|
How-To Document
How to integrate Oracle Label Security with Oracle Internet Directory
Date: 28-Oct-2005
Introduction
The integration of Oracle Label Security with Oracle Internet Directory, the core of Oracle Identity Management, combines the efficiency of centralized user management with label- based access control, providing increased security at lower cost.
Pre-Requisites:
- Install Oracle Application Server 10g (10.1.2.), including the Identity Management option
- Install Oracle Database 10g
- Install Oracle Label Security
- Using Oracle Label Security
- Setting up Enterprise User Security
Send us your comments
Configure Oracle Label Security to use Oracle Internet Directory:
If Oracle Label Security is already installed in your database in 'stand-alone' mode, then it cannot be converted to integrate with OID. You need to drop OLS first, then configure it to work with OID (When you run catnools.sql, all labels will be lost, your tables are no longer protected by OLS unless you re-create them in Oracle Internet Directory, which is the purpose of this document):
Run the script "catnools.sql", located in $OH/rdbms/admin:
 Exit from SQL*Plus and start dbca to configure OLS:
 Click "Next":
 Select "Configure Database Options" and click "Next":
 Select your database and click "Next":
 Select "No, keep the database registered" and click "Next":
 Check "Oracle Label Security" and click "Customize...":
 Select "Yes, configure with OID", enter "cn=dbcreator,cn=users,dc=us,dc=oracle,dc=com", and the password; click "OK":
 Click "Next":
Click on "Finish":
 Click on "OK":
 Click on "OK":
 The configuration in progress:
 Click "No" to exit from dbca
When dbca completed the configuration of OLS for OID, it created a "provisioning profile", which synchronizes changes to policies in the directory back to all connected databases. Existing policies are copied to newly registered databases as well:
There is one provisioning profile for each database.
Edit the Provisioning Profile:
According to Enterprise Security Manager, the distinguished name ("dn") of our database is defined as: "cn=orcl,cn=OracleContext,dc=us,dc=oracle,dc=com"; the user who registered the database with OID is "cn=dbcreator,cn=users,dc=us,dc=oracle,dc=com".
The default period for synchronizing changes to policies in OID to the connected databases ("schedule") is 3,600 seconds – once per hour. We will change this to 60 seconds. Events that occur during the "downtime" are not lost, they will be propagated as soon as the profile is enabled again.
Return to your terminal to enter each of the following three commands as one line (no returns etc.) to edit the provisioning profile in OID:
oidprovtool operation=disable ldap_host=dlsun25 ldap_port=389 ldap_user='cn=dbcreator,cn=users,dc=us,dc=oracle,dc=com' ldap_user_password=welcome application_dn='cn=orcl,cn=OracleContext,dc=us,dc=oracle,dc=com' organization_dn='dc=us,dc=oracle,dc=com'
oidprovtool operation=modify ldap_host=dlsun25 ldap_port=389 ldap_user='cn=dbcreator,cn=users,dc=us,dc=oracle,dc=com' ldap_user_password=welcome application_dn='cn=orcl,cn=OracleContext,dc=us,dc=oracle,dc=com' organization_dn='dc=us,dc=oracle,dc=com' schedule=60
oidprovtool operation=enable ldap_host=dlsun25 ldap_port=389 ldap_user='cn=dbcreator,cn=users,dc=us,dc=oracle,dc=com' ldap_user_password=welcome application_dn='cn=orcl,cn=OracleContext,dc=us,dc=oracle,dc=com' organization_dn='dc=us,dc=oracle,dc=com'
For security reasons, both accounts for "LBACSYS" and "DIP" are locked; unlock them with:
connect / as sysdba;
alter user dip identified by dip account unlock; (*)
alter user lbacsys identified by elcaro1 account unlock;
(*): In case you want to change the password for "dip", don't use the "alter user" command; this needs to be done by using "oidprovtool".
In another Oracle-by-Example it is shown how to create an OLS policy to protect the LOCATIONS-table in the "hr" schema in a stand-alone configuration of OLS (without OID).
The OLS labels in this example contain only levels (SENSitive, CONFidential, PUBlic), no compartments or groups.
LBACSYS is the default DBA for OLS policies, but he granted execution rights to two other administrators in order to achieve strong separation of duty:
"sec_admin": execute on SA_COMPONENTS, SA_POLICY_ADMIN, SA_LABEL_ADMIN
"HR_sec": execute on SA_USER_ADMIN
The end-users with their clearances for access to the hr.LOCATIONS table are:
- Steven King (SKing): PUB, CONF, SENS
- Karen Partners (KPartner): PUB, CONF
- Louise Doran (LDoran): PUB
In this new OID-based OLS demo, we will continue to protect the hr.LOCATIONS table, but the users and OLS policy will be managed centrally in OID.
LBACSYS <—> polcreator
sec_admin/HR_sec <—> poladmin
Create admin users "polcreator" and "poladmin":
Since "polcreator" and "poladmin" don't exist yet, we have to create them first as Enterprise Users in OID.
Point your Browser to http://<OIDhost>:7777/oiddas/ui/oideushome/:
Click on the "Login" button in the top right corner: Enter "orcladmin" and "welcome1" as your credentials:
 Click on the "Users and Groups" tab and click on "create":
 Enter some details for "poladmin", scroll down:
 Scroll down and click on "submit":
 Confirm and click on "Create Another User":
 Add some details for "polcreator", scroll down and hit submit.
On the next page confirm the creation of "polcreator"; close your Browser.
Re-build the policy in OID using "olsadmintool":
At first, "polcreator" needs to be given the privilege to create a policy, which is granted by "cn=orcladmin,cn=users,dc=us,dc=oracle,dc=com":
olsadmintool addpolcreator --userdn "cn=polcreator,cn=users,dc=us,dc=oracle,dc=com" -h dlsun25 -D cn=orcladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
Next, "polcreator" creates the policy "ACCESS_LOCATIONS":
olsadmintool createpolicy --name ACCESS_LOCATIONS --colname OLS_COLUMN --options "READ_CONTROL,LABEL_DEFAULT,HIDE" -h dlsun25 -p 389 -D cn=polcreator,cn=users,dc=us,dc=oracle,dc=com -w welcome1 -b dc=us,dc=oracle,dc=com
 '"polcreator" enables "poladmin" to manage the details of this policy (compare polcreator to LBACSYS and poladmin to sec_admin in our stand-alone demo, where this level of separation of duties is achieved by grating the <policy_name>_DBA - role to sec_admin):
olsadmintool addadmin --polname ACCESS_LOCATIONS --admindn "cn=poladmin,cn=users,dc=us,dc=oracle,dc=com" -h dlsun25 -D cn=polcreator,cn=users,dc=us,dc=oracle,dc=com -w welcome1
The levels are created by "poladmin" (compartments and groups are not included in this demo):
olsadmintool createlevel --polname ACCESS_LOCATIONS --tag 1000 --shortname PUB --longname PUBLIC -b dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
olsadmintool createlevel --polname ACCESS_LOCATIONS --tag 2000 --shortname CONF --longname CONFIDENTIAL -b dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
olsadmintool createlevel --polname ACCESS_LOCATIONS --tag 3000 --shortname SENS --longname SENSITIVE -b dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
 Since this demo does neither include compartments nor groups, we are ready to create the labels, based on the levels created earlier:
olsadmintool createlabel --polname ACCESS_LOCATIONS --tag 1000 --value "PUB" -h dlsun25 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
olsadmintool createlabel --polname ACCESS_LOCATIONS --tag 2000 --value "CONF" -h dlsun25 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
olsadmintool createlabel --polname ACCESS_LOCATIONS --tag 3000 --value "SENS" -h dlsun25 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
As opposed to stand-alone OLS, labels in OID-enabled OLS are not attached to the users in OID; the labels are attached to "profiles", and later the enterprise users are added to the profiles; there is one profile for each label; there is no maximum for users per profile.
olsadmintool createprofile --polname ACCESS_LOCATIONS --profname PUB_PROFILE --maxreadlabel PUB --maxwritelabel PUB --minwritelabel PUB --defreadlabel PUB --defrowlabel PUB -b dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
olsadmintool createprofile --polname ACCESS_LOCATIONS --profname CONF_PROFILE --maxreadlabel CONF --maxwritelabel CONF --minwritelabel PUB --defreadlabel CONF --defrowlabel CONF -b dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
olsadmintool createprofile --polname ACCESS_LOCATIONS --profname SENS_PROFILE --maxreadlabel SENS --maxwritelabel SENS --minwritelabel CONF --defreadlabel SENS --defrowlabel SENS -b dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1
The next step is to create the Enterprise Users in OID; in the stand-alone demo, we picked 3 employees listed in the hr.EMPLOYEES table and made them database users (Steven King, Karen Partners and Louise Doran). To create Enterprise Users, point your browser to the following address:
http://<OIDhost>:7777/oiddas/ui/oideushome/:
Click on the "Login" button in the top right corner: Enter "orcladmin" and "welcome1" as your credentials:
Click on the "Users and Groups" tab and click on "create":
Get some details to fill in to the following forms by querying the hr.EMPLOYEES table in your database for Steven King, Karen Partners and Louise Doran. To create a hierarchy that reflects their access rights, make Karen Louise's manager, and Steven Karen's manager. Enter some details for "Steven King", scroll down:
 After adding some more info, scroll down and click on "submit":
 Enter some details for "Karen Partners", scroll down:
 Define Steven as Karen's manager by clicking on the searchlight; scroll down and click on "submit":
 Enter some details for "Louise Doran", scroll down:
 Define Karen as Louise's manager by clicking on the searchlight; scroll down and click on "submit":
 Enter 'ldoran' in the search box and click on "Go":
 Click on her "Job Title":
 Confirm org-chart, close your Browser
 The next step is to add these employees, according to their hierarchical position, to the profiles created earlier:
- Steven King, CEO: SENS_PROFILE
- Karen Partners, Sales Manager: CONF_PROFILE
- Louise Doran, Sales Rep: PUB_PROFILE
olsadmintool adduser --polname ACCESS_LOCATIONS --profname SENS_PROFILE --userdn cn=SKing,cn=users,dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1 -b dc=us,dc=oracle,dc=com
olsadmintool adduser --polname ACCESS_LOCATIONS --profname CONF_PROFILE --userdn cn=KPartners,cn=users,dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1 -b dc=us,dc=oracle,dc=com
olsadmintool adduser --polname ACCESS_LOCATIONS --profname PUB_PROFILE --userdn cn=LDoran,cn=users,dc=us,dc=oracle,dc=com -h dlsun25 -p 389 -D cn=poladmin,cn=users,dc=us,dc=oracle,dc=com -w welcome1 -b dc=us,dc=oracle,dc=com
 The policy (which has been created in OID), has been replicated to all participating databases (here it is only one: 'orcl') using the information given in the provisioning profile. To verify, use your terminal and log into the database as LBACSYS and enter:
select * from dba_sa_policies;:
 Since the policy is present in all registered databases, it is neccessary to subscribe the database to the policy; this can only be done by "cn=poladmin,cn=users,dc=us,dc=oracle,dc=com", who connects to the database as an Enterprise User:
Using your terminal window, try to connect as "cn=poladmin":
Remember, in the current configuration, only Joe could connect; Nina couldn't, because her name wasn't added to the "dbaccess_ent_role" defined in OID. You have to add "poladmin" to a group with "connect" privilege as well:
poladmin cannot share the enterprise role we created earlier, since he will need special execution rights he does not want to share with the other 'normal' users like Steven King, Karen Partners and Louise Doran, and of course Joe. So we will create another globally identified database role and a special enterprise role in OID. Use your terminal window to connect "as sysdba", create the "policy_admin_role" and grant "connect" to it:
 Exit from your SQL - prompt and start Enterprise Security Manager with "esm":
Provide the log in credentials to Oracle Internet Directory for "cn=orcladmin", then click "OK". Navigate to "Enterprise Roles":
Click on "Operations" and select "Create Enterprise Role": Enter the name of the Enterprise Role, for example "policy_admin_ent_role":
Click "OK" Navigate to the new enterprise role:
Click on the "Database Global Roles" tab and click "Add..." Click on the name of the database that contains the globally identified role: "orcl"
 Enter the credentials requiered to log into your database as "system"
 From the list of available global roles, pick "policy_admin_role".
Click "OK" Click "Apply":
 Click the "Users" tab:
Click "Add..." Navigate to "cn=Users" and search for "poladmin":
Highlight "poladmin" and hit "OK" Click "Apply"
Close Enterprise Security Manager LBACSYS grants execute on sa_policy_admin to the policy_admin_role, which is used by poladmin to subscribe the policy to the database:
(Subscribing the policy is only necessary when using OLS with OID; in stand-alone, the policy can be applied to the table directly. Only poladmin, configured as an Enterprise User, has the privilege to subscribe the policy! poladmin applies the policy to the hr.LOCATIONS table:
 When poladmin applied the policy to the table, an additional column has been added to the LOCATIONS table. When the policy was first created by "polcreator", this column was named "OLS_COLUMN". This column will contain the policy labels. Since the policy was created with the "READ_CONTROL" option, nobody has access to the rows anymore when the policy is applied to the table.
A new enterprise user ("HR_DBA") will be created. This user gets an exclusive schema that is matched directly to his DN in OID (cn=HR_DBA,cn=users,dc=us,dc=oracle,dc=com). All other users connect through a shared schema ("global_ident_schema_user").
HR, the owner of the LOCATIONS table, grants select and update privileges to this exclusive schema, and poladmin creates an OWNER-profile, which provides the FULL privilege to HR_DBA. These privileges combined will allow HR_DBA to add the labels into the OLS_COLUMN, regardless of the policy:
 Point your Browser to http://<OIDhost>:7777/oiddas/ui/oideushome/:
Click on the "Login" button in the top right corner: Enter "orcladmin" and "welcome1" as your credentials:
Click on the "Users and Groups" tab and click on "create":
Enter some details for "poladmin", scroll down:
Scroll down and click on "submit". Confirm creation of the HR_DBA Enterprise User in OID:
Logout and close the Browser Exit from your SQL - prompt and start Enterprise Security Manager with "esm":
Provide the log in credentials to Oracle Internet Directory for "cn=orcladmin", then click "OK". Drill down to "OracleDefaultDomain":
click on the "Database Schema Mapping" tab. Click on "Add...". Highlight the HR_DBA entry and type in the name of the exclusive database schema which HR_DBA will use to connect to the database.
click on "OK". Hit "Apply" and close Enterprise Security Manager
 poladmin adds the new OWNER_PROFILE to the ACCESS_LOCATION - policy in OID, and adds HR_DBA to the profile:
 HR_DBA is now an Enterprise User with his own exclusive database schema and the OLS 'FULL' privilege, and updates the NULL values in the OLS_COLUMN with the data classification labels:
 Start Enterprise Security Manager with "esm", in order to match the three employees SKing, KPartners and LDoran to the global_ident_schema_user, so that they can access and query the hr.LOCATIONS table:
Provide the log in credentials to Oracle Internet Directory for "cn=orcladmin", then click "OK". Navigate to the first enterprise role you created: "dbaccess_ent_role", and click on the "Users" tab.
Highlight "Joe" and click on "Remove"; click "Add..." Navigate to the Users subtree and search for SKing.
Highlight SKing and click on "OK"; repeat for KPartners and LDoran Click Apply.
Close Enterprise Security Manager
Test the policy:
All three employees (SKing, KPartners and LDoran) issue the same query against the hr.LOCATIONS table. But their clearances are different and allow only those rows to be returned to them when their clearance dominates the data classification label:
Connect as SKing:
Steven can see all 23 rows (PUBLIC, CONFIDENTIAL and SENSITIVE)
 Connect as KPartners:
Karen can see 20 rows (PUBLIC and CONFIDENTIAL)
 Connect as LDoran:
Louise can see 17 rows (PUBLIC only)
 |
Bookmark
