30 Configuring the Policy and Credential Store

For production environments, you must reassociate your policy store with an external LDAP (either Oracle Internet Directory 11gR1 or 10.1.4.3), or a database. Note that when using an external LDAP-based store, the credential store and policy store must be configured to use the same LDAP server. The identity store can, however, use any of the other supported LDAP servers; it does not need to use the same LDAP server as the policy and credential stores.

Reassociating the policy and credential store with OID consists of creating a root node in the LDAP directory, and then reassociating the policy and credential store with the OID server using Fusion Middleware Control, or from the command line using WLST. Reassociating the policy and credential store with a database consists of setting up the schema and database connection in the RCU, and then migrating the policy and credential store to the database from the command line using WLST.

Caution:

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

• jps-config.xml

• system-jazn-data.xml

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

This chapter contains the following sections:

• Section 30.1, "Creating a root Node"

• Section 30.2, "Reassociating the Credential and Policy Store Using Fusion Middleware Control"

• Section 30.3, "Reassociating the Credential and Policy Store Using WLST"

• Section 30.4, "Reassociating the Policy and Credential Store with a Database"

• Section 30.5, "Managing Credentials"

• Section 30.6, "Managing Users and Application Roles"

• Section 30.7, "Configuring Self-Registration By Invitation in the Spaces Application"

• Section 30.8, "Setting the Policy Store Refresh Interval and Other Cache Settings"

Audience

The content of this chapter is intended for Fusion Middleware administrators (users granted the 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."

30.1 Creating a root Node

The first step in reassociating the policy and credential store with OID, is to create an LDIF file in the LDAP directory and add a root node under which all data is added. After creating the file and adding the node, continue by reassociating the store using either Fusion Middleware Control or WLST.

To create a root node:

1. Create a root node by adding the following to an LDIF file (for example, root.ldif) in the LDAP directory:

   dn: cn=root_webcenter_xxxx
   cn: root_webcenter_xxxx
   objectclass: top
   objectclass: orclcontainer
   

   Where xxxx is a string (for example, the server name) that uniquely identifies the node.

2. Add this node to the directory by running the following LDAP command from your LDAP installation directory:

   OID_ORACLE_HOME/as_1/bin/ldapadd -h ldap_host_name -p ldap_port -D cn=orcladmin -w password -v -f root.ldif
   

   where:

   • OID_ORACLE_HOME is the directory in which LDAP is installed

   • ldap_host_name is the host name of the OID server

   • ldap_port is the OID server port number

   • password is the password with which to access the OID server

   Note that each root container must have a unique name.

30.2 Reassociating the Credential and Policy Store Using Fusion Middleware Control

Before reassociating the policy and credential store with Oracle Internet Directory, you must first have created the root node as described in Section 30.1, "Creating a root Node."

To reassociate the policy and credential store with the OID server:

1. Open Fusion Middleware Control and log in to your target instance.

   For information on logging into Fusion Middleware Control, see Section 6, "Starting Enterprise Manager Fusion Middleware Control."

2. In the Navigation pane, click your domain.

   When initially installed, Spaces and Enterprise Manager are already associated and deployed in the same domain.

3. From the WebLogic Domain menu, select Security > Security Provider Configuration.

   The Security Provider Configuration page displays (see Figure 30-1).

   Figure 30-1 Security Provider Configuration Page

   
   Description of "Figure 30-1 Security Provider Configuration Page"
   
   

4. On the Security Provider Configuration page, click Change Store Type to add the new Oracle Internet Directory provider (or select the store and click Edit if the store already exists and you want to change its parameters).

   The Configure Security Stores page displays (see Figure 30-2).

   Figure 30-2 COnfigure Security Store Page

   
   Description of "Figure 30-2 COnfigure Security Store Page"
   
   

5. Select Oracle Internet Directory as the Store Type.

6. Under LDAP Server Details, enter the Host name and LDAP Port for Oracle Internet Directory.

7. Set the Connect DN field to cn=orcladmin, and enter the associated password in the Password field.

8. Under Root Node Details, set the Root DN field to the one you added to the root.ldif file (for example, cn=root_webcenter_abcd99). Be sure to include the cn=.

9. Click OK to begin the reassociation. Restart the WebLogic server when prompted after migration.

30.3 Reassociating the Credential and Policy Store Using WLST

Before reassociating the policy and credential store with Oracle Internet Directory, you must first have created the root node as described in Section 30.1, "Creating a root Node."

1. Start WLST as described in Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

2. Connect to the Administration Server for the target domain with the following command:

   connect('username>,'password', 'host_id:port')
   

   where:

   • username is the administrator account name used to access the Administration Server (for example, weblogic)

   • password is the administrator password used to access the Administration Server (for example, weblogic)

   • host_id is the server ID of the Administration Server (for example, example.com)

   • port is the port number of the Administration Server (for example, 7001).

3. Reassociate the policy and credential store using the reassociateSecurityStore command:

   reassociateSecurityStore(domain="domain_name", admin="admin_name", password="password", 
   ldapurl="ldap_uri", servertype="ldap_srvr_type", jpsroot="root_webcenter_xxxx")
   

   Where:

   • domain_name specifies the domain name where reassociation takes place.

   • admin_name specifies the administrator's user name on the LDAP server. The format is cn=usrName.

   • password specifies the password associated with the user specified for the argument admin.

   • ldap_uri specifies the URI of the LDAP server. The format is ldap://host:port, if you are using a default port, or ldaps://host:port, if you are using a secure LDAP port. The secure port must have been configured to handle an anonymous SSL connection, and it is distinct from the default (non-secure) port.

   • ldap_srvr_type specifies the kind of the target LDAP server. Specify OID for Oracle Internet Directory.

   • root_webcenter_xxxx specifies the root node in the target LDAP repository under which all data is migrated. Be sure to include the cn=. The format is cn=nodeName.

   All arguments are required. For example:

   reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode")
   

30.4 Reassociating the Policy and Credential Store with a Database

As well as using an LDAP server, such as OID, for your policy and credential store, you can also reassociate the policy and credential store with an Oracle database. Prior to reassociating the policy and credential store with a database, you should have:

• Installed the RCU and the OPSS schema

• Installed an Oracle database (Oracle RDBMS version 10.2.0.4+, 11.1.0.7+, or 11.2.0.1+)

• Installed WebLogic Server

• Created a domain

  For instructions on how to create a new domain, see "Creating a New Domain" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

• Created a data source

  For instructions on how to create a data source, see "Creating a JDBC Data Source" in the Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.

• Backed up your <DOMAIN>/config/fmwconfig/jps-config.xml file.

Follow the steps below to configure a database as your policy and credential store:

1. Associate the schema and database connection. For information about how to associate the schema and database connection, see Section 7.1.5, "Creating and Registering the Metadata Service Repository."

2. Back up the jps-config.xml and bootstrap/cwallet.sso files (both are in the domain_home/config/fmwconfig folder).

3. Migrate the policy and credential store to the database using the following WLST command:

   reassociateSecurityStore(domain="your_domain", datasourcename="your_data_source", servertype="DB_ORACLE", jpsroot="cn=jpsTestNode")
   

   Where datasourcename is the JNDI name for the OPSS data source you just created. Note also that jpsroot is the parameter through which the policy store gets striped, and the value of this parameter should be unique to the policy store. For more information about using the reassociateSecurityStore command, see "reassociateSecurityStore" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

30.5 Managing Credentials

Administrators can manage credentials for the WebCenter Portal domain credential store using Fusion Middleware Control and WLST commands. For more information, see "Managing Credentials" in the Oracle Fusion Middleware Application Security Guide.

30.6 Managing Users and Application Roles

This section describes how you can use Fusion Middleware Control, WLST, and the runtime administration pages in Spaces and Framework applications to manage users and application roles.

This section contains the following subsections:

• Section 30.6.1, "Granting the Spaces Administrator Role"

• Section 30.6.2, "Granting Application Roles"

• Section 30.6.3, "Using the Runtime Administration Pages"

30.6.1 Granting the Spaces Administrator Role

Spaces only recognizes users in the identity store that is mapped by the first authenticator. Since the Spaces 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 Spaces, you must also create a user in that LDAP and grant that user the Spaces Administrator role.

You can grant a user the Spaces Administrator role using Fusion Middleware Control or WLST as shown below in the sections on:

• Section 30.6.1.1, "Granting the Spaces Administrator Role Using Fusion Middleware Control"

• Section 30.6.1.2, "Granting the Spaces Administrator Role Using WLST"

For more information, see "Granting the Administrator Role to a Non-Default User" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal.

30.6.1.1 Granting the Spaces Administrator Role Using Fusion Middleware Control

This section describes how to grant the Spaces administrator role to a user account other than the default "weblogic" account.

To grant the Spaces Administrator role using Fusion Middleware Control:

1. Log into Fusion Middleware Control and navigate to the Spaces home page.

   See Section 6.2, "Navigating to the Home Page for the Spaces Application."

2. From the WebCenter Portal menu, select Security -> Application Roles.

   The Application Roles page displays (see Figure 30-3).

   Figure 30-3 Application Roles Page

   
   Description of "Figure 30-3 Application Roles Page"
   
   

3. Search for the Spaces Administrator role:

   1. Select Select Application Stripe to Search.

   2. Select webcenter.

   3. In the Role Name field, enter the following internal identifier for the Administrator role, and then click the Search (arrow) icon:

      s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator
      

   The search should return s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator, which is the administrator role identifier.

4. Click the administrator role identifier in the Role Name column.

   The Edit Application Role page displays (see Figure 30-4).

   Figure 30-4 Edit Application Role Page

   
   Description of "Figure 30-4 Edit Application Role Page"
   
   

5. Click Add User.

   The Add User pop-up displays (see Figure 30-5).

   Figure 30-5 Add User Pop-up

   
   Description of "Figure 30-5 Add User Pop-up"
   
   

6. Use the Search function to search for the user to assign the Administrator role to.

7. Use the arrow keys to move the user from the Available Users column to the Selected Users column, and click OK.

8. On the Edit Application Role page, click OK.

9. To remove the weblogic role, on the Edit Application Role page under Users, click weblogic and the click Delete.

10. Restart the WC_Spaces managed server.

    When you login to Spaces, the Administration link should appear and you should be able to perform all administrator operations.

30.6.1.2 Granting the Spaces Administrator Role Using WLST

To grant the Spaces Administrator role to another user using WLST:

1. Start WLST as described in Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

2. Connect to the Spaces Administration Server for the target domain with the following command:

   connect('user_name','password, 'host_id:port')
   

   Where:

   • user_name is the name of the user account with which to access the Administration Server (for example, weblogic)

   • password is the password with which to access the Administration Server

   • host_id is the host ID of the Administration Server

   • port is the port number of the Administration Server (for example, 7001).

3. Grant the Spaces administrator application role to the user in Oracle Internet Directory using the grantAppRole command as shown below:

   grantAppRole(appStripe="webcenter", appRoleName="s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator",
   principalClass="weblogic.security.principal.WLSUserImpl", principalName="wc_admin")
   

   Where wc_admin is the name of the administrator account to create.

4. To test the new account, log into Spaces using the new account name.

   The Administration link should appear, and you should be able to perform all administrator operations.

5. After granting the Spaces Administrator role to new accounts, remove this role from accounts that no longer need or require it using the WLST revokeAppRole command. For example, if Spaces was installed with a different administrator user name than weblogic, the administrator role should be given to that user and should be revoked from the default weblogic.

   revokeAppRole(appStripe="webcenter", appRoleName="s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator", 
   principalClass="weblogic.security.principal.WLSUserImpl", principalName="weblogic")
   

30.6.2 Granting Application Roles

This section describes how to add users to application roles using Fusion Middleware Control and WLST commands.

This section contains the following subsections:

• Section 30.6.2.1, "Granting Application Roles Using Fusion Middleware Control"

• Section 30.6.2.2, "Granting Application Roles Using WLST"

30.6.2.1 Granting Application Roles Using Fusion Middleware Control

This section describes how to grant an application role to users using Fusion Middleware Control.

1. Log in to Fusion Middleware Control and navigate to the home page for Spaces or your Framework application. For more information, see:

   • Section 6.2, "Navigating to the Home Page for the Spaces Application"

   • Section 6.3, "Navigating to the Home Page for Framework Applications"

2. From the WebCenter Portal menu, select Security -> Application Roles.

   The Application Roles page displays (see Figure 30-6).

   Figure 30-6 Application Roles Page

   
   Description of "Figure 30-6 Application Roles Page"
   
   

3. Search for the Spaces or Framework application role:

   1. Select Select Application Stripe to Search.

   2. Sect the application stripe (webcenter for Spaces).

   3. In the Role Name field, enter the name of the role you are looking for (for example, appConnectionManager), and then click the Search (arrow) icon:

      If you are not sure of the name, enter a partial search term or leave the field blank to display all the application roles.

4. Click the role identifier in the Role Name column.

   The Edit Application Role page displays (see Figure 30-7).

   Figure 30-7 Edit Application Role Page

   
   Description of "Figure 30-7 Edit Application Role Page"
   
   

5. Click Add User.

   The Add User pop-up displays (see Figure 30-8).

   Figure 30-8 Add User Pop-up

   
   Description of "Figure 30-8 Add User Pop-up"
   
   

6. Use the Search function to search for the user to assign the application role to.

7. Use the arrow keys to move the user from the Available Users column to the Selected Users column, and click OK.

8. On the Edit Application Role page, click OK.

9. Restart the managed server on which Spaces or the Framework application is deployed (for Spaces this is always WC_Spaces).

30.6.2.2 Granting Application Roles Using WLST

Use the grantAppRole command to grant an application role to a user. For syntax and usage information, see "grantAppRole" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

30.6.3 Using the Runtime Administration Pages

Spaces provides a Security tab from which an administrator can define application roles and grant application roles to users defined in the identity store. For information about managing users and application roles in Spaces, see "Managing Users and Roles for WebCenter Portal: Spaces" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Caution:

The "Allow Password Change" property, which specifies whether users can change their passwords within Spaces, should be carefully controlled for corporate identity stores. Spaces administrators can set this property from the Profile Management Settings page in Spaces. For more information, see "Configuring Profiles" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Framework applications can provide a similar Security tab for application administrators. For details, see Section 36.4, "Managing Application Members and Roles." For more information about role-mapping for ADF-security based Framework applications, see the section What You May Need to Know About Application Roles and Enterprise Roles in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

30.7 Configuring Self-Registration By Invitation in the Spaces Application

Spaces supports self-registration by invitation, as described in "Enabling Self-Registration By Invitation-Only" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces. The self-registration 'by-invitation' feature requires that the WebCenter Portal domain credential store contain the following password credentials:

• map name = o.webcenter.security.selfreg

• key= o.webcenter.security.selfreg.hmackey

• user name = o.webcenter.security.selfreg.hmackey

To enable 'self-registration by invitation' in Spaces, use Fusion Middleware Control or the WLST command createCred to create the password credentials detailed above. For example:

createCred(map="o.webcenter.security.selfreg", key="o.webcenter.security.selfreg.hmackey", type="PC", 
user="o.webcenter.security.selfreg.hmackey", password="<password>", url="<url>", port="<port>", [desc="<description>"])

For more information, see "Managing Credentials" in the Oracle Fusion Middleware Application Security Guide.

30.8 Setting the Policy Store Refresh Interval and Other Cache Settings

This section provides recommended cache settings that should be configured after installation. Although settings for cache sizes and maximum group hierarchies should be based on your specific environment, the following sections provide recommendations that you can use as a starting point. For a complete list of tuning parameters and recommended values for WebCenter Portal, see "Oracle WebCenter Portal Performance Tuning" in the Oracle Fusion Middleware Performance and Tuning Guide.

This section includes the following subsections:

• Section 30.8.1, "Setting the Policy Store Refresh Interval"

• Section 30.8.2, "Setting the Connection Pool Cache"

• Section 30.8.3, "Setting User Cache Settings"

• Section 30.8.4, "Setting Group Cache Settings"

30.8.1 Setting the Policy Store Refresh Interval

The authorization policies used by WebCenter Portal use an in-memory cache with a default policy refresh time of 10 minutes. When a group space is created in a multi-node high availability environment, and you need a node failure to replicate the policy data more quickly, you can shorten the policy store refresh interval by modifying the domain-level jps-config.xml file, and adding the following entry:

oracle.security.jps.ldap.policystore.refresh.interval=<time_in_milli_seconds>

This should be added to the PDP service node:

<serviceInstance provider="pdp.service.provider" name="pdp.service">

Note that the policy refresh interval should not be set to too small a value as the frequency at which the server cached policy is refreshed may impact performance.

After modifying the jps-config.xml file, restart all servers in the domain. For more information, see "Caching and Refreshing the Cache" in the Oracle Fusion Middleware Application Security Guide.

30.8.2 Setting the Connection Pool Cache

This section describes the recommended settings for the connection pool cache.

To set the connection pool cache:

1. Log into the WLS Administration Console.

2. Select Security Realms > [realm] > Providers > [provider] > Configuration > Provider Specific.

3. Set the connection pool cache parameters to the following recommended values:

   • Connection Pool Size = max connection users

   • Connect Timeout = 30

   • Connection Retry Limit = 1

   • Results Time Limit = 1000

   • Keep Alive Enable = true

4. Save your changes and restart all servers in the domain.

30.8.3 Setting User Cache Settings

This section describes the recommended settings for user cache settings.

To set user cache settings:

1. Log into the WLS Administration Console.

2. Select Security Realms > [realm] > Providers > [provider] > Configuration > Provider Specific.

3. Set the user cache parameters to the following recommended values:

   • Cache Enabled = true

   • Cache Size = 3200

   • Cache TTL = session timeout

   • Results Time Limit = 1000

   • Keep Alive Enable = true

4. Save your changes and restart all servers in the domain.

30.8.4 Setting Group Cache Settings

This section describes the recommended settings for group cache settings.

To set group cache settings:

1. Log into the WLS Administration Console.

2. Select Security Realms > [realm] > Providers > [provider] > Performance.

3. Set the group cache parameters to the following recommended values:

   • Enable Group Membership Lookup Hierarchy Caching = true

   • Cache Size = 3200

   • Max Group Hierarchies in Cache = 1024

   • Group Hierarchy Cache TTL = session timeout

   • Keep Alive Enable = true

4. Save your changes and restart all servers in the domain.