| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Portal 11g Release 1 (11.1.1.6.0) Part Number E12405-17 |
|
|
View PDF |
| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Portal 11g Release 1 (11.1.1.6.0) Part Number E12405-17 |
|
|
View PDF |
This chapter describes how to reassociate the identity store with an external LDAP rather than the default embedded LDAP identity store. It also describes how to configure an LDAP server for Oracle WebCenter Content Server and contains the following subsections:
Section 29.1, "Reassociating the Identity Store with an External LDAP Server"
Section 29.3, "Configuring the GUID Attribute for External LDAP Identity Stores"
Section 29.4, "Adding Users to the Embedded LDAP Identity Store"
Section 29.5, "Moving the Administrator Account to an External LDAP Server"
Section 29.6, "Configuring the Oracle Content Server to Share the Spaces Identity Store LDAP Server"
Section 29.7, "Aggregating Multiple Identity Store LDAP Servers Using libOVD"
Section 29.8, "Configuring Dynamic Roles for the Spaces Application"
Section 29.9, "Configuring Dynamic Groups for the Spaces Application"
Section 29.10, "Configuring the REST Service Identity Asserter"
Caution:
Before reassociating the identity store, be sure to back up the relevant configuration files:
config.xml
jps-config.xml
As a precaution, you should also back up the boot.properties file for the Administration Server for the domain.
Note that for Framework applications, the steps for Migrating WebCenter Portal's Discussions Server to Use an External LDAP are not required. For more information about the identity store, see the Oracle Fusion Middleware Application Security Guide.
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."
In almost all cases, you must reassociate the identity store with an external LDAP server rather than using the default embedded LDAP. Although you can use many different types of LDAP servers (see Section 28.2, "Default Security Configuration" for a list of supported LDAPs), this section focuses on how to configure the identity store to use Oracle Internet Directory (OID).
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 Section 1.13.2, "Oracle WebLogic Server Administration Console."
In the Domain Structure pane (see Figure 29-1), click Security Realms.
The Summary of Security Realms pane displays (see Figure 29-10).
Figure 29-2 Summary of Security Realms pane
In the Name column, click the realm for which you want to reassociate the identity store.
The Realm Settings pane displays (see Figure 29-3).
Open the Providers tab.
The Providers Settings pane displays (see Figure 29-4).
Click New to add a new provider.
The Create a New Authentication Provider pane displays (see Figure 29-5).
Figure 29-5 Create a New Authentication Provider Pane
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.
Click OK to save your settings.
The Settings pane displays with the new authentication provider (see Figure 29-6).
Figure 29-6 Settings Pane - Authentication Providers
In the list of Authentication Providers, click the newly created provider.
The Settings Pane for the new authentication provider displays (see Figure 29-7).
Figure 29-7 Settings Pane for Authenticator
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.
The Provider Specific pane displays (see Figure 29-8).
Enter the details specific to your LDAP server.
Note:
The table below shows values appropriate for OID. For the permissible values for other LDAPs, such as Active Directory, see the appendix "OPSS System and Configuration Properties" in the Oracle Fusion Middleware Application Security Guide.
| Parameter | Value | Description |
|---|---|---|
|
Host: |
The LDAP server's server ID (for example, <ldap_host> |
|
|
Port: |
The LDAP server's port number (for example, |
|
|
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, |
|
|
Group Base DN: |
Specify the DN that points to your Groups node (for example, |
|
|
Use Retrieved User Name as Principal |
Checked |
Must be turned on |
|
All Users Filter: |
|
Search to find all users under the User Base DN |
|
User From Name Filter: |
|
|
|
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 Section 29.5, "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.
The following sections describe performance-related configurations that may be required for specific environments. For more general information about tuning and performance for WebCenter Portal, see Oracle Fusion Middleware Performance and Tuning Guide.
This section includes the following subsections:
When you configure an identity store with WebCenter Portal (using WebLogic Server providers), you can choose to configure either an SSL port or a non-SSL port. If you choose an SSL port, by default, the JNDI connections are not pooled causing increased response time and decreased performance when looking up users, groups, or other identity store entities. To address this, do the following:
Open the jps-config.xml file under domain_home/config/fmwconfig/jps-config.xml, locate the idstore.ldap service instance and add the line highlighted below:
<!-- JPS WLS LDAP Identity Store Service Instance -->
<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="java.naming.ldap.factory.socket"
value="javax.net.ssl.SSLSocketFactory"/>
</serviceInstance>
Restart all the servers within the domain that are connected to the identity store on an SSL port with the following JVM parameter:
-Dcom.sun.jndi.ldap.connect.pool.protocol=ssl
You can specify this by modifying setDomainEnv.sh or directly from the console.
Verify that the servers are running with this JVM parameter, and then (for *nix systems) run the following grep command:
ps -aef | grep WC_Spaces
and verify that the process state specifies com.sun.jndi.ldap.connect.pool.protocol=ssl.
For OVD, the only object class against which attributes are looked up is inetOrgPerson (and it's parent object classes). Since the Profile Gallery can display attributes not defined in inetOrgPerson, all the additional attributes not covered in inetOrgPerson would require an additional round trip to the identity store.For best performance when using OVD in a production environment, Oracle recommends that you add the following configuration entry (in bold) to the domain-level jps-config.xml file:
<!-- JPS WLS LDAP Identity Store Service Instance -->
<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"/>
<extendedProperty>
<name>user.object.classes</name>
<values>
<value>top</value>
<value>person</value>
<value>inetorgperson</value>
<value>organizationalperson</value>
<value>orcluser</value>
<value>orcluserv2</value>
<value>ctCalUser</value>
</values>
</extendedProperty>
</serviceInstance>
For best performance when using Active Directory in a production environment, Oracle recommends that you add the following configuration entries (in bold) to the domain-level jps-config.xml file:
<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 name="PROPERTY_ATTRIBUTE_MAPPING" value="WIRELESS_ACCT_NUMBER=mobile:MIDDLE_NAME=middlename:MAIDEN_NAME=sn:DATE_OF_HIRE=pwdLastSet:NAME_SUFFIX=generationqualifier:DATE_OF_BIRTH=pwdLastSet:DEFAULT_GROUP=primaryGroupID" />
<property value="sAMAccountName" name="username.attr"/>
<property value="sAMAccountName" name="user.login.attr"/>
</serviceInstance>
The People Profile Service queries for all these attributes and there is no default mapping for these attributes in the Active Directory provider. A vanilla Active Directory installation doesn't have any mapping corresponding to DATE_OF_HIRE, DATE_OF_BIRTH.
Note that the two attributes are simply a mapping to some attribute of the correct data type to reduce unnecessary LDAP server calls as Active Directory really doesn't have corresponding attributes with the same semantic meaning.
This section describes the different GUID attributes used by non-Oracle LDAP implementations, as shown below:
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
If you are using an LDAP identity store that does not use the orclGuid attribute, such as IBM Tivoli, you must manually map the GUID attribute so that it matches your identity store. For example, for IBM Tivoli, set GUID=ibm-entryUUID in the jps-config.xml file as shown below:
Open the MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config.xml file in a text editor.
Set the GUID property as follows:
<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap.0">
<!-- existing props ... ->
<property name="PROPERTY_ATTRIBUTE_MAPPING"
value="GUID=ibm-entryUUID"/>
<extendedProperty>
... ...
</extendedProperty>
</serviceInstance>
Restart all the servers.
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 Oracle Internet Directory, users are typically managed using ODSM (described in the section on "Managing Directory Entries" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory).
Note:
If you are planning to reassociate your identity store with an external LDAP, perform that step first (as described in Section 29.1, "Reassociating the Identity Store with an External LDAP Server") as when you reassociate the embedded LDAP with OID or other external LDAP implementation users and user artifacts may not be carried forward. Consequently, do not add users to the embedded LDAP with the expectation of moving them to a production environment. The embedded LDAP is intended to be used only as a test environment, and is not intended as a staging environment that can be moved to production.
Spaces supports self-registration. New users who self-register with Spaces are added directly to the identity store. For more information about self-registration, see "Allowing Self-Registration" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.
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:
Section 29.4.1, "Adding Users to the Identity Store Using the WLS Administration Console"
Section 29.4.2, "Adding Users to the Identity Store Using an LDIF File"
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 Section 1.13.2, "Oracle WebLogic Server Administration Console."
In the Domain Structure pane (see Figure 29-9), click Security Realms.
The Summary of Security Realms pane displays (see Figure 29-10).
Figure 29-10 Summary of Security Realms pane
In the Name column, click the realm to which you want to add users.
The Realm Settings pane displays (see Figure 29-11).
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 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.
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.
For information on logging into the WebLogic Server Administration Console, see Section 1.13.2, "Oracle WebLogic Server Administration Console."
In the Domain Structure pane (see Figure 29-13), click wc_domain.
Figure 29-13 Domain Structure Pane (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 (see Figure 29-14).
Figure 29-14 Settings Pane with 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 29-15.
Figure 29-15 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 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: welcome1 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:
Spaces 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 the Oracle Identity Management User Reference.
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
When configuring the domain to use an external LDAP server, you can also optionally move the Fusion Middleware administrator account (weblogic by default) to the LDAP server.
If the Fusion Middleware 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.
If you cannot create the weblogic (default) user in the external LDAP directory, there are two options. You can:
Keep the DefaultAuthenticator provider and use the weblogic account with the local embedded LDAP server in WebLogic Server to start and stop servers and do other administrator operations from the WebLogic Server Administration Console. If you keep the DefaultAuthenticator, make sure that the control flag for the DefaultAuthentication provider is set to SUFFICIENT. If you choose this option, you must also perform the additional steps described in Section 29.5.1, "Migrating WebCenter Portal's 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 the Spaces application as the application code will not be able to find the user in the external LDAP store.
Remove the DefaultAuthenticator and make sure that any valid user account used for administrator operations, such as starting and stopping servers, is included in an "Administrators" group or other named group that contains the list of users that are allowed to manage your domain in OID or other external LDAP. If a name other than "Administrators" is used, then you must update the group name in the definition of the WebLogic Server Global Administrator role. By default, this is defined as membership in the enterprise group called "Administrators". For information about changing the administrator group name, see Section 29.5.2, "Changing the Administrator Group Name."
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 29.5, "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 Section 29.4, "Adding Users to the Embedded LDAP Identity Store."
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.
Click Settings > Admins/Moderators.
The Admins & Moderators page displays (see Figure 29-16).
Click Grant New Permissions.
The Grant New Permissions pane displays (see Figure 29-17).
Grant System Admin privileges to the user you created, as shown in Figure 29-18.
Figure 29-18 Grant New Permissions Pane with New User
Click System > System Properties.
The Jive Properties page displays (see Figure 29-19).
Check that the properties marked in red have been added and are set as shown in Figure 29-19.
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."
In the Domain Structure pane (see Figure 29-20), click Security Realms.
The Summary of Security Realms pane displays (see Figure 29-21).
Figure 29-21 Summary of Security Realms pane
In the Name column, click the realm for which you want to change the administrator group name.
The Realm Settings pane displays (see Figure 29-22).
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 29-23:
Figure 29-23 Providers Tab with Reordered Authentication Providers
Restart the domain Administration Server and discussions server.
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 Section 1.13.2, "Oracle WebLogic Server Administration Console."
In the Domain Structure pane (see Figure 29-24), click Security Realms.
The Summary of Security Realms pane displays (see Figure 29-25).
Figure 29-25 Summary of Security Realms pane
In the Name column, click the realm for which you want to change the administrator group name.
The Realm Settings pane displays (see Figure 29-26).
Open the Roles and Policies tab, and then the Realm Roles subtab.
The Realm Roles settings pane displays (see Figure 29-27).
Expand the Global Roles node, and then the Roles node.
Click View Role Conditions for the Admin role.
The Edit Global Role page displays (see Figure 29-28).
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 (see Figure 29-29).
Figure 29-29 Edit Global Role Page - Predicate List
Select Group from the Predicate List list and click Next.
The Edit Global Role - Arguments page displays (see Figure 29-30).
Figure 29-30 Edit Global Role Page - Arguments
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.
Oracle Content Server (OCS) must be configured to use the same identity store LDAP server as Oracle Spaces. For more information on configuring the OCS, see Chapter 11, "Managing Content Repositories" and also "Configuring the LDAP Identity Store Service" in the Oracle Fusion Middleware Application Security Guide.
Sites with muliple identity stores can use libOVD to aggregate their user profile information. Two scenarios are covered in the step-by-step configuration instructions below:
Users are available in distinct identity stores with complete user profile information available in the respective identity store.
The same user is available in both identity stores with some attributes in one store and other attributes in the other store.
Note:
If you are supporting self-registration with Active Directory, be sure to see the troubleshooting note in Section 28.3.3, "Users Cannot Self-Register when Spaces Configured with Active Directory."
This section contains the following subsections:
Section 29.7.1, "Configuring libOVD for Identity Stores with Complete User Profiles"
Section 29.7.2, "Configuring libOVD for Identity Stores with Partial 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."
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 thejps-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>
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 $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.
You can restore the single authenticator by removing the Join Adapter rule, thereby backing out the configuration done in Section 29.7.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.
This section describes how to configure dynamic roles for Spaces.
This section contains the following subsections:
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) 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 29-31 shows the login process for a topology configured with OES and the OVD plug-in.
Figure 29-32 shows what happens during a dynamic group query for a topology configured with OES and the OVD plug-in.
Prior to installing and configuring the OVD plug-in, you should already have installed and configured Oracle Internet Directory (OID), Oracle Virtual Directory (OVD), and Oracle Entitlement Server (OES).
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 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."
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:
Download the oes-ovd-plugin.zip file from:
http://download.oracle.com/otndocs/tech/webcenter/files/oes-ovd-plugin.zip
Make a copy of the oes-ovd-plugin.zip file.
Go to the plugins/lib directory where OVD was installed (for example, asinst_1/OVD/ovd1/plugins/lib).
Unzip oes-ovd-plugin.zip.
Create the following directories:
mkdir pdpproxy mkdir keys
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
Go to the keys directory that you just created and copy all the keys in the OES install (ales32-shared/keys directory) here.
Go to the pdpproxy directory that you just created and copy the PDP configuration properties file from OES (rmi-ssm/pdpproxy/PDPProxyConfiguration.properties).
Restart the OVD process with the following command:
./opmnctl stopall startall
If you are planning to use Personalization in defining your constraints, install the p13nattributeRetriever as shown below:
Locate the <WebCenter Home>/webcenter/modules/oracle.webcenter.framework_11.1.1/attribute-retriever.jar file.
Locate the rmi-ssm/lib/providers directory of the OES installation, and copy the attribute-retriever.jar file there.
Restart the rmi-ssm.
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 29.8.2, "Prerequisites to Configuring Dynamic Roles") and the OVD plug-in (described in Section 29.8.3, "Installing the OVD Plug-in").
This section contains the following subsections:
Section 29.8.4.3, "Configuring the Personalization Attributes"
Section 29.8.4.4, "Configuring the Spaces Application to Consume Dynamic Roles"
All the dynamic roles that you want to be available in Spaces should be defined under a single umbrella resource and action. In the steps below, we're using WebCenterApp/WebCenterResource as the umbrella resource, and browse as the action. When you create the dynamic roles, the roles are then granted browse permission on the resource using role mapping polices. A role mapping policy can also have additional constraints based on identity store or Personalization attributes.
To configure OES for dynamic groups:
Open a browser and log onto the OES console:
https://host:port/asi
Create a resource root naming it WebCenterApp and selecting Binding as the Type as shown in Figure 29-33.
Create a resource under WebCenterApp naming it WebCenterResource and selecting Resource as the Type as shown in Figure 29-34.
Create an action naming it browse as shown in Figure 29-35.
Create the dynamic roles as shown in Figure 29-36.
Create resource attributes using the same name as the identity store attributes that are to be used in the constraints (for example, business_email or timezone) as shown in Figure 29-37. If Personalization attributes are to be used in the constraints then those attributes should also be created.
Figure 29-37 Creating Resource Attributes
Create role mapping policies and constraints using the identity store attributes or built-in system attributes (such as hour or day) as shown in Figure 29-38.
Figure 29-38 Creating Role Mapping Policies
Open the Authorization node under Service Control Manager, and then open the Attribute Retrievers tab as shown in Figure 29-39.
Create a custom attribute retriever named WebCenterP13nAttributeRetriever (oracle.webcenter.security.internal.plugins.oes.attributeretriever.WebCenterP13nAttributeRetriever), adding the class details as shown in Figure 29-40.
Figure 29-40 Creating a Custom Attribute Retriever
Open the Configuration tab and distribute the configuration changes as shown in Figure 29-41.
Figure 29-41 Distributing the Configuration Changes
Open the Policy tab and distribute the policy changes as shown in Figure 29-42.
Figure 29-42 Distributing the Policy Changes
This section describes how to configure the OVD plug-in.
To configure the OVD plug-in:
Go to the plugins/lib/pdpproxy directory and edit the file PDPProxyConfiguration.properties, providing the SSM configuration ID, the OES host name, the RMIS port, and the trust store location. Example values are shown below:
SSMConfigID=JK_SM1 PDPTransport=RMI PDPAddress=rmis://example.com:9300 (the use of SSL port is always recommended) TrustStore=<OID_HOME>/asinst_1/OVD/ovd1/plugins/lib/keys/DemoTrust.jks
Open the file ./config/OPMN/opmn/opmn.xml and change the java-options and java-classpath of the OVD process shown in the following sample, providing the correct OVD home path:
<data id="java-options" value="-server -Xms256m -Xmx256m -Dvde.soTimeoutBackend=0 -Didm.oracle.home=$ORACLE_HOME -Dcommon.components.home=$ORACLE_HOME/../oracle_common -Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml -Djavax.net.ssl.trustStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/DemoTrust.jks -Dpdp.configuration.properties.location=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/pdpproxy/PDPProxyConfiguration.properties -Dwles.ssl.identityKeyAlias=wles-admin -Dwles.ssl.identityKeyPasswordAlias=wles-admin -Dwles.ssl.identityKeyStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/identity.jceks -Dwles.ssl.trustedCAKeyStore=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/trust.jks -Dwles.ssl.passwordFile=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/password.xml -Dwles.ssl.passwordKeyFile=$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/keys/password.key"/> <data id="java-classpath" value="$ORACLE_INSTANCE/OVD/ovd1/plugins/lib/jsafeFIPS.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/jsafeJCEFIPS.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/scmapi.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/sslplus.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/ssladapter.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/asitools.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/webserviceclient.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/EccpressoCore.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/webservice.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/kodo-runtime.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/kodo-runtime.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/commons-pool-1.3.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/oes-ovd-plugin.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/xbean.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/antlr.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/log4j.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/api.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/asi_classes.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/framework.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/rmi-types.jar: $ORACLE_INSTANCE/OVD/ovd1/plugins/lib/rmi-ssm.jar: $ORACLE_HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
Using your browser, open the Oracle Directory Service Manager (ODSM):
http://host:port/odsm
To determine the ODSM port use the opmnctl status command in the OID installation. The default port is 7005.
Create an adapter of Type LDAP Adapter, providing the LDAP host and port details as shown in the example in Figure 29-43.
Choose the DN and provide a mapping name for the DN.
If you need to map to attributes other than the default, open the Plug-ins tab of the adapter and add the UserManagement adapter. For example, if you are using Active Directory as the backend directory server for OVD, add the UserManagement adapter providing the following parameter mappings:
<param name="directoryType" value="ActiveDirectory"/> <param name="mapAttribute" value="orclguid=objectguid"/> <param name="mapAttribute" value="cn=sAMAccountName"/> <param name="mapAttribute" value="uniquemember=member"/> <param name="mapAttribute" value="OESRole=OESRole"/> <param name="mapObjectclass" value="orclGroup=group"/> <param name="mapObjectclass" value="groupofurls=group"/> <param name="mapObjectclass" value="groupofuniquenames=group"/> <param name="mapObjectclass" value="person=user"/> <param name="mapRDNAttribute" value="uniquemember=member"/>
For more information about configuring the UserManagement adapter, see "UserManagement Plug-In" in the Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.
Add the OES10gUserEntitlementsPlugin and add all the plug-in parameters as shown in the example below, replacing the host and port details for BLM and Personalization (p13n) for your local environment:
<param name="ldap_group_basedn" value="cn=Groups,dc=us,dc=oracle,dc=com"/> <param name="ldap_user_basedn" value="cn=Users,dc=us,dc=oracle,dc=com"/> <param name="ldap_admin_user" value="cn=Administrator"/> <param name="oes_admin_user" value="admin"/> <param name="OrclOVDEncrypted_oes_admin_pass" value="<password>"/> <param name="oes_config_name" value="JK_SM1"/> <param name="oes_policy_domain" value="JK_SM1"/> <param name="oes_resource_action" value="browse"/> <param name="oes_resource_name" value="WebCenterApp/WebCenterResource"/> <param name="oes_resource_namespace" value="webcenterResource”/> <param name="oes_roles_cache_interval" value="180000"/> <param name="oes_action_namespace" value="webcenterAction"/> <param name="p13n_admin_user" value="weblogic"/> <param name="OrclOVDEncrypted_p13n_admin_pass" value="<password>"/> <param name="oes_blm_host" value="example.com"/> <param name="oes_blm_port" value="7011"/> <param name="oes_p13n_index_url" value="example.com/> <param name="oes_p13n_prop_url" value="example.com"/> <param name="ldap_eqmatch" value="equalityMatch"/> <param name="ldap_loginattr" value="sAMAccountName"/> <param name="ldap_loginattr" value="mail"/> <param name="ldap_loginattr" value="cn"/>
Note that passwords, once entered as plug-in parameters, are encrypted and then stored on the server.
Restart the OVD process using the following command:
./opmnctl stopall startall
Make sure that the OVD process restarts without any exceptions before continuing. If you encounter errors, you can turn on logging in the plug-in, by adding the following entry to:
<INSTANCE_HOME>/config/OVD/ovd1/ovd-logging.xmlovd-logging.xml
<logger name='oracle.webcenter.security.internal.plugins.ovd' level='TRACE:1' useParentHandlers='false'>
<handler name='OVDHandler'/>
</logger>
If SSL-enabled Personalization attributes are required, then import the certificate containing the public key of the Personalization server into the trust store on OVD, whic is typically the JDK's cacerts file.
If you are using Personalization attributes as part of your constraints, then follow the instructions in "Viewing a Property Set Within a Namespace Using the Property Service" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal to configure them. For more information about Personalization for WebCenter Portal, see Chapter 20, "Managing Personalization for WebCenter Portal."
This section describes how to prepare Spaces to consume dynamic roles defined in OES.
By default, Spaces picks up only the static enterprise roles defined in the identity store. To use the dynamic roles defined within OES (Oracle Entitlements Server), you need to add the OVD plug-in as the authenticator. The OVD plug-in can then consolidate the static roles from the identity store and the dynamic roles from OES.
To configure Spaces to consume dynamic roles:
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."
Add an authenticator of Type Oracle Virtual Directory providing the OVD connection details, and the group base dn and user base dn.
Leave the rest of the settings as their default values. Any directory-specific mapping should be done only in the adapter using the UserManagement plug-in. For more information about configuring the UserManagement adapter, see "UserManagement Plug-In" in the Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.
Restart all servers.
Log onto Spaces as a user in OID and create a group space.
Go to Add Members > Groups > Search and add the enterprise roles you want as members to a group space as shown in Figure 29-44.
With OVD as the authenticator, you should see both dynamic (from OES) and static groups. In Figure 29-44, the dynamic groups are ESTUsers, DayUsers and ISTUsers, with the rest being static groups from OID.
Figure 29-44 Adding Static and Dynamic Groups to a Space
A dynamic group is a static group that is dynamically populated. Dynamic groups can be assigned to roles and used within Spaces in the same way as static groups.
Within the application, Spaces does not distinguish between static and dynamic groups. Dynamic groups are configured entirely in the identity store (and their configuration is specific to the LDAP implementation being used), and exposed in the same manner as static groups (in fact a dynamic group can be a composite of a static member list and a dynamically determined membership).
The dynamic membership of the group is defined by setting the group's labeledURI attribute with an appropriate LDAP query filter. The query filter defines the set of users that will define the membership of the group.
For Oracle Internet Directory, you can create a dynamic group with an LDIF file and using the ldapadd command, or using the Oracle Directory Services Manager (ODSM). These two options are described in the following subsections:
Section 29.9.1, "Creating a Dynamic Group Using an LDIF File"
Section 29.9.2, "Creating a Dynamic Group Using the Oracle Directory Services Manager"
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 29-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.
Save the file, and then update the OID server by issuing the ldapadd command. For example:
Example 29-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
To create a dynamic group using ODSM:
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.
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.
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 sections show how to configure OPSS Trust Service instances and identity asserters for Oracle WebLogic Server.
This section contains the following subsections:
Section 29.10.1, "Understanding the REST Service Instance and Identity Asserter"
Section 29.10.3, "Configuring the WLS Trust Service 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 29-45 shows the different components involved in the identity propagation and assertion.
Figure 29-45 REST Identity Propagation and Assertion
The following depicts the sequence of events involved in REST identity propagation and assertion:
End clients (browsers, smart phone apps) 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 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.
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.
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 application uses the response and shows the page to the end user.
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 + " " + 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());
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.
Create the keystore as shown in Section 34.1.2.1, "Creating the WebCenter Portal Domain Keystore."
Configure the keystore as shown in Section 34.1.2.2, "Configuring the Keystore with WLST," or Section 34.1.2.3, "Configuring the Keystore Using Fusion Middleware Control."
Edit the jps-config.xml configuration file.
Navigate to your domain_home/config/fmwconfig directory.
Open the jps-config.xml file in a text editor.
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.
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.
|
 Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|