35 Planning, Deploying and Managing Realms

The following topics describe the identity management realm implementation in Oracle Internet Directory and how to plan, deploy, and manage identity management realms for enterprise and hosted deployments:

• Understanding Identity Management Realms

• Customizing the Default Identity Management Realm

• About Additional Identity Management Realms for Hosted Deployments

• Creating a DIT View

Note:

All references to Oracle Single Sign-On in this guide refer to Oracle Single Sign-On 10g (10.1.4.3.0) or later.

35.1 Understanding Identity Management Realms

This section gives an overview of planning identity management realms.

This introduction includes the following topics:

• Overview of Identity Management Realm Planning

• Understanding Identity Management Realms in an Enterprise Deployment

• Overview of Identity Management Realms in a Hosted Deployment

• Identity Management Realm Objects

• Overview of Default Identity Management Realm

35.1.1 Overview of Identity Management Realm Planning

This section describes 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 must 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

See Understanding Oracle Internet Directory Organization .

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

When you have decided on the overall DIT structure and the placement of users and groups, you must 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 Self-Service Console in Oracle Identity Management 10g (10.1.4.3.0) or later, and command-line tools.

  See Also:

  The command reference for oidrealm in Oracle Internet Directory Realm Tool section in Reference for Oracle Identity Management.

• After 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 before installing and using other Oracle components that use the Oracle Identity Management infrastructure.

Figure 35-1 shows an example of an identity management realm for an enterprise called MyCompany.

Figure 35-1 Example of an Identity Management Realm

In the example in Figure 35-1, 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.

35.1.2 Understanding Identity Management Realms in an Enterprise Deployment

The following topics discuss deployments with single identity management realms and those with multiple ones:

• About Single Identity Management Realm in an Enterprise

• About Multiple Identity Management Realms in an Enterprise

35.1.2.1 About Single Identity Management Realm in an Enterprise

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 35-2 illustrates this usage.

Figure 35-2 Enterprise Use Case: Single Identity Management Realm

In the example in Figure 35-2, 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.

35.1.2.2 About Multiple Identity Management Realms in an Enterprise

You can use the same identity management infrastructure to serve both internal and 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 35-3 illustrates this usage.

Figure 35-3 Enterprise Use Case: Multiple Identity Management Realms

Description of "Figure 35-3 Enterprise Use Case: Multiple Identity Management Realms"

In the example in Figure 35-3, 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.

35.1.3 Overview of Identity Management Realms in a Hosted Deployment

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 35-4 shows a hosted deployment with two hosted companies.

Figure 35-4 Hosted Deployment Use Case

In the example in Figure 35-4, 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.

35.1.4 Identity Management Realm Objects

This section describes the objects in an identity management realm.

Table 35-1 describes the objects in an identity management realm.

Table 35-1 Oracle Identity Management Objects

Object	Description
Root Oracle Context	This object contains: A pointer to the default identity management realm in the infrastructure Information on how to locate a realm given a simple name of the realm
Identity Management Realm	A normal directory entry with a special object class associated with it.
Identity Management Realm-Specific Oracle Context	In each realm, this object contains: User naming policy of the identity management realm—that is, how users are named and located Mandatory authentication attributes Location of groups in the identity management realm Privilege assignments for the identity management realm—for example: who has privileges to add more users to the realm. Application-specific data for that realm including authorizations

35.1.5 Overview of Default Identity Management Realm

To make configuration easier, Oracle Internet Directory, at installation, creates a default DIT and sets up a default identity management realm.

Figure 35-5 Default Identity Management Realm

As Figure 35-5 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 Connected Directory Integration Concepts and Considerations in Administering Oracle Directory Integration Platform.

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 cn=orcladmin,cn=users,dc=us,dc=mycompany,dc=com.

  Note:

  If the realm administrator's account becomes locked, the Oracle Internet Directory superuser can unlock it by modifying the realm administrator's account password, using Oracle Directory Manager.

• 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 configuration 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:

    • orclUserV2 object class in Reference for Oracle Identity Management for more information about the orclUserV2

    • Delegating Privileges for Oracle Identity Management for a fuller description of the default access control policies in Oracle Identity Management

35.2 Customizing the Default Identity Management Realm

The following topics describe how to customize the default identity management realm based on a number of use cases:

• Default Identity Management Realm Customization

• Understanding the Use Cases for Default Identity Management Realm Customization

• Updating the Existing User and Group Search Base

• Setting Up an Additional Search Base

• Refreshing the Oracle Single Sign-On

• Reconfiguring the Provisioning Profiles

35.2.1 Default Identity Management Realm Customization

After a realm is created, you can further customize various aspects of it.

Table 35-2 lists the aspects you can customize, the tools available for each type of customization, and where to look for more information.

Table 35-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 Services Manager Command-line tools	This section. Overview of Default Identity Management Realm The chapter on using the Oracle Internet Directory Self-Service Console in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Manager in 12c Release 2 (12.2.1.3.0).
Authentication policies	Oracle Directory Services Manager Command-line tools	Managing Password Policies
Identity management authorizations	Oracle Internet Directory Self-Service Console Oracle Directory Services Manager Command-line tools	Delegating Privileges for Oracle Identity Management The chapter on using the Oracle Internet Directory Self-Service Console in Oracle Identity Management Guide to Delegated Administration in the 10g (10.1.4.0.1) library

35.2.2 Understanding the Use Cases for Default Identity Management Realm Customization

A typical scenario where this might be required is one where you must 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 log in using Oracle Single Sign-On. 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 user nickname attribute selected for Oracle Single Sign-On Login is unique across the existing user search base and the third party directory naming context. Otherwise, Oracle Single Sign-On authentication fails 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 Updating 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.

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.

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:

1. "Setting Up an Additional Search Base"

2. "Refreshing the Oracle Single Sign-On"

3. "Reconfiguring the Provisioning Profiles"

35.2.3 Updating the Existing User and Group Search Base

This section describes the procedure to update the existing user group search base.

To set up synchronization with the third party directory:

1. Back up the Oracle Internet Directory database.

2. Create the user and group containers for the third party directory, using Oracle Directory Services Manager, if the entries do not already exist in the directory.

3. Apply appropriate ACLs on the new users container by doing the following:

   1. 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.

   2. Upload the instantiated LDIF file usracl.ldif using the ldapmodify command.

4. Apply appropriate ACLs on the new groups container by doing the following:

   1. 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.

   2. Upload the instantiated LDIF file grpacl.ldif using the ldapmodify command.

5. 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 Setting Up an Additional Search Base.

6. 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.

7. Log in to the Self-Service Console as the administrator of the realm (usually orcladmin).

8. Go to the Configuration tab and set the user search base to the Lowest Common User Search Base you determined. If you must also synchronize groups, then also then set the group search base to the Lowest Common Group Search Base that you determined.

9. To make Oracle Single Sign-On recognize these changes, follow the procedure described under Refreshing the Oracle Single Sign-On.

10. Verify the Oracle Single Sign-On login of users in the original user search base by logging in as orcladmin.

11. You must also reconfigure the applications that have been provisioned to reflect the modified user and group bases. Follow the steps described under Reconfiguring the 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 in the 10g (10.1.4.0.1) library for more details.

35.2.4 Setting Up an Additional Search Base

This section describes the procedure to set up an additional search base.

To set up synchronization with the third party directory:

1. Back up the Oracle Internet Directory database.

2. Create the user and group containers for the third party directory, using Oracle Directory Services Manager, if the entries do not already exist in the directory.

3. Apply appropriate ACLs on the new users container by doing the following:

   1. 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.

   2. Upload the instantiated LDIF file usracl.ldif using the ldapmodify command.

4. Apply appropriate ACLs on the new groups container by doing the following:

   1. 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.

   2. Upload the instantiated LDIF file grpacl.ldif using the ldapmodify command.

5. Log in to the Self-Service Console as the administrator of the realm.

6. Go the Configuration tab.

   1. Add cn=users,dc=mycompanycorp,dc=net to the usersearchbase for the current realm.

   2. Add cn=groups,dc=mycompanycorp,dc=net to the groupsearchbase for the current realm.

7. To make Oracle Single Sign-On recognize these changes, follow the procedure described under Refreshing the Oracle Single Sign-On.

8. Verify the Oracle Single Sign-On login of users in the original user search base by logging in as orcladmin.

9. 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 Reconfiguring the 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 in the 10g (10.1.4.0.1) library for more details.

35.2.5 Refreshing the Oracle Single Sign-On

This section describes how to refresh Oracle Single Sign-on script.

To make Oracle Single Sign-On recognize your configuration changes, execute the Oracle Single Sign-On refresh script by changing to the directory $ORACLE_HOME/sso/admin/plsql/sso/ and typing:

sqlplus [e-mail]

you are prompted for the password. 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 in the 10g (10.1.4.0.1) library.

35.2.6 Reconfiguring the Provisioning Profiles

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.

To reconfigure every provisioning profile:

1. Use ldapsearch to put all the provisioning profile information into an LDIF file:

   ldapsearch -h oid_host -p oid_port \
              -D "cn=orcladmin" -q -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.

2. 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 -q \
              -s sub -b "" \
              "orclguid=Value_of_orclODIPProvisioningAppGuid" dn
   

   You can get the GUID values for each profile from the attribute values in provprofiles.ldif.

3. 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

35.3 About Additional Identity Management Realms for Hosted Deployments

You can create additional identity management realms by using the Self-Service Console in Oracle Identity Management 10g (10.1.4.3.0) or later or by using oidrealm.

Only members of the ASPAdmins group can create a new identity management realm. Use Oracle Directory Services 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 Services 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 must 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 in the 10g (10.1.4.0.1) library for instructions on enabling multiple realms in Oracle Single Sign-On.

See Also:

• The oidrealm command reference in Reference for Oracle Identity Management.

• Modifying an Attribute of a Static Group Entry.

• The chapter on the Oracle Internet Directory Self-Service Console in the Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Manager in 12c Release 2 (12.2.1.3.0) library for information about creating an additional identity management realm.

35.4 Creating a DIT View

Beginning with 11g Release 1 (11.1.1.9.0), you can create a DIT view, which is a virtual view or name space that shows entries from a different or source DIT. The following items are transformed from the source DIT to the DIT view name space:

• DN and all DN attributes in the entry

• RDN mappings that are specified for the DIT view

A DIT view reduces the overall storage requirements in a cloud environment for common entries across tenants. All operations except LDAPMODDN are allowed for a DIT view. A DIT view also allows you to derive the RDN attribute value from any attribute in the entry, so you can hide the original entry when user names are visible in the entry DN.

The section includes the following information:

• Specifying a DIT View

• About DIT View Conditions

• Examples of DIT View

35.4.1 Specifying a DIT View

You can specify the DIT view using the following command:

To specify a DIT view, use the following syntax:

objectclass: orclditview
objectclass: extensibleobject
orclRDNAttrMapping:targetAttribute:sourceAttribute:valueFromAttribute[,optionalRelativeDN]
orclDITBaseDN: realDN
orclrdnmapping: targetRDN:sourceRDN
orclreturnattr: orclmemberof
orclreturnattr: attrName

35.4.2 DIT View Syntax

This section describes items in the orclditview object class.

Table 35-3 describes the items used to specify a DIT view.

Table 35-3 DIT View Syntax

Item	Description
objectclass: orclditview	Indicates to Oracle Internet Directory server to process the entry for DIT view mapping.
objectclass: extensibleobject	Allows the entry to optionally hold any attribute.
orclRDNAttrMapping: targetAttribute:sourceAttribute:valueFromAttribute[,optionalRelativeDN ]	Specifies the mapping of a source attribute to a target attribute and the option of using a value from a different attribute: targetAttribute is the name of the RDN attribute of the entry in the DIT view. sourceAttribute is the name of the RDN attribute in the original source entry. valueFromAttribute is the attribute from which the RDN value is derived. In most cases, this value can be the same as sourceAttribute. optionalRelativeDN optionally specifies if the server performs the transformation only if under this relative DN.
orclDITBaseDN: realDN	Specifies the realDN, which is the location of the original source entries. For example: ou=people,dc=us,dc=example,dc=com
orclrdnmapping: targetRDN: sourceRDN	Specifies RDN mapping from the sourceRDN to the destination targetRDN.
orclreturnattr: attrName	Specifies multi-valued attribute names to return. Oracle Internet Directory server returns only these configured attributes. Optional. If orclreturnattr is not specified, the server returns all attributes of the entry.
orclmaskfilter: LDAP Filter	Use this LDAP filter to mask entries.
orclrdnfilter: LDAP Filter	Use this LDAP filter to perform RDN mapping conversion only if orclrdnfilter is applicable.
orclattrmapping:targetAttr:SourceAttr:overwrite	Copies value from SourceAttr to target Attr. If you set overwrite to 1, then targetAttr values only contain values from sourceAttr. Otherwise it is appended to existing targetAttr values.
orclattrexclude: attrName: specificValue	Allows you to exclude an attribute or a specific value of the attribute. The specificValue parameter is optional.
orclalternateDITDN: AlternateDN	Allows you to search for entries under different container when it is not found in orclDITBaseDN. It is single-valued. configuration. Note: You must configure orclmaskfilter to allow Oracle Internet Directory server to distinguish when to use orclDITBaseDN versus orclalternateDITDN.

35.4.3 About DIT View Conditions

This section introduces you to DIT view conditions.

You must keep the following conditions in mind while working with DIT views:

• The RDN attribute of the entry in DIT view that gets mapped must not contain special characters, such as comma (,) , plus (+), equal (=), semicolon (;), hash (#), backslash (\), less than (<), and greater than (>).

• The RDN attribute of the entry in DIT view that is mapped must be a single-valued attribute with uniqueness attribute enabled.

• If you wish to obtain the aliases (memberof/ismemberof) of the orclmemberof attribute from the DIT view, then while creating the DIT view you must specify the alias in the return attribute list as follows:

  orclreturnattr: orclmemberof
  

35.4.4 Examples of DIT View

In the following example, the real entry will be transformed to the DIT view entry.

Real entry:

uid=user.1,ou=people,dc=us,dc=example,dc=com

DIT view entry:

displayname=user.1,ou=people,dc=uk,dc=example,dc=com

For example:

dn: ou=people,dc=uk,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: ou=people,dc=us,dc=example,dc=com

In the following example, the real entry will be transformed to the DIT mapped entry, where [e-mail] is the mail attribute value.

Real entry:

uid=user.1,ou=people,dc=us,dc=example,dc=com

DIT view entry:

displayname=[e-mail],ou=people,dc=ind,dc=example,dc=com

For example:

dn: ou=people,dc=ind,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: ou=People,dc=us,dc=example,dc=com
ou: people

In the following example, the real entry will be transformed to the DIT mapped entry, where [e-mail] is the mail attribute value.

Real entry:

uid=user.1,ou=people,dc=us,dc=example,dc=com

DIT view entry:

displayname=[e-mail],cn=users,cn=common,dc=example,dc=com

For example:

dn: cn=common,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: dc=us,dc=example,dc=com
orclrdnmapping: cn=users:ou=people
orclrdnmapping: cn=groupview:cn=groups
cn: common

The following example returns an attribute configuration. The configuration shows only the uid, mail, cn, and sn attributes to be returned when entries are searched under this tree. Note that while adding or updating the entry with any other attributes, this restriction does not apply, which allows entries with other attributes to be added.

dn: cn=common,dc=example,dc=com
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclrdnattrmapping: displayname:uid:mail
orclditbasedn: dc=us,dc=example,dc=com
orclrdnmapping: cn=users:ou=people
orclrdnmapping: cn=groupview:cn=groups
orclreturnattr: cn
orclreturnattr: uid
orclreturnattr: mail
orclreturnattr: sn
cn: common

The following example describes attribute mapping. The syntax is as follows:

orclattrmapping=targetAttr:SourceAttr:overWrite

Now, if overWrite is set as 1 then existing values of targetAttr are removed. If overWrite is set as 0, then sourceAttr values are appended to existing values of targetAttr.

dn: cn=ditview,dc=oracle,dc=com
changetype: modify
replace: orclattrmapping
orclattrmapping: cn:mail:0     
orclattrmapping: sn:givenname:1

The following example describes how to exclude a value of an attribute. The syntax is as follows:

orclattrexclude: attribute: optionalValue

dn: cn=ditview,dc=oracle,dc=com
changetype: modify
orclattrexclude: objectclass:orgperson
orclattrexclude: authpassword
orclattrexclude: userpassword

The following example describes alternate base DN.

dn: cn=filteredusers,dc=oracle
objectclass: top
objectclass: orclditview
objectclass: extensibleobject
orclditbasedn: ou=people,dc=us,dc=oracle,dc=com
orclalternateditdn: ou=contractors, dc=us,dc=oracle,dc=com
orclmaskfilter: (employeetype=regular)
cn: filteredusers