30 Configuring the Identity Store

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

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

• Create an LDIF File

• Add the Users

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

Figure 30-1 Embedded LDAP Directory Information Tree

Description of "Figure 30-1 Embedded LDAP Directory Information Tree"

The following example shows an LDIF file with the attributes that are displayed in the Spaces 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: MyPassword1
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.

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 "Oracle Internet Directory Data Management Tools" in the Oracle Identity Management User Reference. For a complete list of user attribute mappings for LDAP servers supported by WebCenter Portal, see "Mapping User Attributes to LDAP Directories" 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

30.4.1 Migrating WebCenter Portal's Discussions Server to Use an External LDAP

If you've installed Oracle WebCenter Portal's Discussions Server and choose not to move the administrator account to an external LDAP (as described in Section 30.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 30.3, "Adding Users to the Embedded LDAP Identity Store."

3. Log in to the Oracle WebCenter Portal's Discussion 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 30-2).

   Figure 30-2 Admins & Moderators Page

   
   Description of "Figure 30-2 Admins & Moderators Page"
   
   

5. Click Grant New Permissions.

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

   Figure 30-3 Grant New Permissions Pane

   
   Description of "Figure 30-3 Grant New Permissions Pane"
   
   

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

   Figure 30-4 Grant New Permissions Pane with New User

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

7. Click System > System Properties.

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

   Figure 30-5 Jive Properties Page

   
   Description of "Figure 30-5 Jive Properties Page"
   
   

8. Check that the properties marked in red have been added and are set as shown in Figure 30-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 30-6:

    Figure 30-6 Providers Tab with Reordered Authentication Providers

    
    Description of "Figure 30-6 Providers Tab with Reordered Authentication Providers"
    
    

13. Restart the domain Administration Server and discussions server.

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

30.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."

30.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 $MWHOME/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 stores 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.

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

30.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 30-7 shows the login process for a topology configured with OES and the OVD plug-in.

Figure 30-7 Login Process

Description of "Figure 30-7 Login Process"

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

Figure 30-8 Group Query

Description of "Figure 30-8 Group Query"

30.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.6.0)”in Oracle Fusion Middleware Installation Guide for Oracle Identity Management. Configure OVD by running config.sh as described in the section "Configuring Oracle Virtual Directory (OVD)" 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 Chapter 20, "Managing Personalization for WebCenter Portal."

30.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. Through OVD, OES data can be exposed by means of an OVD custom adaptor in a way that it can be consumed by Spaces. 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:

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

30.7.4 Configuring Dynamic Roles

This section describes how to configure your Spaces 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 30.7.2, "Prerequisites to Configuring Dynamic Roles") and the OVD plug-in (described in Section 30.7.3, "Installing the OVD Plug-in").

This section contains the following subsections:

• Section 30.7.4.1, "Configuring OES"

• Section 30.7.4.2, "Configuring the OVD Plug-in"

• Section 30.7.4.3, "Configuring the Personalization Attributes"

• Section 30.7.4.4, "Configuring the Spaces Application to Consume Dynamic Roles"

30.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 30-1 Defining a Dynamic Group Using an LDIF File

   dn: cn=managers,cn=portal.070720.104824.056918000,cn=groups,dc=us,dc=oracle,dc=comlabeleduri: ldap://myserver.example.com:12061/cn=users,dc=us,dc=mybiz,dc=com??sub?(title=Manager)description: Dynamic Group of Managerscn: Managersorclisvisible: trueobjectclass: orclDynamicGroupobjectclass: orclGroupobjectclass: topobjectclass: groupOfUniqueNamesdisplayname: Managersowner: 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 the 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 30-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
   

30.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 section "Using Oracle Directory Services Manager" in the 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.

30.9.1 Understanding the REST Service Instance and Identity Asserter

Although WebCenter Portal 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 30-24 shows the different components involved in the identity propagation and assertion.

Figure 30-24 REST Identity Propagation and Assertion

Description of "Figure 30-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 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 WebCenter Portal 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 WebCenter Portal 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 application uses the response and shows the page to the end user.

30.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 + " " + b64tok);
   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 35.1.2.1, "Creating the WebCenter Portal Domain Keystore."

   2. Configure the keystore as shown in Section 35.1.2.2, "Configuring the Keystore with WLST," or Section 35.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.

   2. Open the jps-config.xml file in a text editor.

   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.

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