31 Configuring the Identity Store

This chapter describes how to reassociate the identity store with an external LDAP instead of the default embedded LDAP identity store. It also describes how to configure an LDAP server for Oracle WebCenter Content Server and contains the following subsections:

Caution:

Before reassociating the identity store, be sure to back up the relevant configuration files:

  • config.xml

  • jps-config.xml

As a precaution, you should also back up the boot.properties file for the Administration Server for the domain.

Note that for Portal Framework applications, the steps for Migrating the Discussions Server to Use an External LDAP are not required. For more information about the identity store, see the Oracle Fusion Middleware Application Security Guide.

Permissions:

To perform the tasks in this chapter, you must be granted the WebLogic Server Admin role through the Oracle WebLogic Server Administration Console. Users with the Monitor or Operator roles can view security information but cannot make changes.

See also, Section 1.8, "Understanding Administrative Operations, Roles, and Tools."

31.1 Reassociating the Identity Store with an External LDAP Server

In almost all cases, you should reassociate the identity store with an external LDAP server rather than using the default embedded LDAP. Although you can use many different types of LDAP servers (see the "Supported LDAP Identity Store Types" section in the Oracle Fusion Middleware Application Security Guide for a list of supported LDAPs), this section focuses on how to configure the identity store to use Oracle Internet Directory (OID).

Note:

Reassociating the identity store with an external LDAP server is mandatory only if you're using the documents or discussions tools, in which case the WC_Spaces server, Content Server, and Collaboration server must all be configured to use the same external LDAP server.

For the GUID attribute for other supported LDAPs, see Section 31.2, "Configuring the GUID Attribute for External LDAP Identity Stores." For other user attribute mappings for supported LDAP servers, see the "The User and Role API" section in the Oracle Fusion Middleware Application Security Guide. For information about tuning and performance for LDAPs supported by WebCenter Portal, see the "Tuning Identity Store Configuration" section in the Oracle Fusion Middleware Performance and Tuning Guide.

Note:

For Oracle databases, Oracle WebCenter Portal only supports the CustomDBMSAuthenticator and ReadOnlySQLAuthenticator authenticators. To use the SQL Authenticator requires a custom SQL Provider based on the User and Role API.

Caution:

Reassociating an external LDAP identity store (such as OID) in a production environment with another external LDAP store is not supported. If you have a business need to carry out such a reassociation, please contact Oracle support before going ahead as user information and artifacts may be lost in the process.

To reassociate the identity store with OID:

  1. Log in to the WebLogic Server Administration Console.

    For information on logging into the WebLogic Server Administration Console, see Section 1.13.2, "Oracle WebLogic Server Administration Console."

  2. In the Domain Structure pane click Security Realms.

    The Summary of Security Realms pane displays.

  3. In the Name column, click the realm for which you want to reassociate the identity store.

    The Realm Settings pane displays.

  4. Open the Providers tab.

    The Providers Settings pane displays.

  5. Click New to add a new provider.

    The Create a New Authentication Provider pane displays.

  6. Enter a name for the provider (for example OIDAuthenticator for a provider that authenticates the user for the Oracle Internet Directory).

  7. Select the authenticator appropriate for your LDAP directory from the list of authenticators.

    Be sure to select the authenticator associated with the LDAP you are configuring rather than choosing the generic DefaultAuthenticator. For example, for OID select OracleInternetDirectoryAuthenticator, or for iPlanet select IPlanetAuthenticator.

  8. Click OK to save your settings.

    The Settings pane displays with the new authentication provider.

  9. In the list of Authentication Providers, click the newly created provider.

    The Settings Pane for the new authentication provider displays.

  10. Set the Control Flag to SUFFICIENT.

    Setting the Control Flag to SUFFICIENT indicates that if a user can be authenticated successfully by this authenticator, then the authentication provider should accept that authentication and should not invoke any additional authenticators.

    Note:

    If the authentication fails, it falls through to the next authenticator in the chain. Therefore, be sure all subsequent authenticators also have their control flag set to SUFFICIENT.

  11. Click Save to save this setting.

  12. Open the Provider Specific tab to enter the details for the LDAP server.

    The Provider Specific pane displays.

  13. Enter the details specific to your LDAP server.

    Note:

    The table below shows values appropriate for OID. For the permissible values for other LDAPs, such as Active Directory, see the "OPSS System and Configuration Properties" appendix in the Oracle Fusion Middleware Application Security Guide.

    Parameter Value Description

    Host:

    		  

    The LDAP server's server ID (for example, <ldap_host>example.com)

    Port:

    		  

    The LDAP server's port number (for example, 3060)

    Principal:

    		  

    The LDAP user DN used to connect to the LDAP server (for example, cn=orcladmin)

    Credential:

    		  

    The password used to connect to the LDAP server

    User Base DN:

    		  

    Specify the DN under which your Users start (for example, cn=users,dc=example,dc=com)

    Group Base DN:

    		  

    Specify the DN that points to your Groups node (for example, cn=groups,dc=example,dc=com)

    Use Retrieved User Name as Principal

    Checked

    Must be turned on

    All Users Filter:

    (&(uid=*)(objectclass=person))

    Search to find all users under the User Base DN

    User From Name Filter:

    (&(uid=%u)(objectclass=person))

    		  

    User Name Attribute:

    uid

    		  

  14. Click Save.

  15. Return to the Providers tab and reorder the providers so that the new authentication provider is on top, followed by any other authenticators with the DefaultAuthenticator placed at the end of the list.

    All should have their control flags set to SUFFICIENT so that subsequent authenticators can authenticate identities that fall through from the new provider all the way through to the DefaultAuthenticator (which is used only for the default file-based embedded LDAP). For example, logins such as the default administrator account are not typically created in the LDAP directory, but still need to be authenticated to start up the server. Unless identities are allowed to fall through to the DefaultAuthenticator, the default administrator account will not be authenticated. For more information about the DefaultAuthenticator and the default administrator account, see Section 31.4, "Moving the Administrator Account to an External LDAP Server."

    Note:

    Do not use the REQUIRED control flag if you are using multiple authenticators. If a REQUIRED control flag is found in the list of authenticators, regardless of its position, no further authenticators will be examined.

  16. Restart the Administration Server and the managed server for the changes to take effect.

31.2 Configuring the GUID Attribute for External LDAP Identity Stores

This section describes the different GUID attributes used by non-Oracle LDAP implementations. For other user attribute mappings for other supported LDAP servers, see the "Mapping User Attributes to LDAP Directories" section in the Oracle Fusion Middleware Application Security Guide. See also the "Mapping User Attributes to LDAP Directories" section in the Oracle Fusion Middleware Application Security Guide.

Note:

If you are using an LDAP identity store that does not use the orclGuid attribute, such as IBM Tivoli, you can map the GUID attribute in the WLS authenticator and it will be used automatically.

IBM Tivoli® Directory Server:

ibm-entryUUID

Microsoft® Active Directory:

objectGUID

If you are using Active Directory, remember that the samAccountName attribute has a 20-character limit; other IDs used by Lotus Connections have a 256-character limit.

Microsoft Active Directory Application Mode (ADAM):

objectGUID

To use objectSID as the default for ADAM, add the following line to the <config:attributeConfiguration> section of the wimconfig.xml file:

<config:externalIdAttributes name="objectSID" syntax="octetString"/>

BM Domino® Enterprise Server:

dominoUNID

Note that if the bind ID for the Domino LDAP does not have sufficient manager access to the Domino directory the Virtual Member Manager (VMM) does not return the correct attribute type for the Domino schema query; DN is returned as the VMM ID. To override VMM's default ID setting, add the following line to the <config:attributeConfiguration> section of the wimconfig.xml file:

<config:externalIdAttributes name="dominoUNID"/>

Sun Java™ System Directory Server:

nsuniqueid

eNovell Directory Server:

GUID

31.3 Adding Users to the Embedded LDAP Identity Store

For development or testing purposes, you can add users to the embedded LDAP using the WebLogic Server Administration Console, or using an LDIF file and LDAP commands. Using an LDIF file lets you add additional attributes not available through the WebLogic Server Administration Console.

Note:

The embedded LDAP server should only be used for testing or "proof of concept." For production use, Oracle recommends using external identity stores, such as Oracle Internet Directory or Microsoft Active Directory, that are supported by the OPSS user and role APIs. For information about the user and role attributes, see the "Mapping User Attributes to LDAP Directories" section in the Oracle Fusion Middleware Application Security Guide.

For Oracle Internet Directory, users are typically managed using ODSM (described in the "Managing Directory Entries" section in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory).

Note:

If you are planning to reassociate your identity store with an external LDAP, perform that step first (as described in Section 31.1, "Reassociating the Identity Store with an External LDAP Server") as when you reassociate the embedded LDAP with OID or other external LDAP implementation users and user artifacts may not be carried forward. Consequently, do not add users to the embedded LDAP with the expectation of moving them to a production environment. The embedded LDAP is intended to be used only as a test environment, and is not intended as a staging environment that can be moved to production.

WebCenter Portal supports self-registration. New users who self-register with WebCenter Portal are added directly to the identity store. For more information about self-registration, see Section 48.11, "Enabling Self-Registration."

Note:

Adding users to the identity store is typically a system administrator task and may not be a task for which application-level administrators have the required permissions.

This section includes the following subsections:

31.3.1 Adding Users to the Identity Store Using the WLS Administration Console

To add users to the embedded LDAP identity store from the WebLogic Server Administration Console:

  1. Log in to the WebLogic Server Administration Console.

    For information on logging into the WebLogic Server Administration Console, see Section 1.13.2, "Oracle WebLogic Server Administration Console."

  2. In the Domain Structure pane, click Security Realms.

    The Summary of Security Realms pane displays.

  3. In the Name column, click the realm to which you want to add users.

    The Realm Settings pane displays.

  4. Click the Users and Groups tab to display the list of current users.

  5. Click New to add a new user.

  6. On the Create a New User page, enter the new user login name in the Name field.

    User names are case sensitive and must be unique. Do not use commas, tabs or any of the other characters in the following comma-separated list:

    < >, #, |, &, ?, ( ), { }

  7. In the Description field, enter a description for the user (for example, the user's full name).

  8. From the Provider drop-down menu, select DefaultAuthenticator.

  9. In the Password field, enter a password for the user.

    The minimum password length for a user defined in the WebLogic Authentication provider is 8 characters (note that other LDAP providers may have different requirements for the password length). Do not use user name/password combinations such as weblogic/weblogic in a production environment.

  10. Reenter the password in the Confirm Password field.

  11. Click OK to save your changes and add the user.

    The user should now appear in the list of users.

31.3.2 Adding Users to the Identity Store Using an LDIF File

You can add users directly to the embedded LDAP identity store using an LDIF file. Using an LDIF file enables you to specify additional user attributes that are not available through the WebLogic Server Administration Console.As the embedded LDAP server is a conformant LDAP server, you can use LDAP commands to add or modify users. You can also search the directory, which is useful when exporting and importing user accounts.

To add users to the embedded LDAP using an LDIF file you must perform the following tasks:

Enable External LDAP Access

When WebLogic Server is installed, the LDAP access credential is set as a randomized value and encrypted in the config.xml file. To enable external LDAP access, you must reset the access credential for the embedded LDAP.

To reset the access credential for the embedded LDAP:

  1. Log in to the WebLogic Server Administration Console.

    For information on logging into the WebLogic Server Administration Console, see Section 1.13.2, "Oracle WebLogic Server Administration Console."

  2. In the Domain Structure pane, click wc_domain.

  3. In the Settings pane for wc_domain, click the Security tab, and then click the Embedded LDAP tab.

    The Settings Pane for wc_domain displays the embedded LDAP settings.

  4. Enter a new password in the Credential field, and reenter it in the Confirm Credential field.

  5. Click Save to save your settings.

  6. Restart the WebLogic server.

    After this, you are ready to access the LDAP server with the following values:

    • the DN value for admin access is "cn=Admin"

    • the password is the value you entered in the Credential field

    • the port is the same as the admin port, which by default is 7001

Create an LDIF File

You can create an LDIF file with any text editor, and can include any attributes appropriate for the embedded LDAP directory. The objectclasses that are supported by default in the embedded LDAP server for WebLogic Server are the following:

  • person

  • inetOrgPerson

  • organizationalPerson

  • wlsUser

In order to interact successfully with the embedded LDAP server, you should understand the default layout of the directory information tree (DIT). The default layout in the embedded LDAP directory is shown in Figure 31-1.

Figure 31-1 Embedded LDAP Directory Information Tree

Description of Figure 31-1 follows
Description of "Figure 31-1 Embedded LDAP Directory Information Tree"

Note:

The naming attribute for the user entry in the embedded LDAP directory tree is "uid". This is different from the default configuration for Oracle Internet Directory (OID), where the naming attribute is "cn". Also, the location of the users in this tree is "ou=people,ou=myrealm,dc=wc_domain".

The following example shows an LDIF file with the attributes that are displayed in the WebCenter Portal user profile screens:

dn: uid=john.doe,ou=people,ou=myrealm,dc=wc_domain
description: John Doe
cn: john.doe
uid: john.doe
sn: Doe
objectclass: wlsUser
objectclass: organizationalperson
objectclass: inetOrgPerson
objectclass: person
objectclass: top
userpassword: MyPassword
displayName: John Doe
employeeNumber: 12345
employeeType: Regular
givenName: John
homePhone: 650-555-1212
mail: john.doe@example.com
title: Manager
manager: uid=mary.jones,ou=people,ou=myrealm,dc=wc_domain
preferredLanguage: en
departmentNumber: tools
facsimiletelephonenumber: 650-555-1200
mobile: 650-500-1200
pager: 650-400-1200
telephoneNumber: 650-506-1212
postaladdress: 200 Oracle Parkway
l: Redwood Shores
homepostaladdress: 123 Main St., Anytown 12345

To create a file with multiple user entries, just replicate the above lines as many times as required, with a blank line between entries.

Note:

WebCenter Portal user profiles include some attributes that are only available in Oracle Internet Directory. These include the following attributes from the orclUserV2 objectclass:

  • orclTimeZone

  • orclDateOfBirth

  • maidenName

You cannot add these attributes to an embedded LDAP identity store.

Add the Users

The example below uses the ldappadd command, a part of the LDAP command line utilities provided with the Oracle Internet Directory server. For more information about using the ldappadd command, see the "Oracle Internet Directory Data Management Tools" section in the Oracle Fusion Middleware Reference for Oracle Identity Management. For a complete list of user attribute mappings for LDAP servers supported by WebCenter Portal and Portal Framework applications, see the "Mapping User Attributes to LDAP Directories" section in the Oracle Fusion Middleware Application Security Guide.

ldapadd -h weblogichost.example.com -p 7001 -D cn=Admin -w password -v -f newuser.ldif
 
add description:
        John Doe
add cn:
        john.doe
add uid:
        john.doe
add sn:
        Doe
add objectclass:
        wlsUser
        organizationalperson
        inetOrgPerson
        person
        top
add userpassword:
        password
add displayname:
        John Doe
add employeenumber:
        12345
add employeetype:
        Regular
add givenname:
        John
add homephone:
        650-555-1212
add mail:
        john.doe@example.com
add title:
        Manager
add manager:
        uid=mary.jones,ou=people,ou=myrealm,dc=wc_domain
add preferredlanguage:
        en
add departmentnumber:
        tools
add facsimiletelephonenumber:
        650-555-1200
add mobile:
        650-500-1200
add pager:
        650-400-1200
add telephonenumber:
        650-506-1212
add postaladdress:
        200 Oracle Parkway
add l:
        Redwood Shores
add homepostaladdress:
        123 Main St., Anytown 12345
adding new entry uid=john.doe,ou=people,ou=myrealm,dc=wc_domain
modify complete

31.4 Moving the Administrator Account to an External LDAP Server

When configuring the domain to use an external LDAP server, you can also optionally move the system administrator account (weblogic by default) to the LDAP server.

If the system administrator account, or any other appropriate user in LDAP, is in an LDAP group called "Administrators", then this account should be sufficient to manage the server, and the DefaultAuthenticator provider can be removed from the list of authentication providers. In this case, all users, including the administrator account, are authenticated against the external LDAP.

Note:

WebCenter Portal only recognizes users in the identity store that is mapped by the first authenticator. Since the WebCenter Portal Administrator account is initially created only in the embedded LDAP server, if an external LDAP such as Oracle Internet Directory is configured as the primary authenticator for WebCenter Portal, you must also create a user in that LDAP and grant that user the WebCenter Portal Administrator role. For more information about granting the WebCenter Portal Administrator role to a user, see Section 32.6.1, "Granting the WebCenter Portal Administrator Role."

If you cannot create the weblogic (default) user in the external LDAP directory, there are two options. You can:

  • Keep the DefaultAuthenticator provider and use the weblogic account with the local embedded LDAP server in WebLogic Server to start and stop servers and do other administrator operations from the WebLogic Server Administration Console. If you keep the DefaultAuthenticator, make sure that the control flag for the DefaultAuthentication provider is set to SUFFICIENT. If you choose this option, you must also perform the additional steps described in Section 31.4.1, "Migrating the Discussions Server to Use an External LDAP."

    Note:

    If the weblogic user account is used from the DefaultAuthenticator, this account should not be used to access WebCenter Portal as the application code will not be able to find the user in the external LDAP store.

  • Remove the DefaultAuthenticator and make sure that any valid user account used for administrator operations, such as starting and stopping servers, is included in an "Administrators" group or other named group that contains the list of users that are allowed to manage your domain in OID or other external LDAP. If a name other than "Administrators" is used, then you must update the group name in the definition of the WebLogic Server Global Administrator role. By default, this is defined as membership in the enterprise group called "Administrators". For information about changing the administrator group name, see Section 31.4.2, "Changing the Administrator Group Name."

This section includes the following subsections:

31.4.1 Migrating the Discussions Server to Use an External LDAP

If you've installed the discussions server and choose not to move the administrator account to an external LDAP (as described in Section 31.4, "Moving the Administrator Account to an External LDAP Server"), you must perform some additional steps to identify the new administrator account for the discussions server prior to reordering the authenticators on the WebLogic server:

  1. Select a user account from the external LDAP to be the administrator for the discussions server.

  2. Create an administrator account in the DefaultAuthenticator (that is, the embedded LDAP) that matches the one you selected from the external LDAP. The account names in the embedded LDAP and the external LDAP server must be the same.

    For information about adding users to the embedded LDAP, see Section 31.3, "Adding Users to the Embedded LDAP Identity Store."

  3. Log in to the discussions server Admin Console with the boot-identity account (that is, weblogic) at:

    http://host:port/owc_discussions/admin

    Where host and port are the host ID and port number of the WLS_Services managed server.

  4. Click Settings > Admins/Moderators.

    The Admins & Moderators page displays (see Figure 31-2).

    Figure 31-2 Admins & Moderators Page

    Description of Figure 31-2 follows
    Description of "Figure 31-2 Admins & Moderators Page"

  5. Click Grant New Permissions.

    The Grant New Permissions pane displays (see Figure 31-3).

    Figure 31-3 Grant New Permissions Pane

    Description of Figure 31-3 follows
    Description of "Figure 31-3 Grant New Permissions Pane"

  6. Grant System Admin privileges to the user you created, as shown in Figure 31-4.

    Figure 31-4 Grant New Permissions Pane with New User

    Description of Figure 31-4 follows
    Description of "Figure 31-4 Grant New Permissions Pane with New User"

  7. Click System > System Properties.

    The Jive Properties page displays (see Figure 31-5).

    Figure 31-5 Jive Properties Page

    Description of Figure 31-5 follows
    Description of "Figure 31-5 Jive Properties Page"

  8. Check that the properties marked in red have been added and are set as shown in Figure 31-5.

  9. Log in to the WebLogic Server Administration Console.

    For information on logging in to the WebLogic Server Administration Console, see Section 1.13.2, "Oracle WebLogic Server Administration Console."

  10. In the Domain Structure pane, click Security Realms.

    The Summary of Security Realms pane displays.

  11. In the Name column, click the realm for which you want to change the administrator group name.

    The Realm Settings pane displays.

  12. Select the Providers tab and the Authentication sub-tab, and reorder the authentication providers so that the authenticator for the external LDAP appears at the top of the list as shown in the example in Figure 31-6:

    Figure 31-6 Providers Tab with Reordered Authentication Providers

    Description of Figure 31-6 follows
    Description of "Figure 31-6 Providers Tab with Reordered Authentication Providers"

  13. Restart the domain Administration server and discussions server.

  14. If you have not done so already, create a user in the external LDAP and grant that user the WebCenter Portal Administrator role (see Section 32.6.1, "Granting the WebCenter Portal Administrator Role").

31.4.2 Changing the Administrator Group Name

You can change the group name to any other valid enterprise role in your LDAP server that contains users authorized to manage the domain. This lets you delegate the administration of specific domains in your enterprise. You can create various administration groups in the directory and have the corresponding domains be configured to use the appropriate group for defining its administrators.

The following example LDIF file creates an administrative group in Oracle Internet Directory:

dn: cn=wc_domain_Admin,cn=groups,dc=example,dc=com
cn: wc_domain_Admin
uniquemember: cn=joe.admin,cn=users,dc=example,dc=com
owner: cn=orcladmin
displayname: WebLogic Administrators Group
description: WebLogic Administrators Group
objectclass: orclgroup
objectclass: groupofuniquenames

Once this group is created, you must update the role definition for the WebLogic Server global Admin role using the WebLogic Server Administration Console.

To update the role definition for the WebLogic Server global Admin role:

  1. Log in to the WebLogic Server Administration Console.

    For information on logging into the WebLogic Server Administration Console, see Section 1.13.2, "Oracle WebLogic Server Administration Console."

  2. In the Domain Structure pane, click Security Realms.

    The Summary of Security Realms pane displays.

  3. In the Name column, click the realm for which you want to change the administrator group name.

    The Realm Settings pane displays.

  4. Open the Roles and Policies tab, and then the Realm Roles subtab.

    The Realm Roles settings pane displays.

  5. Expand the Global Roles node, and then the Roles node.

  6. Click View Role Conditions for the Admin role.

    The Edit Global Role page displays.

    By default, the Administrators group in Oracle Internet Directory (or other configured identity store) defines who has the administrator role in WebLogic Server.

  7. Click Add Conditions to add a different group name.

    The Edit Global Role - Predicate List page displays.

  8. Select Group from the Predicate List list and click Next.

    The Edit Global Role - Arguments page displays.

  9. Enter the name for the new administrator group and click Add.

  10. Select the pre-existing administrator group and click Remove to delete it leaving the new one you've selected in its place.

  11. Click Finish to save your changes.

    After making this change, any members of the new group specified are authorized to administer WebLogic Server.

31.5 Configuring the Oracle Content Server to Share the WebCenter Portal Identity Store LDAP Server

Oracle Content Server (OCS) must be configured to use the same identity store LDAP server as WebCenter Portal. For more information on configuring the OCS, see Chapter 9, "Managing Content Repositories" and also see the "Configuring the LDAP Identity Store Service" section in the Oracle Fusion Middleware Application Security Guide.

31.6 Aggregating Multiple Identity Store LDAP Servers Using libOVD

Sites with multiple identity stores can use libOVD to aggregate their user profile information. Two scenarios are covered in the step-by-step configuration instructions below:

  • Users are available in distinct identity stores with complete user profile information available in the respective identity store.

  • The same user is available in both identity stores with some attributes in one store and other attributes in the other store.

Note:

If you are supporting self-registration with Active Directory, be sure to see the troubleshooting note in Section 30.3.3, "Users Cannot Self-Register when WebCenter Portal Configured with Active Directory."

This section contains the following subsections:

31.6.1 Configuring libOVD for Identity Stores with Complete User Profiles

To configure libOVD where each identity store contains complete user profiles:

  1. Create the required authenticators in the WLS Admin Console for the identity stores being configured and restart the Weblogic Admin and managed servers for the domain. Alternatively, you can also configure the identity store information in jps-config.xml by hand.

  2. Update the identity store service instance in jps-config.xml and add a property virtualize with the value true. You can do this either by editing the jps-config.xml file by hand, or using Fusion Middleware Control.

  3. WebCenter Portal lets users self-register, which creates a new user or group in the identity store. Since multiple identity stores are being used, you also need to explicitly specify the user create bases and group create bases in jps-config.xml. This step must be done by directly editing jps-config.xml.

    The jps-config.xml file should look like the example below after the configuration.

    <serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
<property value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"
name="idstore.config.provider"/>
<property value="oracle.security.idm.providers.stdldap.JNDIPool"
name="CONNECTION_POOL_CLASS"/>
<property value="true" name="virtualize"/>
<extendedProperty>
        <name>user.create.bases</name>
        <values>
             <value>ou=people,ou=myrealm,dc=wc_domain</value>
         </values>
</extendedProperty>
<extendedProperty>
        <name>group.create.bases</name>
        <values>
              <value>ou=groups,ou=myrealm,dc=wc_domain</value>
        </values>
</extendedProperty>
</serviceInstance>

    Be sure to replace the actual values for the user create base in "ou=people,ou=myrealm,dc=wc_domain" and group create base "ou=groups,ou=myrealm,dc=wc_domain."

31.6.2 Configuring libOVD for Identity Stores with Partial User Profiles

To configure libOVD where each identity store contains only partial user profiles:

  1. Create the required authenticators in the WLS Admin Console for the identity stores being configured and restart the Weblogic Admin and managed servers for the domain. Alternatively, you can also configure the identity store information in jps-config.xml by hand.

  2. Update the identity store service instance in jps-config.xml and add a property virtualize with the value true. You can do this either by editing the jps-config.xml file by hand, or using Fusion Middleware Control.

  3. WebCenter Portal lets users self-register, which creates a new user or group in the identity store. Since multiple identity stores are being used, you also need to explicitly specify the user create bases and group create bases in jps-config.xml. This step must be done by directly editing jps-config.xml.

    The jps-config.xml file should look like the example below after the configuration.

    <serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
<property value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"
name="idstore.config.provider"/>
<property value="oracle.security.idm.providers.stdldap.JNDIPool"
name="CONNECTION_POOL_CLASS"/>
<property value="true" name="virtualize"/>

<extendedProperty>
        <name>user.create.bases</name>
        <values>
             <value>ou=people,ou=myrealm,dc=wc_domain</value>
         </values>
</extendedProperty>
<extendedProperty>
        <name>group.create.bases</name>
        <values>
              <value>ou=groups,ou=myrealm,dc=wc_domain</value>
        </values>
</extendedProperty>
</serviceInstance>

    In the above example "ou=people,ou=myrealm,dc=wc_domain" and "ou=groups,ou=myrealm,dc=wc_domain" are the user and group create bases respectively. The actual values should be substituted while doing the configuration.

  4. Run the following OVD WLST commands to configure the Join Adapter for the identity stores. Go to MW_HOME/oracle_common/common/bin and invoke wlst.sh (wlst.cmd in windows) and bring up the WLST prompt. Connect to the Weblogic Administration Server and run the following WLST commands.

    createJoinAdapter(adapterName="<Join Adapter Name>",  root="<Namespace>", primaryAdapter="<Primary adapter Name>")

addJoinRule(adapterName="<Join Adapter Name>", secondary="<Secondary Adapter Name>", condition="<Join Condition>")

    If there are more secondary identity stores, then run the addJoinRule command for each secondary identity store.

    modifyLDAPAdapter(adapterName="<AuthenticatorName>", attribute="Visible", value="Internal")

    Run the above modifyLDAPAdapter command for each identity store that is configured.

Example

Authenticator 1:

In this example, the same user is available in both identity stores with some attributes in one store and some in the other. For this example, AD is the primary store and OID is the secondary store.

Authenticator Name: AD

User Base: cn=users,dc=acme,dc=com

Authenticator 2:

Authenticator Name: OID

User Base: cn=users,dc=oid,dc=com

Perform steps 1 - 3 above, specifying the user.create.bases and group.create.bases corresponding to the primary adapter's namespace.

Perform the following WLST commands:

createJoinAdapter(adapterName="JoinAdapter1", root="dc=acme,dc=com", primaryAdapter="AD")
addJoinRule(adapterName="JoinAdapter1", secondary="OID", condition="uid=cn")

"uid=cn" is the join condition in the above example, which indicates that if the uid value of a user in the secondary identity store (OID) matches with the cn value of the user in the primary identity store (AD), then the attributes will be combined.

modifyLDAPAdapter(adapterName="OID", attribute="Visible", value="Internal")
modifyLDAPAdapter(adapterName="AD", attribute="Visible", value="Internal")

Restart the WebLogic Administration server and managed servers.

31.6.3 Restoring the Single Authenticator

You can restore the single authenticator by removing the Join Adapter rule, thereby backing out the configuration done in Section 31.6.2, "Configuring libOVD for Identity Stores with Partial User Profiles."

To remove the Join Adapter rule, connect to the Weblogic Administration Server and run the following WLST commands:

deleteAdapter(adapterName="JoinAdapter1")
modifyLDAPAdapter(adapterName="oid auth", attribute="Visible", value="Yes")
modifyLDAPAdapter(adapterName="AD", attribute="Visible", value="Yes")

Restart the WebLogic Administration server and managed servers and make sure that users from both identity stores are able to log in.

31.7 Configuring Dynamic Roles for WebCenter Portal

This section describes how to configure dynamic roles for WebCenter Portal.

This section contains the following subsections:

31.7.1 Overview of Configuring Dynamic Roles

With static roles, the role to membership relationship is static. This relationship is established at provisioning time, and once established, and after a user logs in, the subject is populated with all the roles for which the user is a direct member or indirectly a member based on an enterprise group.

Dynamic roles provide for rule-based role membership. Membership to an application role is provided through a dynamic group. Dynamic group definitions can include constraints for user profile attributes, and date and time that provide a flexible way to provide access to an application. For example, a user could be allowed to access an application only during their shift or during maintenance periods without explicitly having to grant them that access. Note that rules based on session or request attributes are not supported in this release.

Dynamic roles can be defined in Oracle Entitlement Server (OES) 10g as a role with constraints. The role defined in OES is added to user's enterprise group principal through an OVD plug-in. When the user logs in the policy rules are evaluated to determine whether the user's subject gets the dynamic group principal. Figure 31-7 shows the login process for a topology configured with OES and the OVD plug-in.

Figure 31-7 Login Process

Description of Figure 31-7 follows
Description of "Figure 31-7 Login Process"

Figure 31-8 shows what happens during a dynamic group query for a topology configured with OES and the OVD plug-in.

Figure 31-8 Group Query

Description of Figure 31-8 follows
Description of "Figure 31-8 Group Query"

31.7.2 Prerequisites to Configuring Dynamic Roles

Prior to installing and configuring the OVD plug-in, you should already have installed and configured Oracle Internet Directory (OID), Oracle Virtual Directory (OVD) 11g, and Oracle Entitlement Server (OES) 10g. Note that the OVD plug-in is not currently certified with OES 11g.

OID and OVD are part of the Oracle Identity Management 11g suite. If you have not already installed them, install them as described in "Installing and Configuring Oracle Identity Management (11.1.1.7.0)" in Oracle Fusion Middleware Installation Guide for Oracle Identity Management. Configure OVD by running config.sh as described in the "Configuring Oracle Virtual Directory" section in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

Install OES 10g with RMI-SSM and the latest cumulative patch as described in the section "Configuring a Remote SSM and Proxy" in the SSM Installation and Configuration Guide.

Additionally, if you have plan to incorporate constraints based on Personalization for WebCenter Portal, you will also need to install and configure the Personalization server, as described in Section 25, "Managing Personalization."

31.7.3 Installing the OVD Plug-in

Oracle Virtual Directory (OVD) is a part of the Oracle Identity Management suite of products. OVD provides an elegant solution to the problem of integrating multiple heterogeneous data sources presenting them as a consolidated view that can be consumed by an LDAP client in WebCenter Portal or Portal Framework applications. Through OVD, OES data can be exposed by means of an OVD custom adaptor in a way that it can be consumed by WebCenter Portal or Portal Framework applications. The adapter can represent non-LDAP data as an LDAP-like tree hierarchy. The functionality of the custom adapter is contained in a plug-in that can be attached to the adapter.

To install the OVD plug-in:

  1. Locate the oes-ovd-plugin.zip file in the following folder:

    WCP_HOME/modules/oracle.webcenter.framework_11.1.1/oes-ovd-plugin.zip

  2. Make a copy of the oes-ovd-plugin.zip file.

  3. Go to the plugins/lib directory where OVD was installed (for example, asinst_1/OVD/ovd1/plugins/lib).

  4. Unzip oes-ovd-plugin.zip.

  5. Copy webcenterNames.xml to the instance home (for example, ORACLE_HOME/asinst_1).

  6. Create the following directories:

    mkdir pdpproxy
mkdir keys

  7. Copy the following OES jars from the OES/rmi-ssm installation directory to the lib directory:

    EccpressoCore.jar
antlr.jar
api.jar
asi_classes.jar
asitools.jar
commons-pool-1.3.jar
connector.jar
framework.jar
jsafeFIPS.jar
jsafeJCEFIPS.jar
kodo-runtime.jar
log4j.jar
managementapi.jar
orawsdl14.jar
rmi-ssm.jar
rmi-stubs.jar
rmi-types.jar
ssladapter.jar
sslplus.jar
webservice.jar
webserviceclient.jar
webservices.jar
xbean.jar

  8. Go to the keys directory that you just created and copy all the keys in the OES install (ales32-shared/keys directory) here.

  9. Go to the pdpproxy directory that you just created and copy the PDP configuration properties file from OES (rmi-ssm/pdpproxy/PDPProxyConfiguration.properties).

  10. Restart the OVD process with the following command:

     ./opmnctl stopall startall

  11. If you are planning to use Personalization in defining your constraints, install the p13nattributeRetriever as shown below:

    1. Locate the <WebCenter Home>/webcenter/modules/oracle.webcenter.framework_11.1.1/attribute-retriever.jar file.

    2. Locate the rmi-ssm/lib/providers directory of the OES installation, and copy the attribute-retriever.jar file there.

    3. Restart the rmi-ssm.

31.7.4 Configuring Dynamic Roles

This section describes how to configure your WebCenter Portal environment to support dynamic roles through OES and the OVD plug-in. Prior to completing the configuration steps in this section, you should already have installed the prerequisite applications (described in Section 31.7.2, "Prerequisites to Configuring Dynamic Roles") and the OVD plug-in (described in Section 31.7.3, "Installing the OVD Plug-in").

This section contains the following subsections:

31.7.4.1 Configuring OES

All the dynamic roles that you want to be available in WebCenter Portal should be defined under a single umbrella resource and action. In the steps below, we're using WebCenterApp/WebCenterResource as the umbrella resource, and browse as the action. When you create the dynamic roles, the roles are then granted browse permission on the resource using role mapping polices. A role mapping policy can also have additional constraints based on identity store or Personalization attributes.

To configure OES for dynamic groups:

  1. Open a browser and log onto the OES console as an administrator:

    https://<host>:<port>/asi

  2. Under the Administration Console node, click Resources to display a list of the currently defined resources in the Resources page as shown in Figure 31-9.

    Figure 31-9 Resources Page

    Description of Figure 31-9 follows
    Description of "Figure 31-9 Resources Page"

  3. Create a resource root by right-clicking the javaapi_app node and selecting Add Resource to display the Create Resource dialog. Name the resource WebCenterApp and select Binding as the Type as shown in Figure 31-10.

    Figure 31-10 Creating a Root Resource

    Description of Figure 31-10 follows
    Description of "Figure 31-10 Creating a Root Resource"

  4. Right-click WebCenterApp and create a new resource under it naming it WebCenterResource and selecting Resource as the Type as shown in Figure 31-11.

    Figure 31-11 Creating a Resource

    Description of Figure 31-11 follows
    Description of "Figure 31-11 Creating a Resource"

  5. Under the Resources node, click Privileges to display the Privileges page.

  6. Click New and create an action naming it browse as shown in Figure 31-12.

    Figure 31-12 Creating an Action

    Description of Figure 31-12 follows
    Description of "Figure 31-12 Creating an Action"

  7. Open the Identity node and click Roles to display the Roles page.

  8. Click New to create the dynamic roles using the Create Role dialog as shown in Figure 31-13.

    Figure 31-13 Creating the Dynamic Roles

    Description of Figure 31-13 follows
    Description of "Figure 31-13 Creating the Dynamic Roles"

  9. Open the Resources node and click Attributes to display the Resource Attributes page.

  10. Click New and use the Create Resource Attribute dialog to create resource attributes using the same name as the identity store attributes that are to be used in the constraints (for example, business_email or timezone) as shown in Figure 31-14. If Personalization attributes are to be used in the constraints then those attributes should also be created. Note that the attributes that are used as constraints in the Role Mapping policy cannot be empty in the identity store.

    Figure 31-14 Creating Resource Attributes

    Description of Figure 31-14 follows
    Description of "Figure 31-14 Creating Resource Attributes"

  11. Open the Policy node and click Role Mapping Policies to display the Role Mapping Policies page.

  12. Click New to display the Create Role Mapping Policy dialog and create role mapping policies and constraints using the identity store attributes or built-in system attributes (such as hour or day) as shown in Figure 31-15.

    Figure 31-15 Creating Role Mapping Policies

    Description of Figure 31-15 follows
    Description of "Figure 31-15 Creating Role Mapping Policies"

  13. Under the Policy node click Authorization Policies to display the Authorization Policies page.

  14. Click New to use the Create Authorization Policies dialog to create new authorization policies, or from the summary of authorization policies select a policy and click Edit to edit and provide details for the policy such resources and policy subjects as shown in Figure 31-16.

    Figure 31-16 Creating Authorization Policies

    Description of Figure 31-16 follows
    Description of "Figure 31-16 Creating Authorization Policies"

  15. Open the Authorization node under Service Control Managers, click ASIAuthorizationProvider and then open the Attribute Retrievers tab as shown in Figure 31-17.

    Figure 31-17 Attribute Retrievers Tab

    Description of Figure 31-17 follows
    Description of "Figure 31-17 Attribute Retrievers Tab"

  16. Click Configure a new Custom Attribute Retriever and create a custom attribute retriever named WebCenterP13nAttributeRetriever (oracle.webcenter.security.internal.plugins.oes.attributeretriever.WebCenterP13nAttributeRetriever), adding the class details as shown in Figure 31-18.

    Figure 31-18 Creating a Custom Attribute Retriever

    Description of Figure 31-18 follows
    Description of "Figure 31-18 Creating a Custom Attribute Retriever"

  17. Open the Role Mapping node under Service Control Managers, click ASIRoleMapperProvider and open the Bindings tab. Bind the WebCenterApp resource to the authorization provider as shown in Figure 31-19.

    Figure 31-19 Binding the Resource to the Authorization Provider

    Description of Figure 31-19 follows
    Description of "Figure 31-19 Binding the Resource to the Authorization Provider"

  18. Click Deployment, open the Configuration tab and distribute the configuration changes as shown in Figure 31-20.

    Figure 31-20 Distributing the Configuration Changes

    Description of Figure 31-20 follows
    Description of "Figure 31-20 Distributing the Configuration Changes"

  19. Open the Policy tab and distribute the policy changes as shown in Figure 31-21.

    Figure 31-21 Distributing the Policy Changes

    Description of Figure 31-21 follows
    Description of "Figure 31-21 Distributing the Policy Changes"

31.7.4.2 Configuring the OVD Plug-in

This section describes how to configure the OVD plug-in.

To configure the OVD plug-in:

  1. Go to the plugins/lib/pdpproxy directory and edit the file PDPProxyConfiguration.properties, providing the SSM configuration ID, the OES host name, the RMIS port, and the trust store location. Example values are shown below:

    SSMConfigID=JK_SM1
PDPTransport=RMI
PDPAddress=rmis://example.com:9300 (the use of SSL port is always recommended)
TrustStore=<OID_HOME>/asinst_1/OVD/ovd1/plugins/lib/keys/DemoTrust.jks

  2. Open the file ./config/OPMN/opmn/opmn.xml and change the java-options and java-classpath of the OVD process shown in the following sample, providing the correct OVD home path:

    <data id="java-options" value="-server -Xms256m -Xmx256m
-Dvde.soTimeoutBackend=0 -Didm.oracle.home=$ORACLE_HOME
-Dcommon.components.home=$ORACLE_HOME/../oracle_common
-Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml
-Djavax.net.ssl.trustStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/DemoTrust.jks
-Dpdp.configuration.properties.location=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/
pdpproxy/PDPProxyConfiguration.properties -Dwles.ssl.identityKeyAlias=wles-admin
-Dwles.ssl.identityKeyPasswordAlias=wles-admin
-Dwles.ssl.identityKeyStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/identity.jceks
-Dwles.ssl.trustedCAKeyStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/trust.jks
-Dwles.ssl.passwordFile=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/password.xml
-Dwles.ssl.passwordKeyFile=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/password.key"/>
 
<data id="java-classpath" value="$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/jsafeFIPS.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/jsafeJCEFIPS.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/scmapi.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/sslplus.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/ssladapter.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/asitools.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/webserviceclient.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/EccpressoCore.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/webservice.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/kodo-runtime.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/kodo-runtime.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/commons-pool-1.3.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/oes-ovd-plugin.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/xbean.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/antlr.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/log4j.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/api.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/asi_classes.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/framework.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/rmi-types.jar:
$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/rmi-ssm.jar:
$ORACLE_HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>

  3. Using your browser, open the Oracle Directory Service Manager (ODSM):

    http://host:port/odsm

    To determine the ODSM port use the opmnctl status command in the OID installation. The default port is 7005.

  4. Create an adapter of Type LDAP Adapter, providing the LDAP host and port details as shown in the example in Figure 31-22.

    Figure 31-22 Example LDAP Adapter

    Description of Figure 31-22 follows
    Description of "Figure 31-22 Example LDAP Adapter"

  5. Choose the DN and provide a mapping name for the DN.

  6. If you need to map to attributes other than the default, open the Plug-ins tab of the adapter and add the UserManagement adapter. For example, if you are using Active Directory as the backend directory server for OVD, add the UserManagement adapter providing the following parameter mappings:

    <param name="directoryType" value="ActiveDirectory"/>
<param name="mapAttribute" value="orclguid=objectguid"/>
<param name="mapAttribute" value="cn=sAMAccountName"/>
<param name="mapAttribute" value="uniquemember=member"/>
<param name="mapAttribute" value="OESRole=OESRole"/>
<param name="mapObjectclass" value="orclGroup=group"/>
<param name="mapObjectclass" value="groupofurls=group"/>
<param name="mapObjectclass" value="groupofuniquenames=group"/>
<param name="mapObjectclass" value="person=user"/>
<param name="mapRDNAttribute" value="uniquemember=member"/>

    For more information about configuring the UserManagement adapter, see the "UserManagement Plug-In" section in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

  7. Add the OES10gUserEntitlementsPlugin and add all the plug-in parameters as shown in the example below, replacing the host and port details for BLM and Personalization (p13n) for your local environment:

    <param name="ldap_group_basedn" value="cn=Groups,dc=us,dc=oracle,dc=com"/>
<param name="ldap_user_basedn" value="cn=Users,dc=us,dc=oracle,dc=com"/>
<param name="ldap_admin_user" value="cn=Administrator"/>
<param name="oes_admin_user" value="admin"/>
<param name="OrclOVDEncrypted_oes_admin_pass" value="<password>"/>
<param name="oes_config_name" value="JK_SM1"/>
<param name="oes_policy_domain" value="JK_SM1"/>
<param name="oes_resource_action" value="browse"/>
<param name="oes_resource_prefix" value="//app/policy/"/>
<param name="oes_resource_name" value="javaapi_app/WebCenterApp/WebCenterResource"/>
<param name="oes_resource_namespace" value="webcenterResource"/>
<param name="oes_roles_cache_interval" value="180000"/>
<param name="oes_action_namespace" value="webcenterAction"/>
<param name="p13n_admin_user" value="weblogic"/>
<param name="oes_p13n_debug" value="true"/>
<param name="OrclOVDEncrypted_p13n_admin_pass" value="<password>"/>
<param name="oes_blm_host" value="example.com"/>
<param name="oes_blm_port" value="7011"/>
<param name="oes_p13n_index_url" value="example.com/>
<param name="oes_p13n_prop_url" value="example.com"/>
<param name="ldap_eqmatch" value="equalityMatch"/>
<param name="ldap_loginattr" value="sAMAccountName"/>
<param name="ldap_loginattr" value="mail"/>
<param name="ldap_loginattr" value="cn"/>

    Note that passwords, once entered as plug-in parameters, are encrypted and then stored on the server.

  8. Restart the OVD process using the following command:

    ./opmnctl stopall startall

    Make sure that the OVD process restarts without any exceptions before continuing. If you encounter errors, you can turn on logging in the plug-in, by adding the following entry to:

    ORACLE_INSTANCE_HOME/config/OVD/ovd1/ovd-logging.xmlovd-logging.xml

    <logger name='oracle.webcenter.security.internal.plugins.ovd' level='TRACE:1' useParentHandlers='false'>
      <handler name='OVDHandler'/>
</logger>

  9. If SSL-enabled Personalization attributes are required, then import the certificate containing the public key of the Personalization server into the trust store on OVD, which is typically the JDK's cacerts file.

31.7.4.3 Configuring the Personalization Attributes

If you are using Personalization attributes as part of your constraints, then see the "Creating Property Sets and Property Definitions" section in Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper for how to configure them. For more information about Personalization, see Section 25, "Managing Personalization."

31.7.4.4 Configuring WebCenter Portal to Consume Dynamic Roles

This section describes how to prepare WebCenter Portal to consume dynamic roles defined in OES 10g.

By default, WebCenter Portal picks up only the static enterprise roles defined in the identity store. To use the dynamic roles defined within OES (Oracle Entitlements Server), you need to add the OVD plug-in as the authenticator. The OVD plug-in can then consolidate the static roles from the identity store and the dynamic roles from OES.

To configure WebCenter Portal to consume dynamic roles:

  1. Log in to the WebLogic Server Administration Console.

    For information on logging into the WebLogic Server Administration Console, see Section 1.13.2, "Oracle WebLogic Server Administration Console."

  2. Add an authenticator of Type Oracle Virtual Directory providing the OVD connection details, and the group base dn and user base dn.

    Leave the rest of the settings as their default values. Any directory-specific mapping should be done only in the adapter using the UserManagement plug-in. For more information about configuring the UserManagement adapter, see the "UserManagement Plug-In" section in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

  3. Restart all servers.

  4. Log onto WebCenter Portal as a user in OID and create a portal.

  5. Go to Add Members > Groups > Search and add the enterprise roles you want as members to a portal as shown in Figure 31-23.

    With OVD as the authenticator, you should see both dynamic (from OES) and static groups. In Figure 31-23, the dynamic groups are ESTUsers, DayUsers and ISTUsers, with the rest being static groups from OID.

    Figure 31-23 Adding Static and Dynamic Groups to a Portal

    Description of Figure 31-23 follows
    Description of "Figure 31-23 Adding Static and Dynamic Groups to a Portal"

31.8 Configuring Dynamic Groups for WebCenter Portal

A dynamic group is a static group that is dynamically populated. Dynamic groups can be assigned to roles and used within WebCenter Portal in the same way as static groups.

Within the application, WebCenter Portal does not distinguish between static and dynamic groups. Dynamic groups are configured entirely in the identity store (and their configuration is specific to the LDAP implementation being used), and exposed in the same manner as static groups (in fact a dynamic group can be a composite of a static member list and a dynamically determined membership).

The dynamic membership of the group is defined by setting the group's labeledURI attribute with an appropriate LDAP query filter. The query filter defines the set of users that will define the membership of the group.

For Oracle Internet Directory, you can create a dynamic group with an LDIF file and using the ldapadd command, or using the Oracle Directory Services Manager (ODSM). These two options are described in the following subsections:

31.8.1 Creating a Dynamic Group Using an LDIF File

To create the dynamic group using an LDIF file:

  1. Create an LDIF file with a text editor. The following example shows how a dynamic group can be defined that represents all users under the default user search base, with the title of "Manager":

    Example 31-1 Defining a Dynamic Group Using an LDIF File

    dn: cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=oracle,dc=com
labeleduri: ldap://myserver.example.com:12061/cn=users,dc=us,dc=mybiz,dc=com
??sub?(title=Manager)
description: Dynamic Group of Managers
cn: Managers
orclisvisible: true
objectclass: orclDynamicGroup
objectclass: orclGroup
objectclass: top
objectclass: groupOfUniqueNames
displayname: Managers
owner: cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com

    Note:

    .The labledURI syntax for an LDAP URL is defined in RFC 2255 (http://www.faqs.org/rfcs/rfc2255.html). In the example above, it is representing a search for any entry under the DN cn=users,dc=us,dc=mybiz,dc=com with the attribute title=Manager. This is to be done on the server myserver.example.com at LDAP port 12061 and using a subtree ("sub") search.

    A dynamic group can be defined on any attribute or condition that can be represented as an LDAP URL and defined in the labeledURI attribute. Dynamic groups can also be defined using the ConnectBy assertion, which is included in the orclDynamicGroup objectClass. Refer to Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for more information for this alternate approach.

  2. Save the file, and then update the OID server by issuing the ldapadd command. For example:

    Example 31-2 Updating OID Using the ldapadd Command

    ldapadd -h myserver -p 12061 -D cn=fmwadmin -w mybiz1 –f managers.ldif –v
add labeleduri: ldap://myserver.example.com:12061/cn=users,dc=us,dc=mybiz,dc=com??sub?(title=Manager)
add description:
Dynamic Group of Managers
add cn:
Managers
add orclisvisible:
true
add objectclass:
orclDynamicGroup
orclGroup
top
groupOfUniqueNames
add displayname:
Managers
add owner:
cn=fmwadmin,cn=users,dc=us,dc=mybiz,dc=com
adding new entry cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=mybiz,dc=com
modify complete

31.8.2 Creating a Dynamic Group Using the Oracle Directory Services Manager

To create a dynamic group using ODSM:

  1. Invoke Oracle Directory Services Manager (ODSM) and connect to the Oracle Internet Directory server.

    Refer to the "Using Oracle Directory Services Manager" chapter in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for information on invoking and using the Oracle Directory Services Manager.

  2. From the Go to list, select Data Browser.

  3. Click the New Entry icon in the data browser.

  4. Provide the DN and add the objectclasses orclDynamicGroup and groupOfUniqueNames.

  5. On the Mandatory Properties tab, provide the CN attribute.

  6. On the Optional Properties tab, provide the attributes for labeleduri.

  7. Click OK to complete the definition of the dynamic group.

When you refresh the tree view you'll see the new group that you created. Note that group members will not be shown in ODSM.

31.9 Configuring the REST Service Identity Asserter

This section describes how to configure an identity asserter for the REST service. For the REST service, including REST service APIs, to be used with WebCenter Portal or Portal Framework applications requires that an identity asserter be configured for it in the WebCenter domain identity store. The following sections show how to configure OPSS Trust Service instances and identity asserters for Oracle WebLogic Server.

This section contains the following subsections:

31.9.1 Understanding the REST Service Instance and Identity Asserter

Although WebCenter Portal and Portal Framework applications, and other Oracle WebLogic applications, can use REST APIs to display information the way they need to, since such calls originate from the mid-tier, users will be prompted again to provide login credentials. To overcome this, we use perimeter authentication where the user identity is propagated in the HTTP header and asserted using the OPSS Trust Service Asserter.

In order to successfully propagate user identity from one application to another application, these applications must be using correctly configured Trust Service instances. Figure 31-24 shows the different components involved in the identity propagation and assertion.

Figure 31-24 REST Identity Propagation and Assertion

Description of Figure 31-24 follows
Description of "Figure 31-24 REST Identity Propagation and Assertion"

The following depicts the sequence of events involved in REST identity propagation and assertion:

  1. End clients (browsers, smart phone apps) connect to a WebCenter Portal or Portal Framework application.

  2. The application page queries data from REST APIs and builds its own UI on top and therefore needs to call the REST end point.

  3. The application calls WebCenter Security API (WCSecurityUtility.issueTrustServiceSecurityToken) to issue the token used for securely propagating the user identity. The token is generated using the Trust Service Embedded Provider. Generated tokens are compressed to optimize token size and then BASE64-encoded to ensure that the token can be safely transported using an HTTP header.

  4. The application takes the issued token and adds it against the "Authorization" security header. The client then dispatches the token as part of its call to the REST URI.

  5. WebLogic Server checks if the identity asserter exists for the given token type.

  6. The identity asserter parses and verifies that the token is using OPSS Trust Service APIs.

  7. The asserter maps the username to a WLS username, a user Subject is established, and the call ends up on the REST application.

  8. The REST application recognizes that the user is already an authenticated user and sends a response. The WebCenter Portal or Portal Framework application uses the response and shows the page to the end user.

31.9.2 Setting up the Client Application

This section describes how to configure the client for a REST service identity asserter.

To configure the client for a REST service identity asserter:

  1. Using JDeveloper, create the client application.

    The client application could be a JSE or a servlet application. The following example shows the skeleton of a sample client application.

    // The authenticated username
// String user = "weblogic"; 
// URL of the target application
URL url = "http://host:port/destinationApp"; 
//-----------------------------------------
 
String b64EncodedToken = WCSecurityUtility.issueTrustServiceSecurityToken()
 
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setDoOutput(true);
connection.setReadTimeout(10000);
connection.setRequestProperty("Authorization", AUTH_TYPE_NAME + " " + b64EncodedToken); 
connection.connect();
BufferedReader rd = new BufferedReader(new InputStreamReader(
    connection.getInputStream()));
StringBuilder sb = new StringBuilder();
 
String line = null;
while ((line = rd.readLine()) != null) {
    sb.append(line);
}
connection.disconnect();
System.out.println(sb.toString());

  2. Create and configure the keystore.

    Create the keystore for the domain and then configure WebLogic Server for the identity asserter. The keystore is first provisioned for a client certificate and private key. The client certificate is then exported and imported into a trust key store.

    1. Create the keystore as shown in Section 36.1.2.1, "Creating the WebCenter Portal Domain Keystore."

    2. Configure the keystore as shown in Section 36.1.2.2, "Configuring the Keystore with WLST," or Section 36.1.2.3, "Configuring the Keystore Using Fusion Middleware Control."

  3. Edit the jps-config.xml configuration file.

    1. Navigate to your DOMAIN_HOME/config/fmwconfig directory and open the jps-config.xml file in a text editor.

    2. Make sure you have the following in the jps-config.xml file:

      <serviceInstance name="keystore" provider="keystore.provider" location="./default-keystore.jks">

    3. Modify the trust.provider.embedded propertySet node as below:

          <propertySets>
        <propertySet name="trust.provider.embedded">
             ... existing entries
            <property value="orakey" name="trust.aliasName"/>
            <property value="orakey" name="trust.issuerName"/>
        </propertySet>
    </propertySets>

      Where:

      trust.aliasName is the alias looked up by the identity asserter in the configured keystore for a certificate with which the asserter verifies the issued trust token.

      trust.issuerName is the alias looked up by the token issuer to look up the private key with which the trust token is issued/signed.

  4. If the client and REST applications are in different domains, repeat these steps for both domains.

  5. Restart all servers.

31.9.3 Configuring the WLS Trust Service Asserter

This section describes how to configure the WebLogic Server Trust Service asserter.

To configure the WebLogic Server Trust Service asserter:

  1. Log into the WebLogic Administration Console as an administrator.

  2. Navigate to Security Realms -> myrealm.

  3. Open the Providers tab, and then the Authentication subtab.

    The Create a New Authentication Provider page displays.

  4. Enter the Name of the new asserter (for example, TrustServiceIdAsserter).

  5. Select TrustServiceIdentityAsserter as the asserter Type.

    This asserter calls the Trust Service APIs to decode and validate the token from the incoming request, and pass the username to the WebLogic for establishing the asserted subject.

  6. Click OK to save your changes.

  7. Restart all managed servers.