|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
 Previous |
 Next |
|
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2) B14082-02 |
|
|
Previous |
Next |
This chapter discusses identity management realms and how to plan and configure them for both enterprise and hosted deployments.
This chapter contains these topics:
Planning the Directory Information Tree for Identity Management
Identity Management Realm Implementation in Oracle Internet Directory
Default Directory Information Tree and the Identity Management Realm
Oracle Internet Directory serves as a shared repository for the entire Oracle Identity Management infrastructure. A carefully planned logical structure of the directory enables:
Enforcement of security policies that meet the requirements of your deployment
An efficient physical deployment of the directory service
Easier configuration of synchronization of a third-party directory with Oracle Internet Directory
Figure 19-1 shows a directory information tree for a hypothetical company, called MyCompany, that is deploying identity management.
MyCompany makes the following decisions with respect to the logical organization of the directory in their U.S. deployment:
A domain name-based scheme is to represent the overall DIT hierarchy. Because the identity management infrastructure is being rolled out in the us domain, the root of the DIT is dc=us,dc=mycompany,dc=com.
Within the naming context chosen, all users are represented under a container called cn=users. Within this container, all users are represented at the same level—that is, there is no organization-based hierarchy. In addition, the uid attribute is chosen as the unique identifier for all users.
Within the naming context chosen, all enterprise groups are represented under a container called cn=groups. Within this container, all enterprise groups are represented at the same level. The naming attribute for all group entries is cn.
Finally, the container dc=us is chosen as the root of the identity management realm. In this case, the name of the realm is us. The deployment expects to enforce similar security policies for all users who fall under the scope of the us realm.
Planning the logical organization of the directory for Oracle Identity Management involves planning:
The overall structure of the directory information tree
The directory containment and naming for users and groups
The identity management realm
This section discusses further details to consider when designing the logical organization of directory information. It contains these topics:
This task involves designing the basic directory information tree that all identity management-integrated applications in the enterprise are to use. As you do this, keep these considerations in mind:
The directory organization should facilitate clean and effective access control. If either full or partial replication is planned, then proper boundaries and policies for replication can be enforced only if the design of the DIT brings out the separation.
If the enterprise is integrating with a third-party directory server, then it is best to align the DIT design of Oracle Internet Directory with the existing DIT. This consideration also applies to deployments that are rolling out Oracle Internet Directory now but plan to roll out another directory later—for example, Microsoft Active Directory that is required for the operation of software from Microsoft. In each case, choosing an Oracle Internet Directory DIT design that is more consistent with that of the third-party directory makes management of user and group objects easier through Oracle Delegated Administration Services and other middle-tier applications.
In a single enterprise scenario, choosing a DIT design that aligns with the DNS domain name of the enterprise suffices. For example, if Oracle Internet Directory is set up in a company having the domain name mycompany.com, then a directory structure that has dc=mycompany,dc=com is recommended. Oracle Corporation recommends that you not use departmental or organization level domain components such as engineering in engineering.mycompany.com.
If the enterprise has an X.500 directory service, and no other third-party LDAP directories in production, then it may benefit by choosing a country-based DIT design. For example, a DIT design with the root of o=mycompany, c=US might be more suitable for enterprises which already have an X.500 directory service.
Because the directory can be used by several applications—both from Oracle and from third-parties alike—the naming attributes used in relative distinguished names (RDNs) constituting the overall DIT structure should be restricted to well-known attributes. The following attributes are generally well-known among most directory-enabled applications:
c: The name of a country
dc: A component of a DNS domain name
l: The name of a locality, such as a city, county or other geographic region
o: The name of an organization
ou: The name of an organizational unit
st: The name of a state or province
A common mistake is to design the DIT to reflect either the corporate divisional or organizational structure. Because most corporations undergo frequent reorganization and divisional restructuring, this is not advisable. It is important to insulate the corporate directory from organizational changes as much as possible.
Most of the design considerations that are applicable to the overall DIT design are also applicable to the naming and containment of users and groups. This section offers some additional things to consider when modeling users and groups in Oracle Internet Directory.
The Oracle Identity Management infrastructure uses Oracle Internet Directory as the repository for all user identities. Even though a user might have account access to multiple applications in the enterprise, there is only one entry in Oracle Internet Directory representing that user's identity. The location and content of these entries in the overall DIT must be planned before deploying Oracle Internet Directory and other components of the Oracle Identity Management infrastructure.
As mentioned in the previous section, it is tempting to organize users according to their current departmental affiliations and hierarchy. However, this is not advisable because most corporations undergo frequent reorganization and divisional restructuring. It is more manageable to capture a person's organizational information as an attribute of that person's directory entry.
There are no performance benefits derived from organizing users in a hierarchy according to organizational affiliations or management chain. Oracle Corporation recommends that you keep the DIT containing users as flat as possible.
If the deployment has different user populations with each one maintained and managed by a different organization, then Oracle Corporation recommends subdividing users into containers based on these administrative boundaries. This simplifies the setting of access controls and helps in cases where replication is needed.
The out-of-the-box default nickname attribute for uniquely identifying users in lookup operations is uid. This is the default attribute used for logins. The out-of-the-box default naming attribute for constructing a DN is cn.
The default attribute for uniquely identifying users is cn or CommonName. The typical value of CommonName is the person's full name. People's names or email addresses, however, can change and therefore might not be suitable as values of this attribute. If possible choose a value that will not change and that uniquely identifies a user, such as the employee id.
Typically, most enterprises have a Human Resources department that establishes rules for assigning unique names and numbers for employees. When choosing a unique naming component for directory entries, it is good to exploit this administrative infrastructure and use its policies.
It is required that all user entries created in the directory belong to the following object classes: inetOrgPerson, orclUserV2.
If you already have a third-party directory, or plan to integrate with one in the future, then it is beneficial to align the user naming and directory containment in Oracle Internet Directory with the one used in the third-party directory. This simplifies the synchronization and subsequent administration of the distributed directories.
|
Note: In Oracle Internet Directory Release 9.0.2, the default value for thenickname attribute was cn. As of Release 9.0.4, the default value for this attribute is uid.
|
Some applications integrated with the Oracle Identity Management infrastructure can also base their authorizations on enterprise-wide groups created by the deployment in Oracle Internet Directory. Like user entries, the location and content of these group entries should also be carefully planned. When you design groups, consider the following:
There are no performance benefits to be gained from organizing enterprise groups in a hierarchy based on the organizational affiliations or ownership. Oracle Corporation recommends keeping the DIT that contains groups as flat as possible. This facilitates easy discovery of groups by all applications and fosters sharing of these groups across applications.
It is preferable to separate the users and groups in the DIT so that different management policies can be applied to each set of entries.
The attribute used to uniquely identify a group should be cn or CommonName.
All group entries created by the enterprise in the directory should belong to the following object classes: groupOfUniqueNames and orclGroup. The former object class is an internet standard for representing groups. The latter is useful when using the Oracle Internet Directory Self-Service Console to manage groups.
Instead of creating new directory access controls for each enterprise-wide group, consider doing the following:
Use the owner attribute of the group to list which users own this group.
Create an access control policy at a higher level that grants all users listed in the owner attribute special privileges to perform the various operations.
In the description attribute, provide information for users to understand the purpose of the group.
Consider using the displayName attribute from the orclGroup object class. This enables Oracle Delegated Administration Services and Oracle Internet Directory Self-Service Console to display a more readable name for the group.
If you have different sets of groups, each of which is maintained and managed by a different organization with its own administrative policies, then sub-divide the groups into containers based on these administrative boundaries. This simplifies the setting of access controls. It also helps when replication is needed.
If you already have a third-party directory, or plan to integrate with one in the future, then align the group naming and directory containment in Oracle Internet Directory with the one used in the third-party directory. This simplifies the synchronization and subsequent administration of the distributed directories.
The previous sections describe guidelines for you to structure the overall DIT and the placement of users and groups for your deployment. Because implementing these guidelines can lead to an infinite number of deployment configurations, you need to capture the intent of your deployment in metadata in the directory itself. This metadata enables Oracle software and other third-party software relying on the Oracle Identity Management infrastructure to understand the deployment intent and successfully function in customized environments.
In Oracle Internet Directory, this deployment intent is captured in the identity management realm. The realm also helps set identity management policies for users and groups whose placement is described in the previous section.
The identity management realm is a well-scoped area in the directory that consists of:
A well-scoped collection of enterprise identities—for example, all employees in the US
A collection of identity management policies associated with these identities
A collection of groups—that is, aggregations of identities—that makes it easier to set identity management policies
Once you have decided on the overall DIT structure and the placement of users and groups, you need to identify the directory entry to serve as the root of the identity management realm. This entry determines the scope of the identity management policies defined in the realm. By default, the scope is the entire directory subtree under the root of the identity management realm. Under this entry, a special entry called OracleContext is created. It contains the following:
The deployment-specific DIT design, including user and group naming and placement, as described in previous sections
The identity management policies associated with this realm
Additional realm-specific information specific to Oracle applications
When planning the identity management realm, consider the following:
The security needs of your enterprise must dictate the choice of the root of the identity management realm. Typically, most enterprises need only one realm. However, multiple realms may be required when multiple user populations are managed with different identity management policies.
If you already have a third-party directory, or plan to integrate with one in the future, then align the choice of the identity management realm root with the DIT design of the third-party directory. This simplifies the synchronization and subsequent administration of the distributed directories.
To configure and administer identity management realms, use the administrative tools provided by Oracle Internet Directory. These include the Oracle Internet Directory Configuration Assistant, the Oracle Internet Directory Self-Service Console, and command-line tools.
Once you have used the Oracle Internet Directory tools to configure the identity management realm, plan on updating the directory naming and containment policies to reflect the customizations made by the deployment. This update must happen prior to installing and using other Oracle components that use the Oracle Identity Management infrastructure.
Figure 19-2 shows an example of an identity management realm for an enterprise called MyCompany.
In the example in Figure 19-2, the deployment uses a domain name-based DIT structure. The container dc=us,dc=mycompany,dc=com is the root of the identity management realm. This results in the creation of a new identity management realm whose scope, by default, is restricted to the entire directory subtree under the entry dc=us. The name of the identity management realm is US.
To migrate a DIT from a third-party directory, use the techniques described in Oracle Identity Management Integration Guide for synchronizing with third-party metadirectory solutions and integrating with third-party directories. If you are migrating a DIT from a Microsoft Active Directory environment, also see the chapter on integration with the Microsoft Active Directory Environment. Oracle recommends that you configure the Oracle Internet Directory DIT to be identical to the third-party DIT.
This section discusses deployments with single identity management realms and those with multiple ones. It contains these topics:
In this scenario, an enterprise has a single set of users, all of whom are managed with the same identity management policies. This is the default configuration of all Oracle products. It includes only one default identity management realm in Oracle Internet Directory and all Oracle components in the enterprise serve users in that realm. Figure 19-3 illustrates this usage.
In the example in Figure 19-3, there is a single, default identity management realm containing employees only. In that realm all users and groups are managed and all share access to the same applications, Application A and Application B.
You can use the same identity management infrastructure to serve both internal as well as external self-registered users. Because the identity management policies for internal and external users are different, you can deploy two realms, one for internal and one for external users. Figure 19-4 illustrates this usage.
Figure 19-4 Enterprise Use Case: Multiple Identity Management Realms
In the example in Figure 19-4, the default identity management realm is for internal users—namely, employees—and these have access to Applications A, B, and C. The external identity management realm is for external users, and they have access to Applications C and D.
In a hosted deployment, the application service provider (ASP) supplies one or more companies with identity management services and hosts applications for them. Each hosted company is associated with a separate identity management realm where users of that company are managed. Users belonging to the application service provider are managed in a different realm, typically the default realm.
Figure 19-5 shows a hosted deployment with two hosted companies.
In the example in Figure 19-5, the ASP users are in the default identity management realm. The ASP manages its users, groups and associated policies in that realm. ASP users manage Applications A, B, and C for the hosted companies. Hosted company MyCompany users are in the Mycompany identity management realm. They use Applications A and B. Hosted company XY Corp users are in the XY Corp identity management realm. They use Applications B and C.
Table 19-1 describes the objects in an identity management realm.
Table 19-1 Oracle Identity Management Objects
To make configuration easier, Oracle Internet Directory, at installation, creates a default DIT and sets up a default identity management realm.
As Figure 19-6 shows, the default identity management realm is part of a global DIT. The node just below the root DSE is dc=com, followed by dc=MyCompany, then dc=us. These four nodes represent the overall DIT structure. The node dc=us is the root of the default identity management realm. It has two subtrees for containing user and group information: cn=Users and cn=Groups. For purposes of illustration, the cn=Users node contains two leaves: uid=user1 and uid=user2. Similarly, the cn=Groups node contains cn=group1 and cn=group2
Oracle Internet Directory gives you the option of setting up a DIT based on the domain of the computer on which the installation is performed. For example, if the installation is on a computer named oidhost.us.mycompany.com, then the root of the default identity management realm is dc=us,dc=mycompany,dc=com.
It also gives you the option of specifying a different DN that meets your deployment needs as the root of your default identity management realm on the Specify Namespace in Internet Directory install screen. For example, if you plan to integrate your Identity Management installation with a third-party directory, it is recommended that you specify a DN that matches the DN of the default naming context in the third-party directory. For more details on obtaining the default naming context from a third-party directory, refer to the chapter on integrating with third-party directories in the Oracle Identity Management Integration Guide.
During configuration, Oracle Internet Directory creates the following:
An Oracle Context associated with the default identity management realm. The Oracle Context stores all the realm-specific policies and metadata. Using the example in the previous paragraph, it creates the Oracle Context with the distinguished name cn=OracleContext,dc=us,dc=mycompany,dc=com. This entry and the nodes under it enable Oracle software to detect realm-specific policies and settings.
A directory structure and naming policies in the default identity management realm. These enable Oracle components to locate various identities. The default values for these are:
All users are located in the container cn=users under the base of the identity management realm. In this example, it is cn=users,dc=us,dc=mycompany,dc=com.
Any new users created in the identity management realm using the Oracle Identity Management infrastructure are also created under the cn=users container.
All new users created in the identity management realm using the Oracle Identity Management infrastructure belong to the object classes orclUserV2 and inetOrgPerson.
All groups are located in the container cn=groups under the base of the identity management realm. In this example, it is cn=groups,dc=us,dc=mycompany,dc=com.
Identity management realm administrator. This user is located under the users container. In this example, the fully qualified DN of the realm administrator is orcladmin,cn=users,dc=us,dc=mycompany,dc=com.
Default authentication policies, which enable authentication services to perform the appropriate actions. These include:
The default directory password policy—for example, password length, lockout, and expiration
Additional password verifiers that need to be automatically generated when provisioning the user
Identity management authorizations. Oracle Internet Directory grants these to the realm administrator who can further delegate these authorizations through the Oracle Internet Directory Self-Service Console. Some of these authorizations include:
Common identity management operational privileges—for example, user creation, user profile modification, group creation
Privileges to install new Oracle components by using the Oracle Identity Management infrastructure.
Privileges to administer Oracle Internet Directory Self-Service Console
|
See Also:
|
This section describes the various administrative tasks that you can perform with respect to identity management realms. It contains these topics:
Once a realm is created, you can further customize various aspects of it. Table 19-2 lists the aspects you can customize, the tools available for each type of customization, and where to look for more information.
Table 19-2 Customizing the Default Identity Management Realm
| What You Can Customize | Tools | Information |
|---|---|---|
|
Directory structure and naming policies |
Oracle Internet Directory Self-Service Console Oracle Directory Manager Command-line tools |
"Changing the Location of Users and Groups In The Default Identity Management Realm" "Planning the Directory Information Tree for Identity Management" The chapter on using the Oracle Internet Directory Self-Service Console in Oracle Identity Management Guide to Delegated Administration |
|
Authentication policies |
Oracle Directory Manager Command-line tools |
Chapter 15, "Password Policies in Oracle Internet Directory" |
|
Identity management authorizations |
Oracle Internet Directory Self-Service Console Oracle Directory Manager Command-line tools |
Chapter 17, "Delegation of Privileges for an Oracle Technology Deployment" The chapter on using the Oracle Internet Directory Self-Service Console in Oracle Identity Management Guide to Delegated Administration |
A typical scenario where this might be required is one where you need to integrate your Oracle Identity Management installation with a third-party directory.
For example, assume the default Identity Management Realm is dc=mycompany,dc=com and there are users under cn=users,dc=mycompany,dc=com.
If the third party directory naming context does not match the current user and group search base in the default realm, then you can alter the user and group search base of the default realm so that both the existing users and the third party users can login using SSO. Select a user search base just high enough to include the existing users and the third party users. Let us call this search base the Lowest Common User Search Base.
|
Note: This approach assumes that the usernickname attribute selected for SSO Login is unique across the existing user search base and the third party directory naming context. Otherwise, SSO authentication will fail for all those users whose nickname attribute values clash.
|
If your deployment scenario matches any of the use cases from 1 to 5, follow the procedure described in "Steps to Update the Existing User and Group Search Base".
Use Case 1:
The third party naming context is under the default realm, but in a different container than the realm user search base
For example, the existing users are under cn=users,dc=mycompany,dc=com and the third party naming context is under cn=users,o=employees,dc=mycompany,dc=com. In this case, the Lowest Common User Search Base is dc=mycompany,dc=com.
Use Case 2:
The third party naming context is outside the default realm, but there is a Lowest Common User Search Base.
For example, the existing users are under cn=users,dc=mycompany,dc=com and the third party naming context is under cn=users, dc=mycompanyecorp,dc=com. In this case, the Lowest Common User Search Base is dc=com.
If the Lowest Common User Search Base is the root DSE, then use the procedures described for Use Case 6::
Use Case 3:
The third party naming context is the same as the default realm DN.
For example, the existing users are under cn=users,dc=mycompany,dc=com and the third party naming context is directly under dc=mycompany,dc=com. In this case, the Lowest Common User Search Base is dc=mycompany,dc=com.
Use Case 4:
The third party naming context contains the parent of the default realm DN.
For example, you might have a default realm with DN: dc=us,dc=mycompany,dc=com, existing users under cn=users,dc=us,dc=mycompany,dc=com and the third party naming context directly under dc=com. In this case, the Lowest Common User Search Base is dc=com.
Use Case 5:
The third party naming context is under the existing user search base.
For example, existing users are under cn=users,dc=mycompany,dc=com and the third party naming context is directly under l=emea,cn=users,dc=mycompany,dc=com. In this case, the Lowest Common User Search Base is cn=users,dc=mycompany,dc=com. In this use case, you do not need to change the user search base.
You must perform the following steps before you set up synchronization with the third party directory.
Back up the Oracle Internet Directory database.
Create the user and group containers for the third party directory, using Oracle Directory Manager, if the entries do not already exist in the directory.
Apply appropriate ACLs on the new users container by doing the following:
Instantiate the variables %USERBASE% and %REALMBASE% in the ACL template file $ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbs and create the file usracl.ldif. Set the variable %USERBASE% to the DN of the new user container and the variable %REALMBASE% to the default realm DN.
Upload the instantiated LDIF file usracl.ldif using the ldapmodify command.
Apply appropriate ACLs on the new groups container by doing the following:
Instantiate the variables %GRPBASE% and %REALMBASE% in the ACL template file $ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbs and create the file grpacl.ldif. Set the variable %USERBASE% to the DN of the new user container and the variable %REALMBASE% to the default realm DN.
Upload the instantiated LDIF file grpacl.ldif using the ldapmodify command.
Determine a Lowest Common User Search Base base that is just high enough to include the existing users and the third party users.
For example, if existing users are under cn=users,dc=mycompany,dc=com and the third party users are under l=emea,dc=mycompany,dc=com, then the Lowest Common User Search Base is dc=mycompany,dc=com.
The Lowest Common User Search Base might be the root entry. That is the case if, for example, the existing users are under cn=users,dc=mycompany,dc=com and the third party users are under dc=mycompanycorp,dc=net. In that case, skip to the deployment scenario described in Use Case 6: "Set up an Additional Search Base"
If you must also synchronize groups, determine a group search base that is just high enough to include the existing groups and the third party groups. Lets call this search base the Lowest Common Group Search Base.
For example, if existing groups are under cn=groups,dc=mycompany,dc=com and the third party groups are under l=emea,dc=mycompany,dc=com, then the Lowest Common Group Search Base is dc=mycompany,dc=com.
Log into the Self-Service Console as the administrator of the realm (usually orcladmin).
Go to the Configuration tab and set the user search base to the Lowest Common User Search Base you determined in step 5. If you must also synchronize groups, then also then set the group search base to the Lowest Common Group Search Base that you determined in step 6.
To make SSO recognize these changes, follow the procedure described under "Refresh SSO".
Verify the SSO login of users in the original user search base by logging in as orcladmin.
You must also reconfigure the applications that have been provisioned to reflect the modified user and group bases. Follow the steps described under "Reconfigure Provisioning Profiles".
|
Note: In addition to the user and group search base attributes, you can also modify other configuration settings of an identity management realm, such as the attribute for Login Name (nickname) or the attribute for RDN, using the Self-Service Console. See: "Modifying Configuration Settings for an Identity Management Realm" in the chapter "Using the Oracle Internet Directory Self-Service Console" of Oracle Identity Management Guide to Delegated Administration for more details. |
Use Case 6:
In this case, the third party naming context is outside the default realm and the Lowest Common User Search Base is the root DSE.
For example, if existing users are under cn=users,dc=mycompany,dc=com and the third party naming context is under cn=users,dc=mycompanycorp,dc=net, then the Lowest Common User Search Base is the root DSE.
In this case, you must add the third party naming context as an additional search base. The steps are as follows:
Perform the following steps before setting up synchronization with the third party directory.
Back up the Oracle Internet Directory database.
Create the user and group containers for the third party directory, using Oracle Directory Manager, if the entries do not already exist in the directory.
Apply appropriate ACLs on the new users container by doing the following:
Instantiate the variables %USERBASE% and %REALMBASE% in the ACL template file $ORACLE_HOME/ldap/schema/oid/oidUserAdminACL.sbs and create the file usracl.ldif. Set the variable %USERBASE% to the DN of the new user container and the variable %REALMBASE% to the default realm DN.
Upload the instantiated LDIF file usracl.ldif using the ldapmodify command.
Apply appropriate ACLs on the new groups container by doing the following:
Instantiate the variables %GRPBASE% and %REALMBASE% in the ACL template file $ORACLE_HOME/ldap/schema/oid/oidGroupAdminACL.sbs and create the file grpacl.ldif. Set the variable %USERBASE% to the DN of the new user container and the variable %REALMBASE% to the default realm DN.
Upload the instantiated LDIF file grpacl.ldif using the ldapmodify command.
Log into the Self-Service Console as the administrator of the realm.
Go the Configuration tab.
Add cn=users,dc=mycompanycorp,dc=net to the usersearchbase for the current realm.
Add cn=groups,dc=mycompanycorp,dc=net to the groupsearchbase for the current realm.
To make Oracle Application Server Single Sign-On recognize these changes, follow the procedure described under "Refresh SSO".
Verify the SSO login of users in the original user search base by logging in as orcladmin.
If mid-tiers have been configured against this identity management configuration, then you must also reconfigure the applications that have been provisioned to reflect the modified user and group bases. Follow the steps described under "Reconfigure Provisioning Profiles".
|
Note: In addition to the user and group search base attributes, you can also modify other configuration settings of an identity management realm, such as the attribute for Login Name (nickname) or the attribute for RDN, using the Self-Service Console. See: "Modifying Configuration Settings for an Identity Management Realm" in the chapter "Using the Oracle Internet Directory Self-Service Console" of Oracle Identity Management Guide to Delegated Administration for more details. |
The steps for making Oracle Application Server Single Sign-On recognize your configuration changes are as follows:
Execute the SSO refresh script by changing to the directory $ORACLE_HOME/sso/admin/plsql/sso/ and typing:
sqlplus orasso/password@ssoreoid.sql
To get the orasso schema password, refer to the appendix "Obtaining the Single Sign-On Schema Password" in the Oracle Application Server Single Sign-On Administrator's Guide.
Restart the OC4J_SECURITY instance by typing:
opmnctl restartproc type=oc4j instancename=OC4J_SECURITY
If you installed middle-tier applications against this default identity management realm before changing its user and group search bases, then the provisioning profiles created by the middle-tier installations become invalid. This happens because the profiles have the old user or group search base information in the event subscriptions attribute. You must modify all the profiles by using oidprovtool.
Execute the following steps for every provisioning profile:
Use ldapsearch to put all the provisioning profile information into an LDIF file:
ldapsearch -h oid_host -p oid_port \ -D "cn=orcladmin" -w password -s sub \ -b "cn=provisioning profiles,cn=changelog subscriber,\ cn=oracle internet directory" \ "objectclass=*" > provprofiles.ldif
The event subscriptions look something like this:
USER:cn=users,dc=mycompany,dc=com:MODIFY(list_of_attributes)USER:cn=users,dc=mycompany,dc=com:DELETEGROUP:cn=groups,dc=mycompany,dc=com:MODIFY(list_of_attributes)GROUP:cn=groups,dc=mycompany,dc=com:DELETE
where cn=users,dc=mycompany,dc=com and cn=groups,dc=mycompany,dc=com are the user and group search bases, respectively, that were created when you installed and configured the application.
Get the actual DNs of the application identity by searching the Oracle Internet Directory server based on the GUID. To get the application DN, type:
ldapsearch -h host -p port -D cn=orcladmin -w password \ -s sub -b "" \ "orclguid=Value_of_orclODIPProvisioningAppGuid" dn
You can get the GUID values for each profile from the attribute values in provprofiles.ldif.
Modify each of the returned profiles as follows:
$ORACLE_HOME/bin/oidprovtool operation=MODIFY \
ldap_host=host ldap_port=port \
ldap_user_dn="cn=orcladmin" \
ldap_user_passwd=password \
interface_version=interfaceVersion \
application_dn=applicationDN \
organization_dn=identity_Realm_DN \
event_subscription=New_Event_Subscription_1
event_ subscription=New_Event_Subscription_2
.
.
.
event_subscription=New_Event_Subscription_n
The New_Event_Subscription arguments should be of the form:
USER: new_user_search_base:MODIFY(list_of_attributes) USER: new_user_search_base:DELETE GROUP: new_group_search_base:MODIFY(list_of_attributes) GROUP: new_group_search_base:DELETE
Here, the organization_dn value should be the original identity realm DN
You can create additional identity management realms by using the Oracle Internet Directory Self-Service Console.
Only members of the ASPAdmins group can create a new identity management realm. Use Oracle Directory Manager to add a user to that group by adding the userDN to the uniquemember attribute of group ASPAdmins in the Default Identity Management Realm-specific OracleContext. Refer to the section on "Modifying a Static Group Entry by Using Oracle Directory Manager" for details.
|
Note: Not all applications can work with multiple identity management realms.Whenever you add an additional realm, you may need to make existing applications aware of it by using a manual procedure. For more information, see the application-specific documentation. In the Oracle Identity Management infrastructure, the single sign-on server needs to be made aware of an additional realm by using a special administrative procedure. Please refer to the chapter "Single Sign-On in Multiple Realms" in the Oracle Application Server Single Sign-On Administrator's Guide for instructions on enabling multiple realms in Oracle Application Server Single Sign-On. |
|
See Also:
|
