Configuring the Identity Store

25 Configuring the Identity Store

Associate the identity store with an external LDAP instead of the default embedded LDAP identity store, configure an LDAP server for Oracle WebCenter Content Server, and use Oracle Identity Cloud Service as the identity store for WebCenter Portal.

Note:

Beginning with 12c (12.2.1.3.0), Oracle WebCenter Portal has deprecated support for Jive features (announcements and discussions). If you are upgrading from a prior release, these features remain available in your existing installations that are being upgraded.

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.

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.

Topics:

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, 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_Portal server, Content Server, and Collaboration server must all be configured to use the same external LDAP server.

It is recommended that you set a strong password policy on the LDAP server for the identity store. Oracle recommends that user passwords meet the following requirements:

Passwords should not contain the user's account name or parts of the user's full name that exceed two consecutive characters.
Passwords must be at least six characters in length or the number of characters specified in the minimum password length policy setting.
Enforce password history policy setting, which determines the number of unique new passwords that have to be associated with a user account before an old password can be reused. The setting for this value can be between 0–24 (if this value is set to 0, Enforce password history is disabled; a higher value, such as 24, is preferable to prevent security vulnerability through password reuse).
Passwords must contain characters from at least three of the following four categories: English uppercase alphabet characters (A to Z), English lowercase alphabet characters (a to z), base 10 digits (0 to 9), non-alphanumeric characters (for example, !$#,%) .

For the GUID attribute for other supported LDAPs, see Configuring the GUID Attribute for External LDAP Identity Stores. For other user attribute mappings for supported LDAP servers, see the User and Role API Reference in Securing Applications with Oracle Platform Security Services.

Note:

To use an existing database (i.e., not a default database store created when WebCenter Portal is installed in its default configuration) for the identity store, you must either use OVD or write a custom provider based on the User and Role API. Note that LibOVD should not be used in conjunction with a database identity store.

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:

Log in to the WebLogic Server Administration Console.

For information on logging into the WebLogic Server Administration Console, see Oracle WebLogic Server Administration Console.
In the Domain Structure pane click Security Realms.

The Summary of Security Realms pane displays.
In the Name column, click the realm for which you want to reassociate the identity store.

The Realm Settings pane displays.
Open the Providers tab.

The Providers Settings pane displays.
Click New to add a new provider.

The Create a New Authentication Provider pane displays.
Enter a name for the provider (for example OIDAuthenticator for a provider that authenticates the user for the Oracle Internet Directory).
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.
Note:
If using iPlanet, set the virtualize property to true in ./user_projects/domains/soainfra/config/fmwconfig/jps-config.xml.
```
<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
 <property name="idstore.config.provider" value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/>
 <property name="CONNECTION_POOL_CLASS" value="oracle.security.idm.providers.stdldap.JNDIPool"/>
 <property name="virtualize" value="true"/>
 <property name="OPTIMIZE_SEARCH" value="true"/>
</serviceInstance>
```
Click OK to save your settings.

The Settings pane displays with the new authentication provider.
In the list of Authentication Providers, click the newly created provider.

The Settings Pane for the new authentication provider displays.
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.
Click Save to save this setting.
Open the Provider Specific tab to enter the details for the LDAP server.

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 OPSS System and Configuration Properties appendix in Securing Applications with Oracle Platform Security Services.

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

Click Save.
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 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.
Restart the Administration Server and the managed server for the changes to take effect.

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 User and Role API Reference section in Securing Applications with Oracle Platform Security Services. See also Mapping User Attributes to LDAP Directories in Securing Applications with Oracle Platform Security Services. Note that as shown in the table in Mapping User Attributes to LDAP Directories, not all attributes are available across all LDAP servers, including the embedded LDAP server that comes with WebLogic Server (WLS).

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

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 Securing Applications with Oracle Platform Security Services.

For Oracle Internet Directory, users are typically managed using ODSM (described in Managing Directory Entries in Administering Oracle Internet Directory).

Note:

If you are planning to reassociate your identity store with an external LDAP, perform that step first (as described in 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 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:

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:

Log in to the WebLogic Server Administration Console.

For information on logging into the WebLogic Server Administration Console, see Oracle WebLogic Server Administration Console.
In the Domain Structure pane, click Security Realms.

The Summary of Security Realms pane displays.
In the Name column, click the realm to which you want to add users.

The Realm Settings pane displays.
Click the Users and Groups tab to display the list of current users.
Click New to add a new user.
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:

< >, #, |, &, ?, ( ), { }
In the Description field, enter a description for the user (for example, the user's full name).
From the Provider drop-down menu, select DefaultAuthenticator.
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.
Reenter the password in the Confirm Password field.
Click OK to save your changes and add the user.

The user should now appear in the list of users.

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:

Log in to the WebLogic Server Administration Console.
In the Domain Structure pane, click WC_Domain.
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.
Enter a new password in the Credential field, and reenter it in the Confirm Credential field.
Click Save to save your settings.
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 25-1.

Figure 25-1 Embedded LDAP Directory Information Tree

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

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

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 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 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 Changing the Administrator Group Name.

Note:

Since OWSM is dependent on the OracleSystemUser and OracleSystemGroup entities, which are provided by the DefaultAuthenticator, to get OWSM working after the embedded LDAP is removed you’ll need to modify the default user. For more information, see Modifying the Default User in Securing Web Services and Managing Policies with Oracle Web Services Manager.

This section includes the following topics:

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

Select a user account from the external LDAP to be the administrator for the discussions server.
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 Adding Users to the Embedded LDAP Identity Store.
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.
Click Settings > Admins/Moderators.

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

Figure 25-2 Admins & Moderators Page

Description of "Figure 25-2 Admins & Moderators Page"
Click Grant New Permissions.

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

Figure 25-3 Grant New Permissions Pane

Description of "Figure 25-3 Grant New Permissions Pane"
Grant System Admin privileges to the user you created, as shown in Figure 25-4.

Figure 25-4 Grant New Permissions Pane with New User

Description of "Figure 25-4 Grant New Permissions Pane with New User"
Click System > System Properties.

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

Figure 25-5 Jive Properties Page

Description of "Figure 25-5 Jive Properties Page"
Check that the properties marked in red have been added and are set as shown in Figure 25-5.
Log in to the WebLogic Server Administration Console.

For information on logging in to the WebLogic Server Administration Console, see Oracle WebLogic Server Administration Console.
In the Domain Structure pane, click Security Realms.

The Summary of Security Realms pane displays.
In the Name column, click the realm for which you want to change the administrator group name.

The Realm Settings pane displays.
Select the Providers tab and the Authentication subtab, 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 25-6:

Figure 25-6 Providers Tab with Reordered Authentication Providers

Description of "Figure 25-6 Providers Tab with Reordered Authentication Providers"
Restart the domain Administration server and discussions server.
If you have not done so already, create a user in the external LDAP and grant that user the WebCenter Portal Administrator role (see Granting the WebCenter Portal Administrator Role).

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:

Log in to the WebLogic Server Administration Console.

For information on logging into the WebLogic Server Administration Console, see Oracle WebLogic Server Administration Console.
In the Domain Structure pane, click Security Realms.

The Summary of Security Realms pane displays.
In the Name column, click the realm for which you want to change the administrator group name.

The Realm Settings pane displays.
Open the Roles and Policies tab, and then the Realm Roles subtab.

The Realm Roles settings pane displays.
Expand the Global Roles node, and then the Roles node.
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.
Click Add Conditions to add a different group name.

The Edit Global Role - Predicate List page displays.
Select Group from the Predicate List list and click Next.

The Edit Global Role - Arguments page displays.
Enter the name for the new administrator group and click Add.
Select the pre-existing administrator group and click Remove to delete it leaving the new one you've selected in its place.
Click Finish to save your changes.

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

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

The WebCenter Content server must be configured to use the same identity store LDAP server as WebCenter Portal. For more information on configuring WebCenter Content, see Managing Connections to Oracle WebCenter Content Server and also see Configuring the LDAP Identity Store Service in Securing Applications with Oracle Platform Security Services.

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 Users Cannot Self-Register when WebCenter Portal Configured with Active Directory.

This section contains the following topics:

Configuring libOVD for Identity Stores with Complete User Profiles

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

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

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

Configuring libOVD for Identity Stores with Partial User Profiles

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

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

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.

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.

Restoring the Single Authenticator

You can restore the single authenticator by removing the Join Adapter rule, thereby backing out the configuration done in 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.

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 topics:

Note:

Dynamic groups is not supported for LDAPs other than OID unless OVD is used.

Creating a Dynamic Group Using an LDIF File

To create the dynamic group using an LDIF file:

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: 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 theAdministering Oracle Internet Directory for more information for this alternate approach.

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

Example: 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

Creating a Dynamic Group Using the Oracle Directory Services Manager

To create a dynamic group using ODSM:

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

Refer to Using Oracle Directory Services Manager in Administering Oracle Internet Directory for information on invoking and using the Oracle Directory Services Manager.
From the Go to list, select Data Browser.
Click the New Entry icon in the data browser.
Provide the DN and add the objectclasses orclDynamicGroup and groupOfUniqueNames.
On the Mandatory Properties tab, provide the CN attribute.
On the Optional Properties tab, provide the attributes for labeleduri.
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.

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 applications requires that an identity asserter be configured for it in the WebCenter domain identity store. The following topics show how to configure OPSS Trust Service instances and identity asserters for Oracle WebLogic Server.

This section contains the following topics:

Understanding the REST Service Instance and Identity Asserter

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

Figure 25-7 REST Identity Propagation and Assertion

Description of "Figure 25-7 REST Identity Propagation and Assertion"

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

End clients (browsers, smart phone applications) connect to a WebCenter Portal application.
The application page queries data from REST APIs and builds its own UI on top and therefore needs to call the REST end point.
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.
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.
WebLogic Server checks if the identity asserter exists for the given token type.
The identity asserter parses and verifies that the token is using OPSS Trust Service APIs.
The asserter maps the username to a WLS username, a user Subject is established, and the call ends up on the REST application.
The REST application recognizes that the user is already an authenticated user and sends a response. The WebCenter Portal uses the response and shows the page to the end user.

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:

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());

Create and configure the keystore as shown in Creating the WebCenter Portal Domain Keystore, 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..
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.
If the client and REST applications are in different domains, repeat these steps for both domains.
Restart all servers.

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:

Log into the WebLogic Administration Console as an administrator.
Navigate to Security Realms -> myrealm.
Open the Providers tab, and then the Authentication subtab.

The Create a New Authentication Provider page displays.
Enter the Name of the new asserter (for example, TrustServiceIdAsserter).
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.
Click OK to save your changes.
Restart all managed servers.