Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Tips Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS Access
SQL Scripts & Samples
» Database Forum
» Slideshows
Free Newsletters:

News Via RSS Feed

Database Journal |DBA Support |SQLCourse |SQLCourse2

Featured Database Articles


Posted Aug 30, 2003

Oracle Label Security, Part 1: Overview - Page 2

By Jim Czuprynski

Security Components

OLS uses three sets of criteria to define both the set of user's permissions to access data in a row as well as the row's accessibility: levels, compartments, and groups.

Levels. As the first security dimension's name implies, a level defines increasing data sensitivity. A typical example includes the standard security levels (Unclassified, Classified, Secret, and Top Secret). Another example for most companies is human resources information. Just about everyone needs to know everyone else's first and last name and e-mail address (i.e. company-wide access). However, only the employee, her supervisor, and the Human Resources department should know salary information about the employee (hopefully!) only the human resources coordinator should know about an employee's participation in a company-sponsored anger-management class.

Compartments. The second security dimension, a compartment defines the areas to which data access is restricted. In other words, compartments can be used to classify data. Typical examples of compartments include functional divisions within a company (Sales, Accounting, Human Resources, Information Technology).

Groups. A group is the third security dimension. It typically defines who is the owner of the data and provides yet another way to classify what type of access is permitted. However, groups have one important difference: They can be used to restrict access to data based on the owning organization's hierarchical structure. Business rules appropriate for group enforcement within a group include geographical areas (localities within states/provinces, and states/provinces within countries) and sales forces (regions that encompass several districts that themselves encompass territories). What's really great about this feature is that OLS allows me to restrict row-level access to specific nodes of the hierarchy. For example, I can grant a sales force's regional manager access to only sales generated within his region's districts; a district manager access to sales generated only within her district's territories; and a salesperson to only the sales generated within his territory.

Security Component Combinations. For each of the label security components, up to 10,000 different values may be established. OLS requires that, at a minimum, one value for the security level must be stored in each label column, even if it indicates unrestricted access is permitted. Note, however, that compartments and groups need not be included in the label column's value. Also, each row and each user can be assigned multiple access permissions for compartments and groups.

Session Labels

OLS provides authorization to access secured data based on the combined set of security components assigned to the user known as the session label. When first set up by the security policy administrator, it also defines the user's initial session label, but note that the session label can be modified by the user to any combination of his or her authorized components. The session label is defined by:

  • Minimum and maximum security levels
  • Zero, one, or more than one authorized compartments
  • Zero, one, or more than one authorized groups

Row Labels

OLS secures the data itself by adding a label column to the table(s) that need secured access. The label column is in essence a simple NUMBER datatype that stores the values that are decoded by OLS during access mediation to determine if the row is accessible to the user's session.

Access Mediation

During access mediation, OLS compares the value stored in the label column to the user's label permissions. If the user has been granted sufficient permission to access the row, then the transaction continues. Note that the user must be granted read mode to issue a SELECT statement against the row, and that the user also needs to be granted write mode to perform DML statements (INSERT, UPDATE, DELETE, or MERGE) against the row.

Managing Security Policies

If the setup of these myriad security policies, user levels, and row

security levels seems daunting, fear not! Oracle provides a graphical tool -- Oracle Policy Manager -- that leverages the Oracle Enterprise Manager GUI technology to easily construct and manage OLS security policies. And for those of us who prefer to script our own commands to build the security components, manage the user security policies, and establish row-based security, Oracle supplies several packages to facilitate their easy construction.


So far, we've discussed what needs Oracle Label Security fulfills. In my next article, I'll delve into some actual examples of how to implement Oracle Label security in a database. I'll also show you how to establish security policies, user labels, and row labels. Finally, we'll discuss how Oracle uses access mediation to determine what to do when a user does or doesn't have permission to view or modify a row.

References and Additional Reading

While there is no substitute for direct experience, reading the manual is not a bad idea, either. I've drawn upon the excellent Oracle documentation found in Oracle Label Security Administrator's Guide (A96578-01) for the deeper technical details of this article.

» See All Articles by Columnist Jim Czuprynski

Oracle Archives

Latest Forum Threads
Oracle Forum
Topic By Replies Updated
Oracle Data Mining: Classification jan.hasller 0 July 5th, 07:19 AM
Find duplicates - Unique IDs Lava 5 July 2nd, 08:30 AM
no matching unique or primary key rcanter 1 April 25th, 12:32 PM
Update values of one table based on condition of values in other table using Trigger Gladiator 3 February 29th, 06:01 PM