23 Managing Security

This chapter describes how to configure your WebCenter application to handle authentication and authorization, and other aspects of application security.

This chapter includes the following sections:

• Section 23.1, "Introduction to WebCenter Application Security"

• Section 23.2, "Default Security Configuration"

• Section 23.3, "Configuring the Identity Store"

• Section 23.4, "Configuring the Policy and Credential Store"

• Section 23.5, "Managing Users and Roles"

• Section 23.6, "Configuring WebCenter Applications and Components to Use SSL"

• Section 23.7, "Configuring a WebCenter Application to Use Single Sign-On"

• Section 23.8, "Configuring WS-Security"

• Section 23.9, "Securing a PDK-Java Producer"

• Section 23.10, "Troubleshooting Security Configuration Issues"

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

23.1 Introduction to WebCenter Application Security

The recommended security model for Oracle WebCenter is based on Oracle ADF Security, which implements the Java Authentication and Authorization Service (JAAS) model. For more information about Oracle ADF Security, see the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

Figure 23-1 shows the relationship between a WebCenter application deployment and its services, servers, portlets, portlet producers, its identity, credential and policy stores, and Oracle Enterprise Manager.

Figure 23-1 Basic WebCenter Application Architecture

Description of "Figure 23-1 Basic WebCenter Application Architecture"

The diagram in Figure 23-2 shows a basic WebCenter application after deployment with its back-end server connections.

Figure 23-2 WebCenter Application Architecture with Back-end Server Connections

Description of "Figure 23-2 WebCenter Application Architecture with Back-end Server Connections"

The diagram in Figure 23-3 shows the security layers for the WebCenter Spaces application.

Figure 23-3 WebCenter Spaces Security Layers

Description of "Figure 23-3 WebCenter Spaces Security Layers"

The security layers for a custom WebCenter application could have the same four bottom layers (WebCenter Security Framework, ADF Security, OPSS, and WebLogic Server Security) depending on how the application was structured. The application layer will, of course, depend on the implementation.

WebCenter Spaces Application Security

WebCenter Spaces provides support for:

• Application role management and privilege mapping

• Self-registration

• Group space security management

• Account management

• External application credential management

WebCenter Security Framework

WebCenter Security Framework provides support for:

• Service Security Extension Framework

• Permission-based authorization

• Role-mapping based authorization

• External applications and credential mapping

ADF Security

ADF Security provides support for:

• Page authorization

• Task flow authorization

• Secure connection management

• Credential mapping APIs

• Logout invocation, including logout from SSO-enabled configurations with Oracle Access Manager and Oracle SSO

• Secured login URL for ADF Security-based applications (the adfAuthentication servlet)

Oracle Platform Security Services (OPSS)

OPSS provides support for:

• Anonymous-role support

• Authenticated-role support

• Identity store, policy store, and credential store

• Identity Management Services

• Oracle Web Service Manager Security

WebLogic Server Security

WebLogic Server Security provides support for:

• WebLogic authenticators

• Identity asserters

• J2EE container security

• SSL

23.2 Default Security Configuration

This section describes the security configuration that is in place when custom WebCenter applications and WebCenter Spaces are deployed, and the tasks that need to be carried out after deployment:

• Section 23.2.1, "Administrator Accounts"

• Section 23.2.2, "Application Roles and Enterprise Roles in WebCenter Spaces"

• Section 23.2.3, "Default Identity and Policy Stores"

• Section 23.2.4, "Default Policy Store Permissions and Grants"

• Section 23.2.5, "Post-deployment Security Configuration Tasks"

23.2.1 Administrator Accounts

Custom WebCenter applications do not contribute any pre-seeded accounts, and therefore rely on the Fusion Middleware administrator account (weblogic by default) that is set up when Fusion Middleware is installed. Use this administrator account to log into Fusion Middleware Control and set up new accounts.

Although WebCenter Spaces does not contribute any pre-seeded accounts, there are certain pre-seeded grants that are given to the default Fusion Middleware administrator account (weblogic) for the WebCenter Spaces application. If your installation does not use weblogic as the account name for the Fusion Middleware administrator role, you will need to configure one or more other users for this role as described in Section 23.3.5.1, "Granting the WebCenter Spaces Administrator Role Using Fusion Middleware Control."

23.2.2 Application Roles and Enterprise Roles in WebCenter Spaces

Application roles and permissions are defined within WebCenter Spaces and are stored in an application-specific stripe of the policy store. Consequently, WebCenter Spaces roles apply only to WebCenter Spaces; WebCenter Spaces roles and permissions do not extend to other applications.

Application roles differ from roles that appear in the identity store portion of the embedded LDAP server or in roles defined by the enterprise LDAP provider. Application roles are specific to an application and defined in the application policy store.

Enterprise roles, which are stored in the enterprise identity store, apply at the enterprise level. That is, the roles and permissions that you or a system administrator define within the enterprise identity store do not imply permissions within WebCenter Spaces.

Within WebCenter Spaces you can assign application roles and permissions to users in the corporate identity store. You can also assign application roles and permissions to enterprise roles defined in the enterprise identity store.

23.2.3 Default Identity and Policy Stores

By default, WebCenter applications are configured to use a file-based embedded LDAP identity store to store application-level user IDs, and a file-based LDAP policy store to store policy grants.

Although secure, the embedded LDAP identity store is not a "production-class" store and should be replaced with an external LDAP-based identity store such as Oracle Internet Directory for enterprise production environments.

The default file-based policy store can only be used for single-node WebCenter Spaces configurations. For multi-node configurations, you must reassociate the policy and credential store with an external LDAP-based store (such as Oracle Internet Directory) as described in Section 23.4, "Configuring the Policy and Credential Store."

The policy store can be configured to use Oracle Internet Directory 11gR1 and 10.1.4.3, and OVD 11gR1 with the Local Store Adapter (LSA).

The identity store can be configured to use the following LDAP servers:

• Oracle Internet Directory (OID) 11gR1 and 10.1.4.3

• Oracle Virtual Directory (OVD) 11gR1 and 10.1.4

• Sun iPlanet version 4.1.3

• Active Directory shipped as part of Windows 2000

• Open LDAP version 2.0.7

• Novell NDS version 8.5.1

For more information on reconfiguring the identity, policy and credential stores, see Section 23.3, "Configuring the Identity Store" and Section 23.4, "Configuring the Policy and Credential Store."

Note:

Oracle Content Server and Oracle WebCenter Discussions rely on external LDAP-based identity stores. Consequently, if you want to use the Documents service (which relies on Oracle Content Server) or the Discussions service (which relies on Oracle WebCenter Discussions) you must reassociate the identity store with one of the external LDAP servers listed above.

For WebCenter Spaces, Oracle recommends that both WebCenter Spaces and Oracle Content Server share the same LDAP server.

23.2.3.1 File-based Credential Store

The out-of-the-box credential store is wallet-based (that is, file-based) and is contained in the file cwallet.sso. The location of this file is specified in the Oracle Platform Security configuration file jps-config.xml. When you reassociate the policy store to an LDAP directory, the application credentials are automatically migrated to the same LDAP directory as the policy store.

23.2.4 Default Policy Store Permissions and Grants

The ADF Security permissions model supports both permission-based and role-based authorization. These two types of authorization, and the default Policy Store permissions and code based grants are discussed in the following sections:

• Section 23.2.4.1, "Permission-based Authorization"

• Section 23.2.4.2, "Role-mapping Based Authorization"

• Section 23.2.4.3, "Default Policy Store Permissions for WebCenter Spaces"

• Section 23.2.4.4, "Default Code-based Grants"

23.2.4.1 Permission-based Authorization

Permission-based authorization is used for services, such as Lists, where access control is implemented within the WebCenter application using Oracle Platform Security Services (OPSS). WebCenter Spaces provides extensive user and role management tools with which you can create application roles, and define what permissions should be granted to those roles. For information on managing users and roles in WebCenter Spaces, see Section 28.3, "Managing Application Roles and Permissions."

23.2.4.2 Role-mapping Based Authorization

Services that need to access "remote" (back-end) resources require role-mapping based authorization. For example, for the Discussions service, role mapping is required when the users of a WebCenter application (mapping to one or more group space roles) need to be mapped to another set of roles on the Oracle WebCenter Discussions Server (or Oracle Content Server).

In WebCenter Spaces:

• Default application and group space roles for WebCenter Spaces are mapped to the corresponding service roles. For default mappings, see Table 28-4 and Table 28-5.

• When a new user is granted an application or group space role, a similar grant (privilege) is granted in the back-end server. For example, when user Pat is granted Discussions-Manage permissions in WebCenter Spaces, Pat is granted corresponding permissions in the back-end discussion server. See also, Section 28.1.4, "Understanding Discussions Server Role and Permission Mapping."

23.2.4.3 Default Policy Store Permissions for WebCenter Spaces

The tables in this section describe out-of-the-box permissions and roles for WebCenter Spaces:

• Table 23-1 shows the default permissions for pre-seeded application roles in the WebCenter Spaces policy store. Application roles determine what users can do in their personal space.

• Table 23-2 shows the default permissions for group space roles that come pre-seeded with out-of-the-box group space templates: Community of Interest (COI), Group Project, Blank. When a new group space is created, these group space roles and their corresponding permissions are added to the policy store at runtime.

Table 23-1 Default Application Roles and Permissions in WebCenter Spaces

	Default Application Roles
Permissions	Administrator	Spaces-User	Public-User
Application
Manage	✔
Configure	✙
View	✙	✔	✔
Group Spaces
Manage	✔
Configure	✙
View	✙
Create	✙	✔
Group Space Templates
Manage	✔
View	✙
Create	✙	✔
Pages
Manage	✔
Delete	✙
Edit	✙
Personalize	✙
View	✙
Create	✙	✔
Discussions
Manage	✔
Links
Manage	✔
Delete	✙
Create	✙
People Connections
Manage	✔
Edit	✙	✔
Share	✙	✔

Table 23-2 Default Group Space Roles and Permissions in WebCenter Spaces

Default Roles	Moderator			Participant			Viewer			Spaces-User	Public-User
Template	COI	Project	Blank	COI	Project	Blank	COI	Project	Blank
Group Space Access
Manage	✔	✔	✔
Configure	✙	✙	✙
View	✙	✙	✙	✔	✔	✔	✔	✔	✔
Group Space Services(Pages, Events, Links, Lists, Notes)
Manage	✔	✔	✔
Design	✔	✔	✔		✔	✔
Contribute	✔	✔	✔	✔	✔	✔
View	✔	✔	✔	✔	✔	✔	✔	✔	✔
Announcements
Manage	✔	✔								n/a
Edit	✙	✙		✔	✔					n/a
View	✙	✙		✔	✔		✔	✔		n/a
Discussions
Manage	✔	✔								n/a
Edit	✙	✙		✔	✔					n/a
View	✙	✙		✔	✔		✔	✔		n/a
Documents
Manage	✔	✔								n/a
Delete	✔	✔		✔	✔					n/a
View	✔	✔		✔	✔		✔	✔		n/a
Create	✔	✔		✔	✔					n/a

Legend	Description
✔	Shows an explicitly granted permission or action.
✙	Shows an implied permission as a result of an explicitly granted permission. The permission implementation itself does the implication.

23.2.4.4 Default Code-based Grants

WebCenter applications make internal calls to APIs on the security platform that are secured with permission checks. To facilitate this, the WebCenter application must be granted appropriate permissions to invoke the OPSS APIs. For example, the permission to access the policy store and grant or revoke permissions (PolicyStoreAccessPermission), as well as CRUD on application roles. In the case of WebCenter Spaces, CRUD permission are granted by default, out of the box.

Similarly, WebCenter applications must pre-authorize access to various operations that it wants to expose using the WebCenter permissions (described in Table 23-1 and Table 23-2), and then invoke the OPSS APIs as privileged actions.

23.2.5 Post-deployment Security Configuration Tasks

After deploying your custom WebCenter application or WebCenter Spaces, consider the following security-related configuration tasks for your site:

• Reassociating the identity store to use an external LDAP

  By default, WebCenter applications use an embedded LDAP for its identity store. Although secure, the out-of-the-box embedded LDAP may not scale appropriately for large enterprise production environments. For instructions on how to configure the identity store to use an external LDAP such as Oracle Internet Directory (OID), see Section 23.3, "Configuring the Identity Store."

  Note:

  Oracle Content Server and Oracle WebCenter Discussions rely on external LDAP-based identity stores. Consequently, if you want to use the Documents service (which relies on Oracle Content Server) or the Discussions service (which relies on Oracle WebCenter Discussions) you must reassociate the identity store to use an external LDAP server. For more information on reconfiguring the identity store, see Section 23.3, "Configuring the Identity Store."

• Reassociating the policy store to use an external LDAP

  By default, custom WebCenter applications use a file-based system-jazn-data.xml policy store to store policy grants. You should consider using an LDAP-based policy store. For information on how to configure the policy store to use an LDAP server, see Section 23.4, "Configuring the Policy and Credential Store."

• Configuring WS-Security

  Although the use of WS-Security adds complexity to the configuration and management of a WebCenter application and the set of producers it consumes, it helps ensure the security of the information being published by the WebCenter application. Adding WS-Security provides authentication for the consumer, and message-level security.

  For information on how to configure WS-Security for WebCenter applications and components, see Section 23.8, "Configuring WS-Security."

• Configuring SSO

  Single Sign-On (SSO) allows users to log in once across WebCenter applications and components rather than having to log in for each sub-application (for example, for accessing a wiki page in WebCenter Spaces). Users do not have to maintain a separate user ID and password for each application or component that they access. However, you can still configure a variety of authentication methods, so that more sensitive applications can be protected using more stringent methods. WebCenter supports four single sign-on solutions: Oracle Access Manager (OAM), Oracle Single Sign-on (OSSO), a SAML-based single sign-on solution for Oracle WebCenter applications only, and an SSO solution for Microsoft clients, using Windows authentication based on the Simple and Protected Negotiate (SPNEGO) mechanism and the Kerberos protocol. For a discussion of these solutions and an overview of single sign-on, see Section 23.7, "Configuring a WebCenter Application to Use Single Sign-On."

• Configuring SSL

  Secure Sockets Layer (SSL) provides additional security for connections between WebCenter applications or components by providing an additional authentication layer, and by encrypting the data exchanged. For connections between applications or components where the data exchanged is sensitive, consider securing the connection with SSL. For a list of the connections that can and should be protected with SSL in a production environment, see Section 23.6, "Configuring WebCenter Applications and Components to Use SSL."

  Note:

  Using SSL is computationally intensive and adds overhead to a connection. SSL should therefore not be used where it is not required, and is best reserved for production environments.

23.3 Configuring the Identity Store

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

• Section 23.3.1, "Reassociating the Identity Store with an External LDAP"

• Section 23.3.2, "Tuning the Identity Store for Performance"

• Section 23.3.3, "Adding Users to the Identity Store"

• Section 23.3.4, "Moving the Administrator Account to an External LDAP Server"

• Section 23.3.5, "Granting the WebCenter Spaces Administrator Role to a WebCenter Spaces User"

• Section 23.3.6, "Configuring the Oracle Content Server to Share the Identity Store LDAP Server"

Note that for custom WebCenter applications, the steps for Granting the WebCenter Spaces Administrator Role to a WebCenter Spaces User and Migrating the WebCenter Discussions Server to use an External LDAP are not required. For more information about the identity store, see the Oracle Fusion Middleware Security Guide.

Caution:

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

• config.xml

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

23.3.1 Reassociating the Identity Store with an External LDAP

In almost all cases, you will want to 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 23.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).

To reassociate the identity store with OID:

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane (see Figure 23-4), click Security Realms.

   Figure 23-4 Domain Structure Pane

   
   Description of "Figure 23-4 Domain Structure Pane"
   
   

   The Summary of Security Realms pane displays (see Figure 23-13).

   Figure 23-5 Summary of Security Realms pane

   
   Description of "Figure 23-5 Summary of Security Realms pane"
   
   

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

   The Realm Settings pane displays (see Figure 23-6).

   Figure 23-6 Realm Settings Pane

   
   Description of "Figure 23-6 Realm Settings Pane"
   
   

4. Open the Providers tab.

   The Providers Settings pane displays (see Figure 23-7).

   Figure 23-7 Settings Pane - Providers

   
   Description of "Figure 23-7 Settings Pane - Providers"
   
   

5. Click New to add a new provider.

   The Create a New Authentication Provider pane displays (see Figure 23-8).

   Figure 23-8 Create a New Authentication Provider Pane

   
   Description of "Figure 23-8 Create a New Authentication Provider Pane"
   
   

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

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

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

8. Click OK to save your settings.

   The Settings pane displays with the new authentication provider (see Figure 23-9).

   Figure 23-9 Settings Pane - Authentication Providers

   
   Description of "Figure 23-9 Settings Pane - Authentication Providers"
   
   

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

   The Settings Pane for the new authentication provider displays (see Figure 23-10).

   Figure 23-10 Settings Pane for Authenticator

   
   Description of "Figure 23-10 Settings Pane for Authenticator"
   
   

10. Set the Control Flag to SUFFICIENT.

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

    Note:

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

11. Click Save to save this setting.

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

    The Provider Specific pane displays (see Figure 23-11).

    Figure 23-11 Provider Specific Pane

    
    Description of "Figure 23-11 Provider Specific Pane"
    
    

13. Enter the details specific to your LDAP server.

    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

    
    

    If you modify a username attribute to something other than the default set for the LDAP server in the authenticator, you must also edit the jps-config.xml file to correspond to these values. Specifically, the username.attr and user.login.attr properties (highlighted below) must be added for user lookups to function correctly:

    <!-- 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="username.attr" value="uid"/>
    <property name="user.login.attr" value="uid"/>
    </serviceInstance>
    

14. Click Save.

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

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

    Note:

    WebCenter Spaces uses only the first authenticator to authenticate users in the identity store.

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

23.3.2 Tuning the Identity Store for Performance

For a production environment, Oracle recommends that you add the following configuration entry to the jps-config.xml file for best performance:

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

23.3.3 Adding Users to the Identity Store

You can add users to the embedded LDAP or an external LDAP using the WebLogic Server Administration Console. For Oracle Internet Directory, although 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), you can also use the WebLogic Server Administration Console as described below.

Note:

If you are planning to reassociate your identity store with an external LDAP, carry out that step (as described in Section 23.3.1, "Reassociating the Identity Store with an External LDAP") prior to adding users to avoid having to migrate the users from the embedded LDAP to the newly configured external LDAP.

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

You can also add users directly into the embedded LDAP identity store 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:

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 23.3.3.1, "Adding Users Using the WebLogic Server Administration Console"

• Section 23.3.3.2, "Adding Users to the Embedded LDAP Using an LDIF File"

23.3.3.1 Adding Users Using the WebLogic Server Administration Console

To add users to the embedded LDAP or to an external LDAP from the WebLogic Server Administration Console:

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane (see Figure 23-12), click Security Realms.

   Figure 23-12 Domain Structure Pane

   
   Description of "Figure 23-12 Domain Structure Pane"
   
   

   The Summary of Security Realms pane displays (see Figure 23-13).

   Figure 23-13 Summary of Security Realms pane

   
   Description of "Figure 23-13 Summary of Security Realms pane"
   
   

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

   The Realm Settings pane displays (see Figure 23-14).

   Figure 23-14 Realm Settings Pane

   
   Description of "Figure 23-14 Realm Settings Pane"
   
   

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

5. Click New to add a new user.

   Figure 23-15 Create a New User Page

   
   Description of "Figure 23-15 Create a New User Page"
   
   

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

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

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

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

8. From the Provider drop-down menu, select the Authentication provider for the user.

   If multiple WebLogic Authentication providers are configured in the security realm, they will appear in the list. For the embedded LDAP, choose DefaultAuthenticator; for Oracle Internet Directory, choose OracleInternetDirectoryAuthenticator. For other external LDAPs, choose the authenticator associated with that LDAP.

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

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

10. Re-enter the password in the Confirm Password field.

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

    The user should now appear in the list of users.

23.3.3.2 Adding Users to the Embedded LDAP Using an LDIF File

LDIF files enable you to specify additional user attributes. This particular feature is 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 need to carry out the following tasks:

• Enable External LDAP Access

• Create an LDIF File

• Add the Users

Enable External LDAP Access

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

To reset the access credential for the embedded LDAP:

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane (see Figure 23-16), click on wc_domain.

   Figure 23-16 Domain Structure Pane (wc_domain)

   
   Description of "Figure 23-16 Domain Structure Pane (wc_domain)"
   
   

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

   The Settings Pane for wc_domain displays the embedded LDAP settings (see Figure 23-17).

   Figure 23-17 Settings Pane with Embedded LDAP Settings

   
   Description of "Figure 23-17 Settings Pane with Embedded LDAP Settings"
   
   

4. Enter a new password in the Credential field, and re-enter it in the Confirm Credential field.

5. Click Save to save your settings.

6. Restart the WebLogic server.

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

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

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

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

Create an LDIF File

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

• person

• inetOrgPerson

• organizationalPerson

• wlsUser

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

Figure 23-18 Embedded LDAP Directory Information Tree

Description of "Figure 23-18 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 WebCenter 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: [e-mail]
title: Manager
manager: uid=mary.jones,ou=people,ou=myrealm,dc=wc_domain
preferredLanguage: en
departmentNumber: tools
facsimiletelephonenumber: 650-555-1200
mobile: [phone]
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 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 Fusion Middleware User Reference for Oracle Identity Management.

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:
        [e-mail]
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

23.3.4 Moving the Administrator Account to an External LDAP Server

When configuring the domain to use an external LDAP server, you can also optionally move the 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 will also need to perform the additional steps described in Section 23.3.4.1, "Migrating the WebCenter 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 WebCenter 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 need to 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 23.3.4.2, "Changing the Administrator Group Name."

23.3.4.1 Migrating the WebCenter Discussions Server to use an External LDAP

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

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

2. Create an administrator account in the DefaultAuthenticator (i.e., 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 23.3.3, "Adding Users to the Identity Store."

3. Log in to the Oracle WebCenter Discussions Server Admin Console with the boot-identity account (i.e., weblogic) at:

   http://host:port/owc_discussions/admin
   

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

4. Click Settings > Admins/Moderators.

   The Admins & Moderators page displays (see Figure 23-19).

   Figure 23-19 Admins & Moderators Page

   
   Description of "Figure 23-19 Admins & Moderators Page"
   
   

5. Click Grant New Permissions.

   The Grant New Permissions pane displays (see Figure 23-20).

   Figure 23-20 Grant New Permissions Pane

   
   Description of "Figure 23-20 Grant New Permissions Pane"
   
   

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

   Figure 23-21 Grant New Permissions Pane with New User

   
   Description of "Figure 23-21 Grant New Permissions Pane with New User"
   
   

7. Click System > System Properties.

   The Jive Properties page displays (see Figure 23-22).

   Figure 23-22 Jive Properties Page

   
   Description of "Figure 23-22 Jive Properties Page"
   
   

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

9. Log in to the WebLogic Server Administration Console.

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

10. In the Domain Structure pane (see Figure 23-23), click Security Realms.

    Figure 23-23 Domain Structure Pane

    
    Description of "Figure 23-23 Domain Structure Pane"
    
    

    The Summary of Security Realms pane displays (see Figure 23-24).

    Figure 23-24 Summary of Security Realms pane

    
    Description of "Figure 23-24 Summary of Security Realms pane"
    
    

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

    The Realm Settings pane displays (see Figure 23-25).

    Figure 23-25 Realm Settings Pane

    
    Description of "Figure 23-25 Realm Settings Pane"
    
    

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

    Figure 23-26 Providers Tab with Reordered Authentication Providers

    
    Description of "Figure 23-26 Providers Tab with Reordered Authentication Providers"
    
    

13. Restart the domain Administration Server and discussions server.

23.3.4.2 Changing the Administrator Group Name

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

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

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

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

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

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane (see Figure 23-27), click Security Realms.

   Figure 23-27 Domain Structure Pane

   
   Description of "Figure 23-27 Domain Structure Pane"
   
   

   The Summary of Security Realms pane displays (see Figure 23-28).

   Figure 23-28 Summary of Security Realms pane

   
   Description of "Figure 23-28 Summary of Security Realms pane"
   
   

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

   The Realm Settings pane displays (see Figure 23-29).

   Figure 23-29 Realm Settings Pane

   
   Description of "Figure 23-29 Realm Settings Pane"
   
   

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

   The Realm Roles settings pane displays (see Figure 23-30).

   Figure 23-30 Realm Roles Settings Pane

   
   Description of "Figure 23-30 Realm Roles Settings Pane"
   
   

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

6. Click View Role Conditions for the Admin role.

   The Edit Global Role page displays (see Figure 23-31).

   Figure 23-31 Edit Global Role Page

   
   Description of "Figure 23-31 Edit Global Role Page"
   
   

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

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

   The Edit Global Role - Predicate List page displays (see Figure 23-32).

   Figure 23-32 Edit Global Role Page - Predicate List

   
   Description of "Figure 23-32 Edit Global Role Page - Predicate List"
   
   

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

   The Edit Global Role - Arguments page displays (see Figure 23-33).

   Figure 23-33 Edit Global Role Page - Arguments

   
   Description of "Figure 23-33 Edit Global Role Page - Arguments"
   
   

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

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

11. Click Finish to save your changes.

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

23.3.5 Granting the WebCenter Spaces Administrator Role to a WebCenter Spaces User

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

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

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

• Section 23.3.5.2, "Granting the WebCenter 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.

23.3.5.1 Granting the WebCenter Spaces Administrator Role Using Fusion Middleware Control

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

To grant the WebCenter Spaces Administrator role using Fusion Middleware Control:

1. Log into Fusion Middleware Control and select the WebLogic domain for WebCenter Spaces.

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

2. From the WebLogic Domain menu, select Security -> Application Roles.

   The Application Roles page displays (see Figure 23-34).

   Figure 23-34 Application Roles Page

   
   Description of "Figure 23-34 Application Roles Page"
   
   

3. Search for the Administration application role by selecting the Application name for WebCenter Spaces (WLS_Spaces/webcenter), and providing the following internal identifier used by WebCenter Spaces as the Role Name:

   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 name (s8bba98ff_4cbb_40b8_beee_296c916a23ed#-#Administrator) in the Role Name column.

   The Edit Application Role page displays (see Figure 23-35).

   Figure 23-35 Edit Application Role Page

   
   Description of "Figure 23-35 Edit Application Role Page"
   
   

5. Click Add User.

   The Add User pop-up displays (see Figure 23-36).

   Figure 23-36 Add User Pop-up

   
   Description of "Figure 23-36 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 WLS_Spaces managed server.

    When you login to WebCenter Spaces, the Administration link should appear and you should be able to perform all administrator operations. See also, Section 26.1, "Logging into WebCenter Spaces as an Administrator."

23.3.5.2 Granting the WebCenter Spaces Administrator Role Using WLST

To grant the WebCenter Administrator role using WLST:

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

2. Connect to the WebCenter 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 WebCenter 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 WebCenter Spaces using the new account name.

   The Administration link should appear, and you should be able to perform all administrator operations. See also, Section 26.1, "Logging into WebCenter Spaces as an Administrator."

5. After granting the WebCenter Spaces Administrator role to new accounts, remove this role from accounts that no longer need it or should no longer have it using the WLST revokeAppRole command. For example, if WebCenter 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")
   

23.3.6 Configuring the Oracle Content Server to Share the Identity Store LDAP Server

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

23.4 Configuring the Policy and Credential Store

For most environments, and especially production environments, you will want to reassociate your policy store with an external LDAP such as Oracle Internet Directory (OID).

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 as described in the following sections:

• Section 23.4.1, "Creating a root Node"

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

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

• Section 23.4.4, "Managing Credentials"

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

23.4.2 Reassociating the Credential and Policy Store Using Fusion Middleware Control

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

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

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

1. Open Fusion Middleware Control and log into 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.

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

   The Security Provider Configuration page displays (see Figure 23-37).

   Figure 23-37 Security Provider Configuration Page

   
   Description of "Figure 23-37 Security Provider Configuration Page"
   
   

4. On the Security Provider Configuration page, click Change Association... to add the new Oracle Internet Directory provider.

   The Set Security Provider page displays (see Figure 23-38).

   Figure 23-38 Set Security Provider Page

   
   Description of "Figure 23-38 Set Security Provider Page"
   
   

5. Under LDAP Server Details, select Oracle Internet Directory as the LDAP Server Type.

6. In the Host and Port fields, enter the host name and the LDAP port for Oracle Internet Directory.

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

8. Under LDAP Root Node Details, set the JPS 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.

23.4.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 23.4.1, "Creating a root Node."

1. Start WLST as described in Section 1.12.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. Valid types are OID (Oracle Internet Directory) or OVD (Oracle Virtual 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")
   

23.4.4 Managing Credentials

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

23.4.5 Configuring Self-Registration By Invitation in WebCenter Spaces

WebCenter Spaces supports self-registration by invitation, as described in Section 28.4.1, "Enabling Self-Registration By Invitation-Only." The self-registration 'by-invitation' feature requires that the WebCenter 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 WebCenter 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 Security Guide.

23.5 Managing Users and Roles

WebCenter Spaces provides a Users tab from which an administrator can add users defined in the identity store, and assign roles to those users within WebCenter Spaces. For information about managing users and user roles for WebCenter Spaces, see Chapter 28, "Managing Users and Roles for WebCenter Spaces ."

Caution:

The "Allow Password Change" property, which specifies whether users can change their passwords within WebCenter Spaces, should be carefully controlled for corporate identity stores. WebCenter Spaces administrators can set this property from the Profile Management Settings page in WebCenter Spaces. For more information, see Section 16.3.4, "Configuring Profile."

The user interface and management tools with which to manage users and user roles for custom WebCenter applications depends on what has been implemented for the particular deployment. For more information about role-mapping for ADF-security based WebCenter 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.

23.6 Configuring WebCenter Applications and Components to Use SSL

This section includes the following sub-sections:

• Section 23.6.1, "Securing the Browser Connection to WebCenter Spaces with SSL"

• Section 23.6.2, "Securing the Browser Connection to a Custom WebCenter Application with SSL"

• Section 23.6.3, "Securing the Connection from Oracle HTTP Server to WebCenter Spaces with SSL"

• Section 23.6.4, "Securing the Browser Connection to the Wiki Service with SSL"

• Section 23.6.5, "Securing the WebCenter Spaces Connection to Portlet Producers with SSL"

• Section 23.6.6, "Securing the WebCenter Spaces Connection to the LDAP Identity Store"

• Section 23.6.7, "Securing the WebCenter Spaces Connection to OCS with SSL"

• Section 23.6.8, "Securing the WebCenter Spaces Connection to IMAP and SMTP with SSL"

• Section 23.6.9, "Securing the WebCenter Spaces Connection to Oracle SES with SSL"

• Section 23.6.10, "Securing the WebCenter Spaces Connection to OWLCS with SSL"

• Section 23.6.11, "Securing the WebCenter Spaces Connection to Microsoft Live Communication Server with SSL"

Note:

The following can use WS-Security with message protection, and consequently have no hard requirement for SSL:

• BPEL servers - Worklist service

• WSRP Producers

• Oracle WebLogic Communication Services (OWLCS) - IMP service

• Microsoft Live Communication Server (LCS) - IMP service

• Oracle WebCenter Discussions - Discussions and Announcements

23.6.1 Securing the Browser Connection to WebCenter Spaces with SSL

Securing the browser connection to WebCenter Spaces with SSL consists of the following steps:

• Section 23.6.1.1, "Creating the Custom Keystore"

• Section 23.6.1.2, "Configuring the Custom Identity and Java Trust Keystores"

• Section 23.6.1.3, "Configuring the SSL Connection"

23.6.1.1 Creating the Custom Keystore

The first step is to generate a custom keystore for WebCenter Spaces.

To create a custom keystore:

1. Go to JAVA_HOME/bin/ and open a command prompt.

2. Using keytool, generate a key pair:

   keytool -genkeypair -keyalg RSA -dname "dname" -alias alias-keypass key_password -keystore keystore -storepass keystore_password-validity days_valid
   

   Where:

   • dname is the DN (distinguished name) to use (for example, cn=customidentity,dc=example,dc=com)

   • alias is the alias to use (for example, webcenter_wls)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore is the keystore name, (for example, webcenter_wls.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 360).

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

3. Export the certificate containing the public key so WebCenter Spaces clients can import it into their trust store:

   keytool -exportcert -v -alias alias -keystore keystore-storepass keystore_password -rfc -file certificate_file
   

   Where:

   • alias is the WebCenter Spaces alias (for example, webcenter_wls)

   • keystore is the keystore name, (for example, webcenter_wls.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • certificate_file is the file name for the certificate to export the key to (for example, webcenter_wls.cer)

4. Determine the trust store to use:

   Since you are using a self-signed certificate, you must update it as a trusted certificate in the server trust store. To do this, you must determine your trust store by going to the server:

   1. Log into the WebLogic Server Administration Console.

   2. In the Domain Structure pane, expand Environments and click Servers.

   3. In the list of servers, click WLS_Spaces.

   4. Open the Configuration tab, and the Keystores subtab.

      The Keystores Settings pane displays (see Figure 23-39).

      Figure 23-39 Keystores Settings Pane

      
      Description of "Figure 23-39 Keystores Settings Pane"
      
      

   5. Note down the location of the server in the Java Standard Trust Keystore field (shown in Figure 23-39).

      Note that the cacerts file may be "read only", in which case you will need to change it's permissions so that it's writable.

5. Import the self-signed certificate generated above in this trust store:

   keytool -importcert -trustcacerts -alias alias -file certificate_file-keystore cacerts -storepass changeit
   

   Where:

   • alias is the WebCenter Spaces alias (for example, webcenter_wls)

   • certificate_file is the file name for the certificate to export the key to (for example, webcenter_wls.cer)

23.6.1.2 Configuring the Custom Identity and Java Trust Keystores

The next step is to configure the Custom Identity and Java Trust keystores on the WebCenter Spaces server.

To configure the identity and trust keystores:

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane, expand Environment and click Servers.

   The Summary of Servers pane displays (see Figure 23-40).

   Figure 23-40 Summary of Servers Pane

   
   Description of "Figure 23-40 Summary of Servers Pane"
   
   

3. Click the WebCenter Spaces server (WLS_Spaces) to configure the identity and trust keystores.

   The Settings pane for the WebCenter Spaces server displays (see Figure 23-41).

   Figure 23-41 Settings Pane for WebCenter Spaces Server

   
   Description of "Figure 23-41 Settings Pane for WebCenter Spaces Server"
   
   

4. Open the Configuration tab, and then the Keystores subtab.

   The Keystores pane displays (see Figure 23-42).

   Figure 23-42 Keystores Pane

   
   Description of "Figure 23-42 Keystores Pane"
   
   

5. For Keystores, select Custom Identity and Java Standard Trust and click Save.

6. Under Identity, enter the path and filename of the Custom Identity Keystore you created in Section 23.6.1.1, "Creating the Custom Keystore."

7. Enter JKS as the Custom Identity Keystore Type.

8. Enter and confirm the Custom Identity Keystore password.

9. Under Trust, enter and confirm the Java Standard Trust Keystore password.

10. Click Save to save your entries.

11. Open the SSL tab.

12. Enter the Private Key Alias.

13. Enter the Private Key Passphrase.

14. Click Save to save your entries.

23.6.1.3 Configuring the SSL Connection

To configure the SSL connection:

1. On the Settings pane for the WebCenter Spaces server, open the Configuration tab and then the General subtab.

   The General Configuration pane displays (see Figure 23-43).

   Figure 23-43 General Configuration Pane

   
   Description of "Figure 23-43 General Configuration Pane"
   
   

2. Check SSL Listen Port Enabled.

3. Enter an SSL Listen Port number and click Save.

4. Open the SSL subtab and expand the Advanced options at the bottom of the page.

   The SSL advanced options are displayed (see Figure 23-44).

   Figure 23-44 Advanced SSL Configuration Settings

   
   Description of "Figure 23-44 Advanced SSL Configuration Settings"
   
   

5. Set the Two Way Client Cert Behavior option to Client Certs Not Requested and click Save.

6. Open the Control tab.

   The Control Settings pane displays (see Figure 23-45).

   Figure 23-45 Control Settings Pane

   
   Description of "Figure 23-45 Control Settings Pane"
   
   

7. Click Restart SSL.

8. Restart the WebLogic Server and open the SSL WebCenter Spaces URL.

9. Accept the certificate for the session and log in.

23.6.2 Securing the Browser Connection to a Custom WebCenter Application with SSL

Securing the browser connection to a custom WebCenter application uses the same configuration steps as for securing the browser connection to WebCenter Spaces. The only difference is that the configuration occurs on the managed server that is hosting the custom WebCenter application deployment rather than the WLS_Spaces server. For more information, see Section 23.6.1, "Securing the Browser Connection to WebCenter Spaces with SSL."

23.6.3 Securing the Connection from Oracle HTTP Server to WebCenter Spaces with SSL

Securing the connection between the Oracle HTTP Server (OHS) and WebCenter Spaces consists of these steps:

• Configure the Identity and Trust Keystores

• Configure the SSL Connection

• Install OHS

• Wire WebCenter Spaces Ports to OHS

• Configure the SSL Certificates

Configure the Identity and Trust Keystores

For instructions on how to configure the Identity and Trust keystores, see Section 23.6.1, "Securing the Browser Connection to WebCenter Spaces with SSL."

Configure the SSL Connection

1. On the Settings pane for the WebCenter Spaces server, open the Configuration tab and then the General subtab.

   The General Configuration pane displays (see Figure 23-46).

   Figure 23-46 General Configuration Pane

   
   Description of "Figure 23-46 General Configuration Pane"
   
   

2. Check SSL Listen Port Enabled.

3. Enter an SSL Listen Port number and click Save.

4. On the Configuration tab, open the SSL subtab, and then expand the Advanced options at the bottom of the page.

   The SSL advanced options are displayed (see Figure 23-47).

   Figure 23-47 Advanced SSL Configuration Settings

   
   Description of "Figure 23-47 Advanced SSL Configuration Settings"
   
   

5. Set the Two Way Client Cert Behavior option to Client Certs Not Requested and click Save.

6. Open the Control tab on the Settings pane, and select the Start/Stop subtab.

7. Click Restart SSL.

8. Open the SSL WebCenter Spaces URL.

9. Accept the certificate for the session and log in.

10. In the WSL Administration Console, click View Changes and Restarts on the Change Center pane and restart any affected servers or components.

Install OHS

1. Install the WebTier.

   • Do not select WebCache; only select the HTTP Server.

   • Uncheck the checkbox to associate a WebLogic server during install.

2. Navigate to the WT_ORACLE_HOME/instances/<your_instance>/bin directory and start OHS using the following command:

   ./opmnctl startall
   

3. Check the status of OHS using the following command:

   ./opmnctl status -l
   

Wire WebCenter Spaces Ports to OHS

1. Open the file WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/mod_wl.conf.

2. Add the following entry to mod_wl.conf to make WebCenter Spaces work with OHS:

   <IfModule mod_weblogic.c>
           WebLogicHost host_id
           WebLogicPort port
           Debug OFF
           WLLogFile /tmp/ohs.log
           MatchExpression *.jsp
        </IfModule>
    
        <Location />
          SetHandler weblogic-handler
        </Location>
   

   Replacing host_id and port with the WebCenter Spaces server ID and port number.

3. Open the file WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/mod_ssl.conf.

4. Add the following entry to mod_ssl.conf to make WebCenter Spaces run on the OHS SSL port:

   <IfModule mod_weblogic.c>
           WebLogicHost host_id
           WebLogicPort port
           WLLogFile /tmp/ohs_ssl.log
           Debug OFF
           DebugConfigInfo ON
           SecureProxy ON
           MatchExpression *.jsp
           WlSSLWallet SSL_wallet
         </IfModule>
    
        <Location />
          SetHandler weblogic-handler
        </Location>
   

   Replacing host_id and port with the WebCenter SSL server ID and port number, and SSL_wallet with the path to the WebLogic SSL wallet (for example, WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/keystores/default).

5. Go to WT_ORACLE_HOME/instances/<your_instance>/bin and start and check the status of OHS using the following commands:

   ./opmnctl stopall
    
   ./opmnctl startall
   ./opmnctl status -l
   

Configure the SSL Certificates

1. For OHS to trust WebCenter's certificate, the WLS_Spaces certificate must be imported into the OHS trust store. Export the certificate from the WLS_Spaces identity keystore:

   keytool -exportcert -v -alias webcenter_wls -keystore webcenter_wls.jks -storepass <password> -rfc -file webcenter_wls.cer
   

2. Import the certificate into the wallet on the OHS side using orapki:

   orapki wallet add -wallet . -trusted_cert -cert webcenter_wls.cer -auto_login_only
   

3. For WebCenter to trust OHS certificates, export the user certificate from OHS wallet and import it as a trusted certificate in the WebLogic trust store.

   orapki wallet export -wallet . -cert cert.txt  -dn 'CN=\"Self-signed Certificate for ohs1 \",OU=EXAMPLEORGUNIT,O=EXAMPLEORG,L=EXAMPLELOCATION,ST=CA,C=US'
   

4. Import the above certificate into the WLS_Spaces managed server trust store available in /scratch/wcwlsinstall/0408/wlshome/jrockit_160_05_R27.6.2-20/jre/lib/security/cacerts:

   keytool -file cert.txt -importcert -trustcacerts -alias ohs_cert -keystore cacerts -storepass changeit
   

5. Restart OHS and the WLS_Spaces server.

   You should now be able to access the SSL OHS, as well as the non-SSL OHS.

23.6.4 Securing the Browser Connection to the Wiki Service with SSL

As with securing the browser connection to WebCenter Spaces, securing the Wiki service connection with SSL consists of two steps:

• Configure the identity and trust keystores

• Configure the SSL connection

Configure the identity and trust keystores

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane, expand Environment and click Servers.

   The Summary of Servers pane displays (see Figure 23-48).

   Figure 23-48 Summary of Servers Pane

   
   Description of "Figure 23-48 Summary of Servers Pane"
   
   

3. Click the Services server (WLS_Services) to configure the identity and trust keystores.

   The Settings pane for the services server displays (see Figure 23-49).

   Figure 23-49 Settings Pane for Services Server

   
   Description of "Figure 23-49 Settings Pane for Services Server"
   
   

4. Open the Configuration tab, and then the Keystores subtab.

   The Keystores pane displays (see Figure 23-50).

   Figure 23-50 Keystores Pane

   
   Description of "Figure 23-50 Keystores Pane"
   
   

5. For Keystores, select Custom Identity and Java Standard Trust and click Save.

6. Open the Control tab.

   The Control Settings pane displays (see Figure 23-51).

   Figure 23-51 Control Settings Pane

   
   Description of "Figure 23-51 Control Settings Pane"
   
   

7. Click Restart SSL.

Configure the SSL connection

1. On the Settings pane for the Services server, open the Configuration tab and then the General subtab.

   The General Configuration pane displays (see Figure 23-52).

   Figure 23-52 General Configuration Pane

   
   Description of "Figure 23-52 General Configuration Pane"
   
   

2. Check SSL Listen Port Enabled.

3. Enter an SSL Listen Port number and click Save.

4. On the Configuration tab, open the SSL subtab, and then expand the Advanced options at the bottom of the page.

   The SSL advanced options are displayed (see Figure 23-53).

   Figure 23-53 Advanced SSL Configuration Settings

   
   Description of "Figure 23-53 Advanced SSL Configuration Settings"
   
   

5. Set the Two Way Client Cert Behavior option to Client Certs Not Requested and click Save.

6. Restart the WLS_Services server and open the SSL Wiki URL at https://host:port/owc_wiki.

7. Accept the certificate for the session and log in.

23.6.5 Securing the WebCenter Spaces Connection to Portlet Producers with SSL

Securing the connection to WSRP and PDK-Java portlet producers with SSL consists of the following steps:

• Configure the identity and trust keystores

• Configure the SSL connection

• Register the SSL-enabled WSRP producer and run the portlets

• Register the SSL-enabled PDK-Java Producer and run the portlets

Configure the identity and trust keystores

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane, expand Environment and click Servers.

   The Summary of Servers pane displays (see Figure 23-54).

   Figure 23-54 Summary of Servers Pane

   
   Description of "Figure 23-54 Summary of Servers Pane"
   
   

3. Click the Portlet server (for example, WLS_Portlet) to configure the identity and trust keystores.

   The Settings pane for the Portlet server displays (see Figure 23-55).

   Figure 23-55 Settings Pane for Portlet Server

   
   Description of "Figure 23-55 Settings Pane for Portlet Server"
   
   

4. Open the Configuration tab, and then the Keystores subtab.

   The Keystores pane displays (see Figure 23-56).

   Figure 23-56 Keystores Pane

   
   Description of "Figure 23-56 Keystores Pane"
   
   

5. For Keystores, select Custom Identity and Java Standard Trust and click Save.

6. Open the Control tab.

   The Control Settings pane displays (see Figure 23-57).

   Figure 23-57 Control Settings Pane

   
   Description of "Figure 23-57 Control Settings Pane"
   
   

7. Click Restart SSL.

Configure the SSL connection

1. In the Domain Structure pane, expand Environment and select Servers.

2. Click on the Portlet server (for example, WLS_Portlet) for which you want to configure SSL.

3. Select Configuration.

4. Check SSL Listen Port Enable.

5. Enter a listen port number.

6. Select Configuration > SSL, and then open the Advanced options at the bottom of the page.

7. Select the Two Way Client Cert Behavior attribute and choose the Client Certs Not Requested option.

8. Click Save.

9. Restart the WebLogic Server and open the SSL URL.

10. Accept the certificate for the session and log in.

Register the SSL-enabled WSRP producer and run the portlets

1. Configure the WebCenter Spaces managed server to use the Custom Identity and Java Standard Trust store. This also uses the certificates in JAVA_HOME/jre/lib/security/cacerts.

2. Download the certificate of the HTTPS producer URL and save it in .PEM format.

   Use Firefox 3.0 or later to download the certificate directly to .PEM format, or for other browsers use the WebLogic Server der2pem tool to convert to PEM format. For more information about using the der2pem tool, see "der2pem" in the Oracle Fusion Middleware Command Reference for Oracle WebLogic Server. Note that WebLogic does not recognize any other format other than .PEM format.

3. Import the certificate into the cacerts file in JAVA_HOME/jre/lib/security using the following keytool command:

   keytool -importcert -alias portlet_cert -file HOME/portlet_pem -keystore ./cacerts -storepass password
   

   Where:

   • portlet_cert is the portlet certificate alias

   • portlet_pem is the portlet certificate file (for example, portlet_cert.pem)

   • password is the keystore password

4. Restart WLS_Spaces.

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

6. Connect to the 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 WLS_Spaces server (for example, weblogic)

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

   • host_id is the host ID of the Administration Server

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

7. Run the registerWSRPProducer WLST command to register the producer:

   registerWSRPProducer('webcenter', 'sslwsrpprod','producer_wsdl)
   

   Where:

   • sslwsrpprod is the name of the SSL-enabled WSRP producer

   • producer_wsdl is the WSDL URL of the SSL-enabled WSRP producer

   For example:

   registerWSRPProducer('webcenter', 'sslwsrpprod','https://example.oracle.com:7004/richtextportlet/portlets/wsrp2?WSDL')
   

8. Navigate to the HTTP or HTTPS WebCenter URL.

9. Create a page and go to the Portlets link.

10. Go to the registered WSRP producer.

11. Add the portlet to the page.

12. Go to the view mode of the page and check that the WSRP portlet renders correctly.

Register the SSL-enabled PDK-Java Producer and run the portlets

1. Configure the WebCenter Spaces managed server to use the Demo Identity and Trust store. This also uses the certificates in JAVA_HOME/jre/lib/security/cacerts.

2. Log in to the WebLogic Server Administration Console.

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

3. On the Domain Structure pane, expand Environment and click Servers.

   The Summary of Servers pane displays (see Figure 23-58).

   Figure 23-58 Summary of Servers Pane

   
   Description of "Figure 23-58 Summary of Servers Pane"
   
   

4. Click WLS_Spaces in the servers list.

   The Settings pane displays (see Figure 23-59).

   Figure 23-59 Settings Pane (WLS_Spaces Server)

   
   Description of "Figure 23-59 Settings Pane (WLS_Spaces Server)"
   
   

5. Open the Configuration tab and select the Keystores tab.

6. Make sure that the value for Demo Identity and Demo Trust is either jks or left blank.

7. Click Save.

8. Download the certificate of the HTTPS producer URL and save it in .PEM format.

   Use Firefox 3.0 or later to download the certificate directly to .PEM format, or for other browsers use the WebLogic Server der2pem tool to convert to PEM format. For more information about using the der2pem tool, see "der2pem" in the Oracle Fusion Middleware Command Reference for Oracle WebLogic Server. Note that WebLogic does not recognize any other format other than .PEM format.

9. Import the certificate into the cacerts file in JAVA_HOME/jre/lib/security using the following keytool command:

   keytool -importcert HOME/portlet_cert.pem -keystore ./cacerts -storepass changeit
   

10. Restart WLS_Spaces.

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

12. Connect to the 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 WLS_Spaces server (for example, weblogic)

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

    • host_id is the host ID of the Administration Server

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

13. Run the registerPDKJavaProducer command:

    registerPDKJavaProducer('webcenter', 'ssljpdkprod', 'producer_wsdl')
    

    Where:

    • ssljpdkprod is the name of the SSL-enabled PDK-Java producer

    • producer_wsdl is the WSDL URL of the SSL-enabled PDK-Java producer

    This will enable one-way SSL for a Web producer. That is, only the server side (web producer) uses certificates. The Web producer code also uses a shared key feature (discussed later) for client authentication.

14. Go to the HTTP or HTTPS WebCenter URL.

15. Create a page and go to the Portlets link.

16. Go to the registered PDK-Java producer.

17. Add the portlet to the page.

18. Go to the view mode of the page and check that the PDK-Java portlet renders correctly.

23.6.6 Securing the WebCenter Spaces Connection to the LDAP Identity Store

To configure the LDAP server port for SSL, refer to the appropriate administration documentation for the LDAP server. For Oracle Internet Directory (OID), an SSL port is installed by default. To use this port for LDAP communication from WebCenter, the identity store should be configured for authentication with the appropriate authenticator. See Section 23.3, "Configuring the Identity Store" for the steps to do this for the identity store.

Note:

When entering the Provider Specific information, be sure to specify an SSL port and to check the SSL Enabled checkbox.

If the CA is unknown to the Oracle WebLogic server, complete the two additional steps described in the following subsections:

• Exporting the OID Certificate Authority (CA)

• Setting Up the WebLogic Server

For more information, see "Setting Up a One- Way SSL Connection" in the Oracle Fusion Middleware Security Guide.

23.6.6.1 Exporting the OID Certificate Authority (CA)

If the CA is unknown to the Oracle WebLogic server (the command prompts the user to enter the keystore password) you will need to use orapki to create a certificate. The following example shows how to use this command to create the certificate serverTrust.cert:

orapki wallet export -wallet CA -dn "CN=myCA" -cert oid_server_trust.cert

23.6.6.2 Setting Up the WebLogic Server

If the CA is unknown to the Oracle WebLogic server, use the utility keytool to import the Oracle Internet Directory's CA into the WebLogic trust store. The following example shows how to use keytool to import the file oid_server_trust.cert into the server trust store cacerts:

keytool -importcert -v -trustcacerts -alias oid_server_trust -file oid_server_trust.cer -keystore cacerts -storepass changeit

23.6.7 Securing the WebCenter Spaces Connection to OCS with SSL

For instructions on how to configure Oracle Content Server (OCS) for SSL, see Section 11.2.1.2.3, "Configuring Secure Sockets Layer (SSL)." For instructions on adding a trusted certificate to the WebCenter Spaces trust store, see the section on importing the certificate into the trust store in Section 23.6.1.2, "Configuring the Custom Identity and Java Trust Keystores."

23.6.8 Securing the WebCenter Spaces Connection to IMAP and SMTP with SSL

Before reconfiguring the mail server connection, you must first import the certificate into the trust store. Follow the steps below to put the certificate in the trust store and configure WebCenter Spaces to use the trust store.

To secure the WebCenter Spaces connection to IMAP and SMTP with SSL:

1. Open a browser and connect to your IMAP server with the following command:

   https://imapserver:ssl_port
   

   For example:

   https:mailserver.example:993 
   

2. Place your cursor on the page, right-click, and select Properties.

3. Click Certificate.

4. In the popup window, click the Details tab and click Copy to File...

   Be sure to use the DER encoded binary(X.509) format and copy to a file.

5. Convert the .DER format certificate to .PEM format.

   Use Firefox 3.0 or later to download the certificate directly to.PEM format, or for other browsers use the WebLogic Server der2pem tool to convert to PEM format. For more information about using the der2pem tool, see "der2pem" in the Oracle Fusion Middleware Command Reference for Oracle WebLogic Server. Note that WebLogic does not recognize any other format other than .PEM format.

6. Import the certificate into the cacerts in the JAVA_HOME using the following command:

   keytool -import -alias imap_cer -file cert_file.cer -keystore cacerts -storepass changeit
   

   Where cert_file is the name of the certificate file you downloaded.

7. Register the mail server connection as described in Section 15.3, "Registering Mail Servers."

8. Restart Webcenter Spaces.

9. Log into WebCenter Spaces and provide your mail credentials.

23.6.9 Securing the WebCenter Spaces Connection to Oracle SES with SSL

Before registering the SES connection, you must first import the certificate into the trust store. Follow the steps below to put the certificate in the trust store and register the Oracle Secure Enterprise Search (SES) connection.

To download the certificate of the HTTPS URL and save it:

1. Use your browser to navigate to the Web Services URL that Oracle Secure Enterprise Search exposes to enable search requests at:

   http://host:port/search/query/OracleSearch
   

   For example:

   https://example.com:7777/search/query/OracleSearch
   

2. Place your cursor on the page, right-click with your mouse, and select Properties.

3. Click Certificate.

4. In the popup window, open the Details tab, and click Copy to File...

   Use DER encoded binary(X.509) format and copy the certificate to a file.

5. Convert the .DER format certificate to .PEM format.

   Use Firefox 3.0 or later to download the certificate directly to.PEM format, or for other browsers use the WebLogic Server der2pem tool to convert to PEM format. For more information about using the der2pem tool, see "der2pem" in the Oracle Fusion Middleware Command Reference for Oracle WebLogic Server. Note that WebLogic does not recognize any other format other than .PEM format.

6. Import the certificate into DemoTrustKeyStore.jks or cacerts in the JAVA_HOME using one of the following commands:

   keytool -import -alias ses_cer -file cert_file.cer -keystore cacerts -storepass changeit
   

   where cert_file is the name of the certificate file you downloaded.

7. Register the SES connection as described in Section 18.3.1, "Registering Oracle SES Services."

8. Restart WebCenter Spaces.

23.6.10 Securing the WebCenter Spaces Connection to OWLCS with SSL

To secure the WebCenter Spaces connection to Oracle WebLogic Communication Services (OWLCS) with SSL, follow the steps below to import the certificate into the trust store, and point WebCenter Spaces to use the trust store. Note that securing the WebCenter Spaces connection to OWLCS with SSL is optional since OWLCS can be configured with confidentiality using WS-Security. See Section 23.8.4, "Securing Oracle WebLogic Communication Services (OWLCS) with WS-Security."

Before registering the OWLCS connection, you must first import the certificate into the trust store. Follow the steps below to put the certificate in the trust store:

1. Open your browser and go to the OWLCS server (for example, https://example.com:port/PresenceConsumerService/services/PresenceConsumer)

2. Place your cursor on the page, right-click, and select Properties.

3. Click Certificate.

4. In the popup window, open the Details tab and click Copy to File...

   Use Firefox 3.0 or later to download the certificate directly to.PEM format, or for other browsers use the WebLogic Server der2pem tool to convert to PEM format. For more information about using the der2pem tool, see "der2pem" in the Oracle Fusion Middleware Command Reference for Oracle WebLogic Server. Note that WebLogic does not recognize any other format other than .PEM format.

5. Import the certificate into the cacerts using the following keytool command:

   keytool -import -alias owlcs_cer -file cert_file.cer -keystore cacerts -storepass changeit
   

   where cert_file is the name of the certificate file you downloaded.

6. Locate the cacerts file used by the OWLCS server in the OWLCS installation, and also update the OWLCS referenced cacerts file with this certificate:

   keytool -import -alias owlcs_cer -file cert_file.cer -keystore cacerts -storepass changeit
   

7. Register the Oracle WebLogic Communication Services connection as described in Section 14.3, "Registering Instant Messaging and Presence Servers."

8. Restart the WebCenter Spaces server.

23.6.11 Securing the WebCenter Spaces Connection to Microsoft Live Communication Server with SSL

To secure the WebCenter Spaces connection to Microsoft Live Communication Server with SSL, follow the steps below to import the certificate into the trust store, and point WebCenter Spaces to use the trust store. Note that securing the WebCenter Spaces connection to Microsoft Live Communication Server with SSL is optional since Microsoft Live Communication Server can be configured with confidentiality using WS-Security.

Before registering the LCS connection, you must first import the certificate into the trust store. Follow the steps below to put the certificate in the trust store:

1. Open your browser and go to the Microsoft Live Communication Server (for example, https://example.com:port/PresenceConsumerService/services/PresenceConsumer)

2. Place your cursor on the page, right-click, and select Properties.

3. Click Certificate.

4. In the popup window, open the Details tab and click Copy to File...

   Use Firefox 3.0 or later to download the certificate directly to.PEM format, or for other browsers use the WebLogic Server der2pem tool to convert to PEM format. For more information about using the der2pem tool, see "der2pem" in the Oracle Fusion Middleware Command Reference for Oracle WebLogic Server. Note that WebLogic does not recognize any other format other than .PEM format.

5. Import the certificate into the cacerts using the following keytool command:

   keytool -import -alias lcs_cer -file cert_file.cer -keystore cacerts -storepass changeit
   

   where cert_file is the name of the certificate file you downloaded.

6. Locate the cacerts file used by the Microsoft Live Communication Server in the Microsoft Live Communication Server installation, and also update the Microsoft Live Communication Server referenced cacerts file with this certificate:

   keytool -import -alias lcs_cer -file cert_file.cer -keystore cacerts -storepass changeit
   

7. Register the Microsoft Live Communication Server connection as described in Section 14.3, "Registering Instant Messaging and Presence Servers."

8. Restart the WebCenter Spaces server.

23.7 Configuring a WebCenter Application to Use Single Sign-On

Oracle Access Manager (OAM), part of Oracle's enterprise class suite of products for identity management and security, provides a wide range of identity administration and security functions, including several single sign-on options for WebCenter Spaces and custom WebCenter applications. OAM is the recommended single sign-on solution for Oracle WebCenter 11g installations.

For deployment environments that are already invested in Oracle 10g infrastructure, and where the Oracle Application Server Single Sign-On (OSSO) server is used as the primary SSO solution, WebCenter 11g can also be configured to use OSSO for single sign-on.

For smaller scale Oracle WebCenter 11g installations, where you do not have an enterprise-class single sign-on infrastructure like Oracle Access Manager or Oracle SSO, and you only need to provide a single sign-on capability within WebCenter Spaces and its associated web applications like Wiki, Discussions, RSS and Worklist, you can configure a SAML-based SSO solution. If you need to provide single sign-on with other enterprise applications, this solution is not recommended.

If your enterprise uses Microsoft desktop logins that authenticate with a Microsoft domain controller with user accounts in Active Directory, then configuring SSO with Microsoft Clients may also be an option to consider.

The setup required for each of these SSO solutions is described in the following subsections:

• Section 23.7.1, "Configuring Oracle Access Manager (OAM)"

• Section 23.7.2, "Configuring Oracle Single Sign-On (OSSO)"

• Section 23.7.3, "Configuring SAML-based Single Sign-on"

• Section 23.7.4, "Configuring SSO with Microsoft Clients"

23.7.1 Configuring Oracle Access Manager (OAM)

Oracle Access Manager (OAM) provides flexible and extensible authentication and authorization, and provides audit services. This section describes how to configure WebCenter Spaces and custom WebCenter applications for OAM single sign-on authentication, including how to configure the WebLogic server side and the WebCenter application as the partner application participating in SSO.

Much of the configuration can be done using scripts (recommended). To use the scripts, follow the instructions in Section 23.7.1.2, "Configuring OAM Using Scripts," and complete the instructions in Section 23.7.1.3, "Configuring the Webtier Components" and Section 23.7.1.6, "Configuring the Policy Manager," and any additional configurations as appropriate in Section 23.7.1.7, "Additional Configurations."

To perform the configuration manually, complete the instructions in all of the subsections, with the exception of Section 23.7.1.2, "Configuring OAM Using Scripts."

The scripted and equivalent manual configuration steps are presented in the following subsections:

• Section 23.7.1.1, "OAM Components and Topology"

• Section 23.7.1.2, "Configuring OAM Using Scripts"

• Section 23.7.1.3, "Configuring the Webtier Components"

• Section 23.7.1.4, "Manually Configuring the Access System"

• Section 23.7.1.5, "Manually Defining the WebCenter Policy Domain"

• Section 23.7.1.6, "Configuring the Policy Manager"

• Section 23.7.1.7, "Additional Configurations"

23.7.1.1 OAM Components and Topology

Figure 23-60 shows the components and topology required to set up single sign-on with Oracle Access Manager for a WebCenter application.

Figure 23-60 OAM Single Sign-On Components and Topology

Description of "Figure 23-60 OAM Single Sign-On Components and Topology"

OAM consists of the following components:

• Access Server - a standalone server that provides authentication, authorization, and auditing services for Access Gates. There is one access server set up on OAM. This is done as part of the OAM install itself.

• WebGate - an out-of-the-box plugin that intercepts Web resource (HTTP) requests and forwards them to the Access Server for authentication and authorization.

• Identity Assertion Provider (IAP) - a type of security provider that asserts the identity of the user based on header information that is set by perimeter authentication. The OAM integration provides an OAM ID Asserter that can be configured as the OAM IAP. The OAM ID Asserter can be used for authentication or for identity assertion. For OAM SSO integration, the OAM ID Asserter should be configured as an Identity Assertion Provider (IAP) by selecting obSSOCookie under Active Types in the provider's Common settings.

23.7.1.2 Configuring OAM Using Scripts

These steps assume that you've installed Oracle WebCenter (see Section 2.3, "Installing WebCenter Spaces"). By default, an Oracle WebCenter installation creates a WebLogic Server domain, including an Administration Server and three managed servers: WLS_Spaces, WLS_Services and WLS_Portlet.

1. Install the WebTier, which contains the Oracle HTTP Server (OHS) and mod_wl (see the Oracle Fusion Middleware Installation Guide for Oracle WebCenter for information on how to install the WebTier).

2. Configure the module mod_wl in the WebTier OHS so that it forwards requests to the Oracle WebLogic Server for WebCenter, as described in Section 23.7.1.3.1, "Configure mod_weblogic (mod_wl_ohs.conf)."

3. Determine which access server to use.

   1. Log onto the Access Manager.

   2. Click Access System Console.

   3. Open the Access System Configuration tab.

   4. Click Access Server Configuration to display a list of all access servers.

   5. Click an access server in the list to see server details.

      The host name and port are the values you need for the oam_aaa_host and oam_aaa_port parameters respectively in the script.

4. Run the following command.

   The oamcfgtool.jar is available in ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar in the WebCenter installation. Values in bold are the one that you need to supply based on the settings of your WebCenter and OAM instances.

   java -jar ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar mode=CREATE app_domain="your_domain_name"
   protected_uris="/webcenter/adfAuthentication,/webcenter/content,/owc_wiki/user/login.jz,/owc_wiki/adfAuthentication,/integration/worklistapp,
   /workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow,/workflow/WebCenterWorklistDetail/faces/adf.task-flow,
   /workflow/sdpmessagingsca-ui-worklist,/rss/rssservlet,/owc_discussions/login!withRedirect.jspa,
   /owc_discussions/login!default.jspa,/owc_discussions/login.jspa,/owc_discussions/admin,/rest"
   public_uris="/webcenter,/owc_wiki,/owc_discussions,/rss,/workflow" 
   app_agent_password=<Password to be provisioned for App Agent> 
   ldap_host=<Hostname of LDAP server> ldap_port=<Port of LDAP server> 
   ldap_userdn=<DN of LDAP Admin User, usually "cn=orcladmin"> 
   ldap_userpassword=<Password of LDAP Admin User> oam_aaa_host=<HOST of OAM server> oam_aaa_port=<Port of OAM server>
   

   We recommend that you register your domain (for <your_domain_name>) as something like "webtier.example.com", where "webtier.example.com" is your Webtier, so that you can easily distinguish the various policies in OAM.

   If your command ran successfully, you should see something like the following output depending on the values you used:

   Processed input parameters
   Initialized Global Configuration
   Successfully completed the Create operation.
   Operation Summary:
   Policy Domain : webtier.example.com
   Host Identifier: webtier.example.com
   Access Gate ID : webtier.example.com_AG
   

   You can also run the Validate command to validate your configurations:

   java -jar WC_ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar mode=VALIDATE app_domain="your_domain_name" 
   ldap_host=<Hostname of LDAP server> ldap_port=<Port of LDAP server>
   *ldap_userdn=<DN of LDAP Admin User, usually "cn=orcladmin">* 
   ldap_userpassword=<Password of LDAP Admin User> oam_aaa_host=<HOST of OAM server> oam_aaa_port=<Port of OAM server>
   test_username=<Username to be used for policy validation> test_userpassword=<Userpassword to be used for policy validation>
   

   If your command runs successfully, you should see the same output as above.

5. Check the Policy Domain settings.

   1. Log on to the Oracle Access Manager.

   2. Click Policy Manager.

   3. Click My Policy Domains.

      You should see the domain you just created in the list of policy domains. In the URL prefixes column, you should also see the URIs you specified during the creation of this domain.

   4. Click the domain you just created and open the Resources tab.

      The URIs you specified should be showing. You can also open other tabs to view and verify other settings, and manually add additional resources later, if required.

6. Check the Access Gate Configurations.

   1. Click on Access System Console.

   2. Open the Access System Configuration tab.

   3. Click AccessGate Configuration.

   4. Enter some search criteria and click Go.

   5. When the Access Gate for the domain you just created shows up (it will have the suffix _AG), click on it to see the setting details.

7. Run the WebGate Installer as described in the section on "Installing the WebGate" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

   The InstallShield Wizard will prompt you for several inputs during the installation. Supply the information requested based on the settings for your environment.

8. Continue with the steps for configuring the Policy Manager in Section 23.7.1.6, "Configuring the Policy Manager," and any further configurations, as required, in Section 23.7.1.7, "Additional Configurations."

23.7.1.3 Configuring the Webtier Components

Configuring the Webtier components is described in the following sections:

• Configure mod_weblogic (mod_wl_ohs.conf)

• Create an AccessGate Entry

• Install WebGate on the WebTier

23.7.1.3.1 Configure mod_weblogic (mod_wl_ohs.conf)

Configure the module mod_wl in the WebTier OHS so that it forwards requests to the Oracle WebLogic Server for WebCenter, by uncommenting lines at WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/mod_wl_ohs.conf. This file is included by the httpd.conf file.

To configure Web Tier OHS to work with multiple non-clustered servers, use the example below in mod_wl_ohs.conf. Make sure that the WebLogic port numbers match your configuration.

<IfModule mod_weblogic.c>
MatchExpression  /webcenter   WebLogicHost=webcenter.example.com|WebLogicPort=8888
MatchExpression  /rss         WebLogicHost=webcenter.example.com|WebLogicPort=8890
MatchExpression  /owc_wiki    WebLogicHost=webcenter.example.com|WebLogicPort=8890
MatchExpression  /owc_discussions  WebLogicHost=webcenter.example.com|WebLogicPort=8890
MatchExpression /workflow WebLogicHost=soa.example.com|WebLogicPort=8888
MatchExpression /integration/worklistapp WebLogicHost=soa.example.com|WebLogicPort=8888
MatchExpression /integration/services WebLogicHost=soa.example.com|WebLogicPort=8888
MatchExpression /soa-infra WebLogicHost=soa.example.com|WebLogicPort=8888
MatchExpression /rest WebLogicHost=webcenter.example.com|WebLogicPort=8890
</IfModule>

Note:

The entries in the MatchExpression list above map the incoming paths to the appropriate WebLogic Server managed servers on which the corresponding applications reside.

23.7.1.3.2 Create an AccessGate Entry

An AccessGate entry needs to be created on the Access Manager to be shared by the OAM Identity Assertion Provider (IAP), and the WebGate performing perimeter authentication on the webtier reverse proxy.

Note:

If you are doing the configuration using the oamcfgtool scripted installation, this step is not required, as the installation script does it automatically.

To create an AccessGate entry:

1. Log in to the Access Server Console using your browser to navigate to:

   http://host:port/access/oblix
   

   Where host is the host ID of the server hosting the Access Manager (for example, oam.example.com), and port is the HTTP port number (for example, 8888).

2. Open the Access System Configuration page.

3. Click Add New AccessGate to create a new AccessGate entry.

4. Click List Access Servers on the Details pane and bind the AccessGate to the Access Server that has been set up for OAM Single Sign-on.

Some of the settings specified here will be needed for WebGate installation and OAM Identity Assertion Provider (IAP) setup. Table 23-3 shows settings for a typical AccessGate entry.

Table 23-3 Sample Settings for AccessGate Entry

Setting	Value
AccessGate Name	webcenter-access-gate
Description
State	Enabled
Hostname	webtier.example.com
Port	9010
Access Gate Password	<Not Displayed>
Debug	Off
Maximum user session time (seconds)	3600
Idle Session Time (seconds)	3600
Maximum Connections	1
Transport Security	Open
IPValidation	On
IPValidationException
Maximum Client Session Time (hours)	24
Failover threshold	1
Access server timeout threshold
Sleep For (seconds)	60
Maximum elements in cache	100000
Cache timeout (seconds)	1800
Impersonation username
Impersonation password	<Not Displayed>
ASDK Client
Access Management Service	On
Web Server Client
Primary HTTP Cookie Domain	.example.com
Preferred HTTP Host	webtier.example.com:9010
Deny On Not Protected	Off
CachePragmaHeader	no-cache
CacheControlHeader	no-cache
LogOutURLs

23.7.1.3.3 Install WebGate on the WebTier

This section describes how to install the WebGate.

To install the WebGate:

1. Copy the ZIP file (Oracle_Access_Manager10_1_4_3_0_linux_GCClib.zip) containing the two gcc libraries required for the installation (libgcc_s.so.1 and libstdc++.so.5) to a /tmp directory.

2. Run the installation as root. For example, from the /tmp directory run:

   sudo -u root ./Oracle_Access_Manager10_1_4_3_0_linux_OHS11g_WebGate
   

3. Follow the installation runtime instructions, providing the installation directory, information of the AccessGate that you created earlier and the absolute path to the httpd.conf file of the web server. For example:

   WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/httpd.conf
   

   Information for the AccessGate can be found in the Access System Console. For more information, see Section 23.7.1.3.2, "Create an AccessGate Entry."

4. After the installation a new section is inserted in the httpd.conf file between the following entries:

   #** BEGIN WEBGATE SPECIFIC ***
   #** END Oblix NetPoint Specific ***  
   

   Check to see if the content is consistent with your environment.

23.7.1.4 Manually Configuring the Access System

To configure the Access System, you need to add a host identifier:

1. Log in to the Access Server Console using your browser to navigate to:

   http://host:port/access/oblix
   

   Where host is the host ID of the server hosting the Access Manager (for example, oam.example.com), and port is the HTTP port number (for example, 8888).

2. Open the Access System Configuration page.

3. On the navigation pane, click Host Identifiers.

4. Add a host identifier for the webtier and enter the Host Identifier name (for example, webtier), a Description, and all Hostname variations. The hostname variations should include all the ways that a browser could issue a request to the webtier. For example, webtier and webtier.example.com if the webtier is using the default port; and additionally webtier:8080 and webtier.example.com:8080 if the webtier is not using the default port.

23.7.1.5 Manually Defining the WebCenter Policy Domain

This section describes the steps to set up the WebCenter Policy Domain that will configure the WebCenter application for OAM SSO authentication.

To configure the WebCenter Policy Domain:

1. Log in to the Access Server Console using your browser to navigate to:

   http://host:port/access/oblix
   

   where host is the host ID of the server hosting the Access Manager (for example, oam.example.com), and port is the HTTP port number (for example, 8888).

2. Click Policy Manager.

   The Policy Manager pane displays (see Figure 23-61).

   Figure 23-61 Policy Manager Pane

   
   Description of "Figure 23-61 Policy Manager Pane"
   
   

3. Click Create Policy Domain in the Navigation pane to create a new policy domain to protect the WebCenter resources.

   The Create Policy Domain page displays (see Figure 23-62).

   Figure 23-62 Create Policy Domain Page

   
   Description of "Figure 23-62 Create Policy Domain Page"
   
   

4. Enter a Name (for example, webtier.example.com) and Description for the policy domain and click Save.

5. Open the Resources tab and click Add.

   The Resource page displays (see Figure 23-63).

   Figure 23-63 Policy Domain Resource Page

   
   Description of "Figure 23-63 Policy Domain Resource Page"
   
   

6. Add the resources that need to be secured. For each resource:

   1. Select http as the Resource Type.

   2. Select the Host Identifier for the WebCenter webtier.

   3. Enter the URL Prefix for the resources you want to protect. The following resources can be protected:

      /adf.task-flow
      /faces/adf.task-flow
      /integration/worklistapp
      /owc_discussions/login!withRedirect.jspa
      /owc_discussions/login!default.jspa
      /owc_discussions/login.jspa
      /owc_discussions/admin
      /owc_wiki/user/login.jz
      /owc_wiki/acl
      /owc_wiki/adfAuthentication
      /owc_wiki/admin
      /owc_wiki/attachments
      /owc_wiki/default
      /owc_wiki/domain
      /owc_wiki/export
      /owc_wiki/index_dir
      /owc_wiki/install
      /owc_wiki/js
      /owc_wiki/layouts
      /owc_wiki/macro
      /owc_wiki/page
      /owc_wiki/pages
      /owc_wiki/remote
      /owc_wiki/tags
      /owc_wiki/templates
      /owc_wiki/user
      /owc_wiki/vhost
      /owc_wiki/wp
      /rss/rssservlet
      /rest
      /webcenter/adfAuthentication
      /webcenter/content
      /workflow/sdpmessagingsca-ui-worklist
      /workflow/WebCenterWorklistDetail/faces
      /workflow/sdpmessagingsca-ui-worklist
      

   4. Enter a Description for the resource.

   5. Make sure that Update Cache is selected, and then click Save.

   6. Enter the URL Prefix for the context roots of the public resources. The following context roots should be added if the corresponding component is installed:

      /owc_discussions
      /owc_wiki
      /rss
      /webcenter
      /workflow
      

7. Enter a Description for each context root, make sure that Update Cache is selected, and then click Save.

8. Open the Authorization Rules tab and click Add.

   The Authorization Rules page displays (see Figure 23-64).

   Figure 23-64 Authorization Rules Page

   
   Description of "Figure 23-64 Authorization Rules Page"
   
   

9. Enter a Name for the new rule (for example, Default_Authorization) and Description.

10. Select Yes for Enabled, and No for Allow takes precedence, and click Save.

11. Click Allow Access on the Authorization Rules tab and click Add.

    The Allow Access page displays (see Figure 23-65).

    Figure 23-65 Allow Access Page

    
    Description of "Figure 23-65 Allow Access Page"
    
    

12. In the Role drop down list, select Any one and click Save.

13. Open the Default Rules tab and click Add.

    The Access Manager Authentication Rule page displays (see Figure 23-66).

    Figure 23-66 Access Manager Authentication Rules Page

    
    Description of "Figure 23-66 Access Manager Authentication Rules Page"
    
    

14. Enter a Name (for example, Default_SSO) and Description for the rule.

15. Set the Authentication Scheme to Oracle: Form Authentication (or a form-based authentication scheme that was previously created) and click Save.

16. Click Authorization Expression on the Default Rules tab, and click Add.

    The Authorization Expression page displays (see Figure 23-67).

    Figure 23-67 Authorization Expression Page

    
    Description of "Figure 23-67 Authorization Expression Page"
    
    

17. Add the Default-Authorization authorization rule (or the rule you created previously) to the Authorization Expression and click Add to add it to the Authorization Expression list.

18. Click Save.

19. Click Actions on the Authorization Expression subtab and click Add.

    The Actions page displays (see Figure 23-68).

    Figure 23-68 Actions Page

    
    Description of "Figure 23-68 Actions Page"
    
    

20. Under Authorization Success, specify what actions should be invoked when the authorization succeeds. Add two Return Attribute entries, specifying the Return Type, Name and Return Attribute as:

    • HeaderVar, OAM_REMOTE_USER, uid

    • HeaderVar, REMOTE_USER, uid

      Note:

      Be careful not to put these values under the row for Return Value. The settings should be placed under Return Attribute.

21. Click Save.

22. Open the Policies tab and click Add.

    The Policies page displays (see Figure 23-69).

    Figure 23-69 Policies Page

    
    Description of "Figure 23-69 Policies Page"
    
    

23. Use the settings below to add a new policy to protect protected URIs under /context-root in app_domain:JSessionPolicyTest when ;jsessionid* is appended to them as shown in Figure 23-69. Note that /context-root must itself also be listed as a resource.

    • Policy Name: Protected_JSessionId_Policy

    • Description: This policy is used to protect protected URIs under /context-root in app_domain:JSessionPolicyTest when ;jsessionid* is appended to them.

    • Resource Type: http

    • Resource Operation(s): GET / POST

    • Resource: Select all

    • URL Pattern: Enter *;jsessionid=*

    • Host Identifiers: Select the Host Identifier (the host identifier of the WebCenter webtier) to which to apply the policy (for example, webtier.example.com)

    The Authentication Rule and Authorization Expression settings under the corresponding tabs can be left as Default.

24. Click Save.

25. Open the Policies tab again.

    A list of policies for the current domain displays (see Figure 23-70).

    Figure 23-70 Policies List

    
    Description of "Figure 23-70 Policies List"
    
    

26. Click Add and use the following settings to add the policy that will identify which resources are to be secured to trigger authentication.

    • Policy Name: Enter a name (for example, Public URI Policy)

    • Description: Enter a description (for example "This policy identifies which resources are to be secured to trigger authentication.")

    • Resource Type: Select http.

    • Resource Operation(s): Select GET / POST.

    • Resource: Select the context roots you added in step 6. Note that /webcenter must always be selected.

    • Host Identifiers: Select the Host Identifier (the host identifier of the WebCenter webtier) to which to apply the policy (for example, webtier.example.com).

27. Click Save.

28. Open the Policies tab again and click Order.

    A tool you can use to set the order for policies currently defined for the domain displays (see Figure 23-71).

    Figure 23-71 Order Tool

    
    Description of "Figure 23-71 Order Tool"
    
    

29. Use the Order tool to make sure that Protected_JSessionId_Policy is at the top of the list.

30. Click Save.

23.7.1.6 Configuring the Policy Manager

Configuring the Policy Manager is described in the subsections below.

• Section 23.7.1.6.1, "Configuring the Oracle Internet Directory Authenticator"

• Section 23.7.1.6.2, "Configuring the OAM Identity Asserter"

• Section 23.7.1.6.3, "Configuring the Default Authenticator and Setting the Provider Order"

• Section 23.7.1.6.4, "Configuring the Application for Oracle Access Manager SSO"

23.7.1.6.1 Configuring the Oracle Internet Directory Authenticator

Assuming Oracle Internet Directory is backing the OAM identity store, an Oracle Internet Directory authenticator (OracleInternetDirectoryAuthenticator) should be configured for the LDAP server that is used as the identity store of OAM, and the provider should be set to SUFFICIENT.

To configure the Oracle Internet Directory authenticator:

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-72).

   Figure 23-72 Summary of Security Realms Pane

   
   Description of "Figure 23-72 Summary of Security Realms Pane"
   
   

3. Click the realm entry for which to configure the OAM authenticator.

   The Settings pane for the realm displays (see Figure 23-73).

   Figure 23-73 Settings Pane

   
   Description of "Figure 23-73 Settings Pane"
   
   

4. Open the Providers tab.

   The Provider Settings display (see Figure 23-74).

   Figure 23-74 Settings Pane - Providers

   
   Description of "Figure 23-74 Settings Pane - Providers"
   
   

5. Click New to create a new provider.

   The Create a New Authentication Provider pane displays (see Figure 23-75).

   Figure 23-75 Create a New Authentication Provider Pane

   
   Description of "Figure 23-75 Create a New Authentication Provider Pane"
   
   

6. Enter a name for the new provider (for example, OID Authenticator), select OracleInternetDirectoryAuthenticator as its type and click OK.

7. On the Providers tab, click the newly added provider.

   The Common Settings pane for the authenticator displays (see Figure 23-76).

   Figure 23-76 Common Settings Pane

   
   Description of "Figure 23-76 Common Settings Pane"
   
   

8. Set the control flag to SUFFICIENT and click Save.

9. Open the Provider Specific tab.

   The Provider Specific Settings pane for the authenticator displays (see Figure 23-77).

   Figure 23-77 Provider Specific Settings for OID Authenticator

   
   Description of "Figure 23-77 Provider Specific Settings for OID Authenticator"
   
   

10. Complete the fields as shown in the table below. Leave the rest of the fields set to their default values.

    Field	Value	Comment
    Host:		The host ID for the LDAP server
    Port:		The LDAP server port number
    Principal:		The LDAP administrator principal (for example, cn=orcladmin)
    Credential:	<password>	The administrator principal password
    Confirm Credential:	<password>
    User Base DN:		User Search Base - this value would be same as #1.d in OAM Access Manager Setup
    All Users Filter:	"(&(uid=*)(objectclass=person))"
    User Name Attribute:	"uid"
    Group Base DN:		Group search base - Same as User Base DN

    
    

11. Click Save.

12. Restart the WebCenter Administration Server and managed server and validate the configuration by navigating to the Realm Settings page in the WebLogic Server Administration Console and opening the Users and Groups tab.

23.7.1.6.2 Configuring the OAM Identity Asserter

An OAM identity asserter needs to be configured with the provider Control Flag set to REQUIRED.

To configure the OAM Identity asserter:

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-78).

   Figure 23-78 Summary of Security Realms Pane

   
   Description of "Figure 23-78 Summary of Security Realms Pane"
   
   

3. Click the realm entry for which to configure the OAM identity asserter.

   The Settings pane for the realm displays (see Figure 23-79).

   Figure 23-79 Settings Pane

   
   Description of "Figure 23-79 Settings Pane"
   
   

4. Open the Providers tab.

   The Provider Settings display (see Figure 23-80).

   Figure 23-80 Settings Pane - Providers

   
   Description of "Figure 23-80 Settings Pane - Providers"
   
   

5. Click New to create a new provider.

   The Create a New Authentication Provider pane displays (see Figure 23-81).

   Figure 23-81 Create a New Authentication Provider Pane

   
   Description of "Figure 23-81 Create a New Authentication Provider Pane"
   
   

6. Enter a name for the new provider (for example, OAM ID Asserter), select OAMIdentityAsserter as its type and click OK.

7. On the Providers tab, click the newly added provider.

   The Common Settings pane for the authenticator displays (see Figure 23-82).

   Figure 23-82 Common Settings Pane

   
   Description of "Figure 23-82 Common Settings Pane"
   
   

8. Set the control flag to REQUIRED and check that ObSSOCookie is set for Active Types.

9. Click Save.

10. Open the Provider Specific tab.

    The Provider Specific Settings pane for the OAMIdentityAsserter displays (see Figure 23-83).

    Figure 23-83 Provider Specific Settings for the OAMIdentityAsserter

    
    Description of "Figure 23-83 Provider Specific Settings for the OAMIdentityAsserter"
    
    

11. Complete the fields as shown in the table below. Leave the rest of the fields set to their default values.

    Field	Value	Comment
    Primary Access Server:		The OAM server endpoint information in HOST:PORT format
    Access Gate Name:		Name of the Access Gate
    Access Gate Password:		Provide the Access Gate password and confirm in the field below.

    
    

12. Click Save to save your settings.

23.7.1.6.3 Configuring the Default Authenticator and Setting the Provider Order

After configuring the OAM identity asserter, make sure that the default authenticator's control flag is set to SUFFICIENT and reorder the providers as shown below:

1. Navigate to the Provider Settings pane (see Figure 23-80).

2. Open the Default Authenticator and check that the control flag is set to SUFFICIENT.

3. Do the same for any providers other than the two you just created.

4. On the Settings Pane, reset the provider order to:

   • OAMIdentityAsserter (REQUIRED)

   • OracleInternetDirectoryAuthenticator (SUFFICIENT)

   • DefaultAuthenticator (SUFFICIENT)

   • DefaultIdentityAsserter

23.7.1.6.4 Configuring the Application for Oracle Access Manager SSO

Configure the applications for SSO by adding a setting to EXTRA_JAVA_PROPERTIES.

There is a system property that tells WebCenter and ADF that the application is configured in SSO mode and some special handling is required. The following system property is required in this mode:

Field	Value	Comment
oracle.webcenter.spaces.osso	true	This flag tells WebCenter that SSO is being used, so no login form should be displayed on the default landing page. Instead, it will render a login link that the user can click to invoke the SSO authentication.

To set this property, edit the setDomainEnv.sh script located in your <domain>/bin directory. Add the property to the EXTRA_JAVA_PROPERTIES variable, as follows:

EXTRA_JAVA_PROPERTIES="-Dweblogic.security.SSL.ignoreHostnameVerification=true -Doracle.mds.bypassCustRestrict=true
-Djps.update.subject.dynamic=true -Doracle.webcenter.spaces.osso=true
-noverify ${EXTRA_JAVA_PROPERTIES}"

After making this change, restart the following servers:

• WebCenter's Administration Server

• All the domain's managed servers

• WebTier OHS

23.7.1.7 Additional Configurations

The configurations described in the following sections may be necessary or helpful in providing additional security for your site:

• Section 23.7.1.7.1, "Configuring the WebLogic Server Administration Console and Enterprise Manager"

• Section 23.7.1.7.2, "Configuring the Discussions Server for SSO"

• Section 23.7.1.7.3, "Creating a Discussions Server Connection for WebCenter Spaces"

• Section 23.7.1.7.4, "Configuring the Wiki Server"

• Section 23.7.1.7.5, "Restricting Access with Connection Filters"

23.7.1.7.1 Configuring the WebLogic Server Administration Console and Enterprise Manager

This section describes how to optionally set up OAM single sign-on for the WebLogic Server Administration Console and Enterprise Manager.

Note:

Setting up OAM SSO for Enterprise Manager and the WebLogic Server Administration Console would provide single sign-on access to same set of users for whom OAM SSO access has been configured. If want the Webtier to be accessible to external users through OAM, but want administrators to log in directly to Enterprise Manager and the WebLogic Server Administration Console, then you may not want to complete this additional configuration step.

To set up OAM SSO for the WebLogic Server Administration Console and Enterprise Manager:

1. Log in to the Access Server Console using your browser to navigate to:

   http://host:port/access/oblix
   

   Where host is the host ID of the server hosting the Access Manager (for example, oam.example.com), and port is the HTTP port number (for example, 8888).

2. Click Policy Manager.

   The Policy Manager pane displays (see Figure 23-84).

   Figure 23-84 Policy Manager Pane

   
   Description of "Figure 23-84 Policy Manager Pane"
   
   

3. Search for the policy domain that you created earlier to protect WebCenter resources in Section 23.7.1.5, "Manually Defining the WebCenter Policy Domain."

4. Open the Resources tab and click Add.

   The Resource page displays (see Figure 23-85).

   Figure 23-85 Policy Domain Resource Page

   
   Description of "Figure 23-85 Policy Domain Resource Page"
   
   

5. Add the resources that need to be secured. For each resource:

   1. Select http as the Resource Type.

   2. Select the Host Identifier for the WebCenter webtier.

   3. Enter the URL Prefix for the WebLogic Server Administration Console or Enterprise Manager.

   4. Enter a Description for the resource.

   5. Make sure that Update Cache is selected, and then click Save.

6. In your webtier, modify the mod_wl_ohs.conf file (in WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/) to include the WebLogic Server Administration Console and Enterprise Manager, using the actual host ID for the WebCenter Administration Server for WebLogicHost.

   <IfModule mod_weblogic.c>
     MatchExpression  /webcenter WebLogicHost=example.com|WebLogicPort=8888
     MatchExpression  /rss WebLogicHost=example.com|WebLogicPort=8888
     MatchExpression  /owc_wiki WebLogicHost=example.com|WebLogicPort=8890
     MatchExpression  /owc_discussions WebLogicHost=example.com|WebLogicPort=8890
     MatchExpression /rest  WebLogicHost=example.com|WebLogicPort=8890
     MatchExpression  /console WebLogicHost=example.com|WebLogicPort=7001
     MatchExpression  /em WebLogicHost=example.com|WebLogicPort=7001
   </IfModule>
   

7. Restart the Oracle HTTP Server for your changes to take effect.

   You should now be able to access the WebLogic Server Administration Console and Enterprise Manager with the following links:

   http://host:OHS port/console
   http://host:OHS port/em
   

   and be prompted with the OAM SSO login form.

23.7.1.7.2 Configuring the Discussions Server for SSO

This section describes how to configure Oracle WebCenter Discussions Server for single sign-on. Before configuring the discussions server for SSO, be sure that it has been configured to use the same identity store LDAP as WebCenter Spaces, as described in Section 23.3.4.1, "Migrating the WebCenter Discussions Server to use an External LDAP."

To set up the discussions server for SSO:

1. Log in to the Oracle WebCenter Discussions Server Admin Console at:

   http://host:port/owc_discussions/admin
   

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

2. Open the System Properties page and edit (if it already exists) or add the owc_discussions.sso.mode property, setting it's value to true.

3. Edit or add the jiveURL property to point to the base URL of the SSO server. For example:

   jiveURL = example.com:8890/owc_discussions
   

23.7.1.7.3 Creating a Discussions Server Connection for WebCenter Spaces

To create a discussions server connection for WebCenter Spaces:

1. Log into Fusion Middleware Control and select the WebLogic domain for WebCenter Spaces.

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

2. In the Navigation pane, open the WebCenter node, and then the WebCenter Spaces node, and click WebCenter Spaces (WLS_Spaces).

3. Register the discussion server as described in Section 12.3.1, "Registering Discussions Servers Using Fusion Middleware Control."

   For Server URL, enter http://<host>:<port>/owc_discussions .

4. Restart the WLS_Spaces managed server.

   When you log into WebCenter Spaces, you automatically sign on to the discussion server as well.

23.7.1.7.4 Configuring the Wiki Server

Wiki page functionality is supported as an iFrame, which you can embed in a Web page, and OAM single sign-on is supported this way. Since the Oracle WebCenter Wiki and Blog Server does not require or support an identity store, there is no need to configure the LDAP.

To add a wiki page to a WebCenter identity store, follow the steps below:

1. Log in to WebCenter Spaces, and open a group space.

2. Add a page, choosing Web Page as the Style.

3. When the page is created, click the Edit icon.

   The Component properties dialog displays.

4. Enter the following URL in the Source box:

   http://host:OHS port/owc_wiki/page/show.jz?inline=1&scope=#{communityContext.communityName}
   

   Where host is the host ID of the WLS_Spaces server, and OHS_port is the port number of the Oracle HTTP Server. The OHS port is used so the call goes through the WebGate which will initiate SSO.

   After specifying the component properties you will see the wiki page contents.

5. Save the changes.

23.7.1.7.5 Restricting Access with Connection Filters

Follow the steps below to only allow users to access WebCenter and other services through the WebTier OHS ports so that they can be properly authenticated.

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane, select the domain you want to configure (for example, webcenter).

3. Open the Security tab and the Filter subtab.

   The Security Filter Settings pane displays (see Figure 23-86).

   Figure 23-86 Security Filter Settings Page

   
   Description of "Figure 23-86 Security Filter Settings Page"
   
   

4. Check Connection Logger Enabled to enable the logging of accepted messages.

   The Connection Logger logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.

5. In the Connection Filter field, specify the connection filter class to be used in the domain.

   • To configure the default connection filter, specify weblogic.security.net.ConnectionFilterImpl.

   • To configure a custom connection filter, specify the class that implements the network connection filter. Note that this class must also be present in the CLASSPATH for WebLogic Server.

6. In the Connection Filter Rules field, enter the syntax for the connection filter rules.

   For example:

   <webtier IP>/0 * * allow
   0.0.0.0/0  *  *  deny
   

   which says: allow all traffic coming from the local host and disallow all traffic from any other IP address. You should, of course, write the network filter(s) that are relevant to your environment. For more information about writing connection filters, see "Developing Custom Connection Filters" in Oracle Fusion Middleware Programming Security for Oracle WebLogic Server.

7. Click Save and activate the changes.

8. Restart all the managed servers and the Administration Server.

9. Verify that all direct traffic to the WebLogic Server is blocked by attempting to navigate to:

   http://host:WLS_port/webcenter
   

   This should produce the following error:

   "The Server is not able to service this request: [Socket:000445]Connection rejected, filter blocked Socket, weblogic.security.net.FilterException: [Security:090220]rule 3"

   You should, however, still be able to access WebCenter through the OHS port:

   http://host:OHS_port/webcenter
   

23.7.2 Configuring Oracle Single Sign-On (OSSO)

In a default installation, WebCenter uses the HTTP ports in the Managed Server created for WebCenter. To configure WebCenter with Oracle Single Sign-On, WebCenter needs Oracle HTTP Server and the associated Module mod_osso to integrate with Oracle Single Sign-On (OSSO).

Note:

The BPEL Console does not support SSO integration. When WebCenter is configured for SSO, login to BPEL must still be done through the standard login page on the BPEL Console.

This section includes the following subsections

• Section 23.7.2.1, "OSSO Components and Topology"

• Section 23.7.2.2, "Configuring the Oracle HTTP Server and Associated mods"

• Section 23.7.2.3, "Configuring the OSSOIdentityAsserter"

• Section 23.7.2.4, "Registering OHS with Oracle SSO"

• Section 23.7.2.5, "Configuring the Discussions Server for SSO"

23.7.2.1 OSSO Components and Topology

In a default installation, WebCenter uses the HTTP ports of the Managed Server created for WebCenter. To configure WebCenter with Oracle Single Sign-On, WebCenter needs the Oracle HTTP Server and the associated Module mod_osso, to integrate with Oracle SSO. The diagram below (Figure 23-87) shows the overall architecture of this integration:

Figure 23-87 OSSO Components and Topology

Description of "Figure 23-87 OSSO Components and Topology"

23.7.2.2 Configuring the Oracle HTTP Server and Associated mods

This section describes how to load and configure the Oracle HTTP Server and associated mods.

To load and configure the Oracle HTTP Server and associated mods:

1. Install the WebTier, which contains Oracle HTTP Server (OHS) and associated mods (mod_osso and mod_wl).

2. Configure the module mod_wl in WebTier OHS so that it forwards requests to the Oracle WebLogic Server for WebCenter.

   Uncomment the lines at WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/mod_wl_ohs.conf. This file is included by the httpd.conf file and looks like the following:

   LoadModule weblogic_module   WT_ORACLE_HOME/ohs/modules/mod_wl_ohs.so
   <IfModule mod_weblogic.c>
   MatchExpression /webcenter WebLogicHost=webcenter.example.com|WebLogicPort=8888
   MatchExpression /rss WebLogicHost=webcenter.example.com|WebLogicPort=8890
   MatchExpression /owc_wiki WebLogicHost=webcenter.example.com|WebLogicPort=8890
   MatchExpression /owc_discussions WebLogicHost=webcenter.example.com|WebLogicPort=8890
   MatchExpression /workflow WebLogicHost=soa.example.com|WebLogicPort=8888
   MatchExpression /integration WebLogicHost=soa.example.com|WebLogicPort=8888
   MatchExpression /rest WebLogicHost=webcenter.example.com|WebLogicPort=8890
   </IfModule>
   

23.7.2.3 Configuring the OSSOIdentityAsserter

Include the OSSO Identity Assertion Provider (IAP) provider in the Oracle WebLogic domain for WebCenter. Use the WebLogic Server Administration Console to add the OSSO IAP to your domain as shown in the steps below.

To configure the OSSOIdentityAsserter:

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-88).

   Figure 23-88 Summary of Security Realms Pane

   
   Description of "Figure 23-88 Summary of Security Realms Pane"
   
   

3. Click the realm entry to which to add the provider.

   The Settings pane for the realm displays (see Figure 23-89).

   Figure 23-89 Settings Pane

   
   Description of "Figure 23-89 Settings Pane"
   
   

4. Click the Providers tab.

   The Provider Settings display (see Figure 23-90).

   Figure 23-90 Settings Pane - Providers

   
   Description of "Figure 23-90 Settings Pane - Providers"
   
   

5. Click New to create a new provider.

   The Create a New Authentication Provider pane displays (see Figure 23-91).

   Figure 23-91 Create a New Authentication Provider Pane

   
   Description of "Figure 23-91 Create a New Authentication Provider Pane"
   
   

6. Enter a name for the new provider, select OSSOIdentityAsserter as its type and click OK.

7. On the Providers tab, click the newly added provider.

8. Set the control flag to OPTIONAL.

9. Make sure that OracleInternetDirectoryAuthenticator (or the primary authenticator you selected when you configured the Identity Store to use an external LDAP) is set as the primary authenticator for the domain so that the user profile can be retrieved from the associated Oracle Internet Directory server. For information about configuring the Identity Store to use an external LDAP, see Section 23.3.1, "Reassociating the Identity Store with an External LDAP."

   For OID, the provider list should appear as follows:

   • OracleInternetDirectoryAuthenticator (SUFFICIENT)

   • OSSOIdentityAsserter (OPTIONAL)

   • DefaultAuthenticator (SUFFICIENT)

   • DefaultIdentityAsserter (OPTIONAL)

   Also make sure that the default jpsContext in WebCenter's jps-config.xml file is set to the idstore.ldap serviceInstance.

23.7.2.4 Registering OHS with Oracle SSO

Register the module mod_osso in the WebTier OHS with the SSO Server as a partner application by following the steps below.

To register OHS with Oracle SSO:

1. Run ssoreg from the SSO server to generate an osso.conf file and manually copy it to the partner application (WT_ORACLE_HOME).

   The following example shows how you would register a remote partner application on a SSO Server. Note that ORACLE_HOME here is the ORACLE_HOME of the OSSO installation on the SSO server.

   bash-3.00$ ORACLE_HOME/sso/bin/ssoreg.sh -site_name
   webtier.example.com:80 -config_mod_osso TRUE -mod_osso_url
   http://webtier.example.com -remote_midtier  -config_file
   webtier.example.com.osso.conf
   

   Running this command creates a webtier.example.com.osso.conf file.

2. Copy the WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/disabled/mod_osso.conf file to WT_ORACLE_HOME/instances/<your_instance>/config/OHS/ohs1/moduleconf. All files in the moduleconf directory are included in the httpd.conf file.

3. Add a static rule to the mod_osso.conf file to protect the /webcenter URL with Oracle SSO.

   The mod_osso.conf file should look similar to this:

   LoadModule osso_module WT_ORACLE_HOME/ohs/modules/mod_osso.so
    <IfModule mod_osso.c>
       OssoIpCheck off
       OssoIdleTimeout off
       OssoSecureCookies Off
    
       # whatever the location of your real osso.conf file is, that was generated from the ssoreg.sh command.
       OssoConfigFile /OracleWebTier/webtier.example.com.osso.conf
    
   #______-
   # Notes
   #______-
   # 1. Here's what you need to add to protect a resource,
   #    e.g. <ApacheServerRoot>/htdocs/private:
   # 2. if an application is protected by SSO then no matter what Apache will always
   #    send no-cache headers practically undoing whatever the Apache configuration or
   #    the ADF faces Cache library do. To allow caching for SSO protected resources
   #    add "OssoSendCacheHeaders off " as following.
    
       <Location /webcenter/adfAuthentication*>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /owc_wiki/user/login.jz>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /rss/rssservlet>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /owc_discussions/login!withRedirect.jspa>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /owc_discussions/login!default.jspa>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /owc_discussions/login.jspa>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /owc_discussions/admin>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /owc_wiki/adfAuthentication>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /integration/worklistapp>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /workflow/WebCenterWorklistDetail>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /workflow/sdpmessagingsca-ui-worklist>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
       <Location /rest>
         OssoSendCacheHeaders off
         require valid-user
         AuthType Osso
       </Location>
   </IfModule>
   #
   # If you would like to have short hostnames redirected to
   # fully qualified hostnames to allow clients that need
   # authentication via mod_osso to be able to enter short
   # hostnames into their browsers uncomment out the following
   # lines
   #
   #PerlModule Apache::ShortHostnameRedirect
   #PerlHeaderParserHandler Apache::ShortHostnameRedirect
   

   Be sure to change the OssoConfigFile parameter to point to the location (and filename if you've changed it) of your osso.conf file.

4. Restart the WebTier so that the configuration changes to mod_osso and mod_wl to take effect.

5. For the Worklist service changes to take effect, run the following command on the WebCenter Administration server:

   setBPELConnection('webcenter','WebCenter-Worklist', 'http://webcenter-stage.example.com')
   

6. To only allow users to access WebCenter and other services through the WebTier OHS ports so that they can be properly authenticated, follow the steps in Section 23.7.1.7.5, "Restricting Access with Connection Filters."

7. Complete the configuration for Oracle Single Sign-on (OSSO) by adding a setting to EXTRA_JAVA_PROPERTIES as described in Section 23.7.1.6.4, "Configuring the Application for Oracle Access Manager SSO."

23.7.2.5 Configuring the Discussions Server for SSO

This section describes how to configure Oracle WebCenter Discussions Server for single sign-on. Before configuring the discussions server for SSO, be sure that it has been configured to use the same identity store LDAP as WebCenter Spaces, as described in Section 23.3.4.1, "Migrating the WebCenter Discussions Server to use an External LDAP."

To set up the discussions server for SSO:

1. Log in to the Oracle WebCenter Discussions Server Admin Console at:

   http://host:port/owc_discussions/admin
   

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

2. Open the System Properties page and edit (if it already exists) or add the owc_discussions.sso.mode property, setting it's value to true.

3. Edit or add the jiveURL property to point to the base URL of the SSO server. For example:

   jiveURL = example.com:8890/owc_discussions
   

23.7.3 Configuring SAML-based Single Sign-on

Security Assertion Markup Language (SAML) enables cross-platform authentication between Web applications or Web Services running in a WebLogic Server domain and Web browsers or other HTTP clients. WebLogic Server supports single sign-on (SSO) based on SAML. When users are authenticated at one site that participates in a single sign-on (SSO) configuration, they are automatically authenticated at other sites in the SSO configuration and do not need to log in separately.

Note:

Although SAML-based single sign-on provides support for logging users onto subsequent applications after initial sign-on, global logout is not supported. Consequently, users must log out of each individual application they open.

Note also that since REST applications don't have a single access point and SAML 1.1 standard does not support wildcards in the Source Redirect URIs (in the asserting party configuration), SAML single sign-on for REST is not supported.

Note also that if you set up SAML-based single sign-on with WebCenter Spaces as the source application and Oracle WebCenter Discussions as the destination application, you can access administration pages of the Discussions application from the WebCenter Spaces Manage Group Space Services screen or Configure WebCenter Services screen. However, since the Oracle WebCenter Discussion administration pages do not participate in SSO, if you access administration pages directly, you are required to log in to Oracle WebCenter Discussions again.

This SSO mechanism can be used for departmental WebCenter installations for which there is no existing Oracle SSO or Oracle Access Manager single sign-on infrastructure, but single sign-on between only WebCenter Spaces and its services is required. For High Availability and large enterprise deployments, the Oracle Access Manager SSO configuration is recommended.

This section describes how to set up SAML 1.1-based single sign-on for Oracle WebCenter Spaces and the Wiki and Worklist services running on different managed servers within the same domain.

This section includes the following subsections:

• Section 23.7.3.1, "SAML Components and Topology"

• Section 23.7.3.2, "Configuring SAML-based Single Sign-on"

23.7.3.1 SAML Components and Topology

Figure 23-93 shows the components and their interaction in a SAML-based single sign-on configuration that includes WebCenter Spaces and the Wiki service.

A SAML-based single sign-on solution consists of the following components:

• SAML Credential Mapper - The SAML Credential Mapping provider acts as a producer of SAML security assertions, allowing WebLogic Server to act as a source site for using SAML for single sign-on. The SAML Credential Mapping provider generates valid SAML 1.1 assertions for authenticated subjects based on the configuration of the target site or resource.

• Inter Site Transfer Service (ITS) - an addressable component that generates identity assertions and transfers the user to the destination site.

• Assertion Retrieval Service (ARS) - an addressable component that returns the SAML assertion that corresponds to the artifact. The assertion ID must have been allocated at the time assertion was generated.

• SAML Identity Asserter - The SAML Identity Assertion provider acts as a consumer of SAML security assertions, allowing WebLogic Server to act as a destination site for using SAML for single sign-on. The SAML Identity Assertion provider processes valid SAML 1.1 assertions for authenticated subjects obtained from the source site or resource.

• Assertion Consumer Service (ACS) - an addressable component that receives assertions and/or artifacts generated by the ITS and uses them to authenticate users at the destination site

• SAML Relying party - A SAML Relying Party is an entity that relies on the information in a SAML assertion produced by the SAML source site. You can configure how WebLogic Server produces SAML assertions separately for each Relying Party or use the defaults established by the Federation Services source site configuration for producing assertion.

• SAML Asserting party - A SAML Asserting Party is a trusted SAML Authority (an entity that can authoritatively assert security information in the form of SAML Assertions).

Figure 23-92 shows the components and flow for a POST-configured SAML SSO configuration that includes both a WebCenter and SOA domain. The flow is similar for other destination applications participating in single sign-on such as RSS, Worklist applications, and Discussions.

Figure 23-92 Detailed SAML Single Sign-on Components and Topology (POST Profile Configured)

Description of "Figure 23-92 Detailed SAML Single Sign-on Components and Topology (POST Profile Configured)"

Figure 23-93 shows a simplified version of the components and flow for a POST-configured SAML SSO configuration, including the SAML SSO flow between WebCenter Spaces and the OWC Wiki application.

Figure 23-93 SAML Single Sign-on Components and Topology (POST Profile Configured)

Description of "Figure 23-93 SAML Single Sign-on Components and Topology (POST Profile Configured)"

The steps in the flow are:

1. The user's browser accesses WebCenter Spaces (source site), hosted on a WebLogic managed server (WLS_Spaces) in the WebCenter domain (wc_domain), by supplying user credentials.

2. WebCenter Spaces passes the user credentials to the authentication service provider.

3. If authentication is successful, the authenticated session is established, and the WebCenter Spaces welcome page is displayed.

4. From the welcome page, the user then clicks on a link on the page to access a secured Web page of the Wiki service (destination site), hosted on a different WebLogic Server (WLS_Services) in the same domain. This triggers a call to the Inter-Site Transfer Service (ITS) servlet configured. In this case, the ITS servlet is hosted within the source site (that is, on the WebCenter Spaces application on the WLS_Spaces managed server) that will share the same JSESSIONID cookie as WebCenter Spaces.

5. The ITS servlet calls the SAML Credential Mapper configured in the WebCenter domain (wc_domain) to request a caller assertion. The SAML Credential Mapper returns the assertion. It also returns the URL of the destination site application Web page (a secured Web page of the Wiki service) and path to the appropriate POST form (if the source site is configured to use the POST profile).

6. The SAML ITS servlet generates a SAML response containing the generated assertion, signs it, base-64 encodes it, embeds it in the HTML form, and returns the form to the user's browser.

7. The user's browser POSTs the form to the destination site's Assertion Consumer Service (ACS). In this case, the ACS Servlet is hosted in destination site (the Wiki service) and shares its login cookie.

8. The assertion is validated.

9. If the assertion is successful, the user is redirected to the target (the secured Web page of the Wiki service).

10. The user is logged in on the destination site Wiki service without having to reauthenticate.

23.7.3.2 Configuring SAML-based Single Sign-on

This section describes how to configure WebCenter Spaces and services for SAML-based single sign-on.

Configuring SAML-based SSO consists of the following steps:

• Section 23.7.3.2.1, "Preparing WebCenter Spaces and Services for SAML SSO"

• Section 23.7.3.2.2, "Generating and Registering Certificates"

• Section 23.7.3.2.3, "Creating the SAML Credential Mapping Provider Instance"

• Section 23.7.3.2.4, "Configuring a Relying Party"

• Section 23.7.3.2.5, "Configuring Source Site Federation Services"

• Section 23.7.3.2.6, "Configuring the SAML Identity Assertion Provider"

• Section 23.7.3.2.7, "Configuring Destination Site Federation Services"

• Section 23.7.3.2.8, "Checking Your Configuration"

23.7.3.2.1 Preparing WebCenter Spaces and Services for SAML SSO

After installing WebCenter Spaces and the Wiki and Worklist services, you must test the single sign-on configuration.

To check the default WebCenter Spaces and Wiki service login:

1. Install WebCenter Spaces, and select the Wiki service and Discussions service, and any other service applications to be configured for SSO (RSS is automatically deployed when you install WebCenter Spaces). For information on installing WebCenter Spaces, see "Installing WebCenter Spaces, Portlet Producers, Discussions, and Wiki and Blogs" in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter.

   When the installation is complete, WebCenter Spaces is hosted on the WLS_Spaces Managed Server, and Wiki and Discussions services are hosted on the WLS_Services Managed Server. Record the host and port that the Wiki service is running on so, later on, you can construct the URL and test single sign-on.

2. Log into WebCenter Spaces and create a personal page with a link to the Wiki service as shown below:

   1. Log in to WebCenter Spaces as a user with create page permissions.

   2. Create a new page by clicking on the Create a page tab in a group space.

   3. Title the page appropriately (for example, "Wiki") and choose the Web page template.

   4. Click the Inspector button and click on the Web page.

   5. Change the source to be the URL specified below:

      http://host:port/owc_wiki/page/show.jz?inline=1&scope=#{communityContext.communityName}
      

      Where host is the Wiki server host ID and port is the Wiki server port number.

   6. Save the page.

   When you click the link, note that you are challenged to log in by the Wiki service. Once you have completed the remainder of the steps, this is not required. You will be automatically logged into Wiki service.

3. For the Worklist service, install SOA (which includes the BPEL server). For information on installing SOA, see Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.

4. Configure the BPEL connection for WebCenter Spaces as described in Section 20.3, "Setting Up Worklist Connections."

5. To test the BPEL connection:

   1. Log into WebCenter Spaces, create a group space, and add your administrator account as a moderator.

   2. Log into WebCenter Spaces with your administrator account.

      You should see a new item in the Worklist task flow indicating that you have been added as a moderator for the group space.

   3. Click the link.

      Note that you are challenged to log in. After you have completed the rest of the steps you automatically log into the Worklist service on the SOA domain.

6. Deploy the SAML SSO version of the Oracle WebCenter Discussions Server:

   By default, the .EAR file that is deployed for the Oracle WebCenter Discussions Server supports form-based Oracle SSO or Oracle Access Manager SSO. Therefore, to configure the Oracle WebCenter Discussions Server for SAML-based single sign-on, you need to deploy the SAML SSO version of the discussion server .EAR file.

   Note:

   Before configuring the discussions server for SSO, be sure that it has been configured to use the same identity store LDAP as WebCenter Spaces, as described in Section 23.3.4.1, "Migrating the WebCenter Discussions Server to use an External LDAP."

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

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

   2. In the Domain Structure pane, click Deployments.

      The Deployments Summary pane displays (see Figure 23-94).

      Figure 23-94 Deployment Summary Pane

      
      Description of "Figure 23-94 Deployment Summary Pane"
      
      

   3. On the Deployment Summary page, select owc_discussions stop and delete and click Install.

   4. Using the Install Application Assistant Path field, locate the SSO enabled owc_discussions .EAR file (owc_discussions_samlsso.ear, typically in $WC_ORACLE_HOME/discussionserver).

   5. Select the owc_discussions_samlsso.ear file and click Next.

   6. Select Install this deployment as an application and click Next.

   7. Set the Name to owc_discussions.

   8. Deploy the .EAR file.

   9. Log into the Discussions Server Administration Console as an administrator (see Section 23.7.1.7.2, "Configuring the Discussions Server for SSO" for more information on logging into the Discussions Server Administration Console).

   10. Open the System Properties page and edit (if it already exists) or add the owc_discussions.sso.mode property, setting it's value to true.

   11. Restart the WLS_Services Managed Server (where the discussions server is deployed).

23.7.3.2.2 Generating and Registering Certificates

To secure communication between the SAML source and destination sites, communication should be encrypted. Additionally, certificates should be used to verify the identity of the other party during SAML interaction. Follow the steps below to generate a key using the keytool utility (available as part of the JDK 6.0), and register it using the WebLogic Server Administration Console.

To create certificates using keytool:

1. Navigate to the JAVA_HOME/bin directory.

2. Using keytool, generate the key with the following command:

   keytool -genkey -keypass key_password -keystore keystore_name -storepass keystore_password -keyalg rsa -alias alias
   

   Where:

   • key_password is the password to apply to the generated key

   • keystore_name is the name of the custom keystore

   • keystore_password is the password for the custom keystore

   • alias is the alias name (for example, testalias)

3. Run the keytool command with -export option to generate a key file calling it, for example, testalias.der.

   keytool -export -keystore keystore_name -storepass keystore_password -alias alias -file testalias.der
   

   where:

   • keystore_name is the name of the custom keystore

   • keystore_password is the password for the custom keystore

   • alias is the alias name (for example, testalias)

   • Determine the trust store to use:

     Since you are using a self-signed certificate, you must update it as a trusted certificate in the server trust store. To do this, you must determine your trust store by going to the server:

     1. Log into the WebLogic Server Administration Console.

     2. In the Domain Structure pane, expand Environments and click Servers.

     3. In the list of servers, click WLS_Spaces.

     4. Open the Configuration tab, and the Keystores subtab.

        The Keystores Settings pane displays (see Figure 23-95).

        Figure 23-95 Keystores Settings Pane

        
        Description of "Figure 23-95 Keystores Settings Pane"
        
        

     5. Note down the location of the server in the Java Standard Trust Keystore field (shown in Figure 23-39).

        Note that the cacerts file may be "read only", in which case you will need to change its permissions so that it's writable.

   • Import the self-signed certificate generated above in this trust store:

     keytool -importcert -trustcacerts -alias alias -file certificate_file-keystore cacerts -storepass changeit
     

     Where:

     • alias is the WebCenter Spaces alias (for example, webcenter_wls)

     • certificate_file is the file name for the certificate to export the key to (for example, webcenter_wls.cer)

To register the keystore using the WebLogic Server Administration Console

1. Log in to the WebLogic Server Administration Console.

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

2. In the Domain Structure pane, expand Environment and click Servers.

   The Summary of Servers pane displays (see Figure 23-96).

   Figure 23-96 Summary of Servers Pane

   
   Description of "Figure 23-96 Summary of Servers Pane"
   
   

3. Click the WebCenter Spaces server (WLS_Spaces) to configure the identity and trust keystore.

   The Settings pane for the WebCenter Spaces server displays (see Figure 23-97).

   Figure 23-97 Settings Pane for WebCenter Spaces Server

   
   Description of "Figure 23-97 Settings Pane for WebCenter Spaces Server"
   
   

4. Open the Configuration tab, and then the Keystores subtab.

   The Keystores pane displays (see Figure 23-98).

   Figure 23-98 Keystores Pane

   
   Description of "Figure 23-98 Keystores Pane"
   
   

5. For Keystores, select Custom Identity and Java Standard Trust.

6. In the Identity section, enter the path to the Custom Identity Keystore you created, choose JKS as the Type, and enter and confirm the Custom Identity Keystore Passphrase.

7. In the Trust section, enter the path to the trust keystore in Java Standard Trust Keystore, enter JKS as the Type, and enter and confirm the Java Standard Trust Keystore Passphrase.

8. Click Save.

23.7.3.2.3 Creating the SAML Credential Mapping Provider Instance

This section describes how to create a SAML Credential Mapping Provider V2 instance. Note that the SAML Credential Mapping provider is not part of the default security realm and must be created.

Creating the SAML Credential Mapping Provider instance is the first of two steps required to configure the credential mapping provider:

• Creating the SAML Credential Mapping Provider instance

• Configuring a Relying Party for each of the participating service applications (which can include OWC Wiki, OWC Discussions, RSS, Worklist Community Detail, Worklist SDP, and Worklist Integration)

To create a SAML Credential Mapping Provider instance:

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-99).

   Figure 23-99 Summary of Security Realms Pane

   
   Description of "Figure 23-99 Summary of Security Realms Pane"
   
   

3. Click your security realm.

   The Settings page for the security realm displays (see Figure 23-100).

   Figure 23-100 Security Realm Settings Page

   
   Description of "Figure 23-100 Security Realm Settings Page"
   
   

4. Open the Providers tab and select the Credential Mapping subtab.

   The Credential Mapping pane displays (see Figure 23-101).

   Figure 23-101 Credential Mapping Pane

   
   Description of "Figure 23-101 Credential Mapping Pane"
   
   

5. Click New.

   The Create a New Credential Mapping Provider pane displays (see Figure 23-102).

   Figure 23-102 Create a New Credential Provider Pane

   
   Description of "Figure 23-102 Create a New Credential Provider Pane"
   
   

6. Enter a Name for the provider, select the Type as SAMLCredentialMapperV2, and click OK.

7. On the Security Realm Settings page, click the provider you just created.

   The Settings page for the new provider displays (see Figure 23-103).

   Figure 23-103 Provider Settings Pane

   
   Description of "Figure 23-103 Provider Settings Pane"
   
   

8. Open the Provider Specific tab.

   The Provider Specific Settings Pane displays (see Figure 23-104).

   Figure 23-104 Provider Specific Settings Pane

   
   Description of "Figure 23-104 Provider Specific Settings Pane"
   
   

9. Configure the SAML Credential Mapping provider as a SAML authority, using the Issuer URI, Name Qualifier, and other attributes as shown below in Table 23-4. Leave the remaining parameters set to their default values.

   Table 23-4 SAML Credential Mapping Provider Security Realm Settings

   Parameter	Value	Description
   Issuer URI	http://www.example.com/webcenter	The Issuer URI (name) of this SAML Authority. This unique URI tells the destination site (Wiki service) the origin of the SAML message and allows it to match with the key. Typically, the URI is used to guarantee uniqueness.
   Name Qualifier	example.com	The Name Qualifier value used by the Name Mapper. The value of the Name Qualifier is the security or administrative domain that qualifies the name of the subject. This provides a means to federate names from disparate user stores while avoiding the possibility of subject name collision.
   Web Service Assertion Signing Key Alias		The alias used to retrieve from the keystore the key that is used to sign assertions (for example, testalias).
   Web Service Assertion Signing Key Passphrase		The credential (password) used to retrieve from the keystore the keys used to sign assertions (for example, testkeypass).
   Please type again To confirm		Re-enter the credential password.

   
   

10. Click Save to save your settings.

11. Restart the WebLogic Administration server.

23.7.3.2.4 Configuring a Relying Party

Configuring a relying party is the second of two steps required to configure the credential mapping provider:

• Creating the SAML Credential Mapping Provider instance

• Configuring a relying party for each of the participating service applications (which can include OWC Wiki, OWC Discussions, RSS, Worklist Community Detail, Worklist SDP, and Worklist Integration)

To configure a relying party:

1. From the Domain Structure pane, click Security Realms.

   The Summary of Security Realms pane displays (see Figure 23-105).

   Figure 23-105 Summary of Security Realms Pane

   
   Description of "Figure 23-105 Summary of Security Realms Pane"
   
   

2. Click your security realm and open the Providers tab and the Credential Mapping subtab.

   The Credential Mapping Providers Settings pane displays (see Figure 23-106).

   Figure 23-106 Credential Mapping Providers Settings Pane

   
   Description of "Figure 23-106 Credential Mapping Providers Settings Pane"
   
   

3. Click the SAML Credential Mapping Provider you created.

4. Open the Management tab and the Relying Parties tab on the Settings page for the provider.

   The Relying Parties Management Settings pane displays (see Figure 23-107).

   Figure 23-107 Relying Parties Management Settings Pane

   
   Description of "Figure 23-107 Relying Parties Management Settings Pane"
   
   

5. Click New.

   The Create a New Relying Parties page displays (see Figure 23-108).

   Figure 23-108 Create a New Relying Party Page

   
   Description of "Figure 23-108 Create a New Relying Party Page"
   
   

6. Select Browser/POST as the SAML Profile, and provide a Description (for example, Wiki).

7. Click OK to save your settings.

8. On the Relying Parties Management Settings pane, click the Partner ID of the Relying Party you just created (the Partner ID is automatically generated for you).

   The Relying Party Settings page displays (see Figure 23-109).

   Figure 23-109 Relying Party Settings Page

   
   Description of "Figure 23-109 Relying Party Settings Page"
   
   

9. On the Relying Parties page, use the settings shown in Table 23-2 to configure a relying party for the Wiki service. Leave the remaining parameters set to their default values. Click Save when finished.

   Table 23-5 Relying Party Settings for Wiki Service

   Parameter	Value	Description
   Enabled	Checked	The state of this SAML Relying Party.
   Description	OWC Wiki	A short description of this Relying Party
   Target URL		The destination site URL for which authentication is requested (for example: http://example.com:8890/owc_wiki/user/login.jz).
   Assertion Consumer URL		The URL at which an Assertion Consumer Service for this SAML Relying Party can be reached (for example, http://exmple.com:8890/owc_wiki/samlacs/acs). Indicates the URL to which an assertion or artifact should be POSTed or redirected. Note: If you have checked ACS requires SSL while configuring destination site federation services, then use HTTPS protocol and the SSL port for the WLS_Services managed server.
   Assertion Consumer Properties	APID=ap_00001	One or more optional query parameters, in the form name=value, that will be added to the ACS URL when redirecting to the destination site. In the case of POST profile, these parameters will be included as form variables when using the default POST form. In this case, ap_00001 indicates the ID of the asserting party for the Wiki application configured in the SAML Identity Asserter of the WebCenter domain which provides the source site (WebCenter Spaces) and ITS details.
   Sign Assertions	Checked	Specifies whether generated assertions for this SAML Relying Party are signed.
   Include KeyInfo	Checked	Indicates whether a <ds:keyinfo> element containing the signing certificate should be included when signing assertions. The default value is true. This value is ignored if Sign Assertions is false.

   
   

10. Repeat steps 1 - 8 to configure a relying party for the Worklist Community Detail service using the settings shown in Table 23-2. Leave the remaining parameters on the Relying Parties page set to their default values. Click Save when finished.

    Table 23-6 Relying Party Settings for Worklist Community Detail

    Parameter	Value	Description
    Enabled	Checked	The state of this SAML Relying Party.
    Description	Worklist Detail	A short description of this Relying Party
    Target URL		The destination site URL for which authentication is requested (for example: http://example.com:8001/workflow/WebCenterWorklistDetail/faces/adf.task-flow).
    Assertion Consumer URL		The URL at which an Assertion Consumer Service for this SAML Relying Party can be reached (for example, http://example.com:8001/workflow/WebCenterWorklistDetail/samlacs/acs). Indicates the URL to which an assertion or artifact should be POSTed or redirected. Note: If you have checked ACS requires SSL while configuring destination site federation services, then use https protocol and the SSL port for the SOA managed server.
    Assertion Consumer Properties	APID=ap_00001	One or more optional query parameters, in the form name=value, that will be added to the ACS URL when redirecting to the destination site. In the case of POST profile, these parameters will be included as form variables when using the default POST form. In this case ap_00001 indicates the ID of the asserting party configured for Worklist Detail in the SAML Identity Asserter of the SOA domain, which provides the source site (WebCenter Spaces) and ITS details.
    Sign Assertions	Checked	Specifies whether generated assertions for this SAML Relying Party are signed.
    Include KeyInfo	Checked	Indicates whether a <ds:keyinfo> element containing the signing certificate should be included when signing assertions. The default value is true. This value is ignored if Sign Assertions is false.

    
    

11. Repeat steps 1 - 8 to configure a relying party for the Worklist SDP service using the settings shown in Table 23-2. Leave the remaining parameters on the Relying Parties pages set to their default values. Click Save when finished.

    Table 23-7 Relying Party Settings for Worklist SDP

    Parameter	Value	Description
    Enabled	Checked	The state of this SAML Relying Party.
    Description	WebCenter SDP	A short description of this Relying Party
    Target URL		The destination site URL for which authentication is requested (for example: http://example.com:8001/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow).
    Assertion Consumer URL		The URL at which an Assertion Consumer Service for this SAML Relying Party can be reached (for example, http://exmple.com:8001/workflow/sdpmessagingsca-ui-worklist/samlacs/acs). Indicates the URL to which an assertion or artifact should be POSTed or redirected. Note: If you have checked ACS requires SSL while configuring destination site federation services, then use https protocol and the SSL port for the SOA managed server.
    Assertion Consumer Properties	APID=ap_00002	One or more optional query parameters, in the form name=value, that will be added to the ACS URL when redirecting to the destination site. In the case of POST profile, these parameters will be included as form variables when using the default POST form. In this case ap_00002 indicates the ID of the asserting party configured for the Worklist SDP application in the SAML Identity Asserter of the SOA domain, which provides the source site (WebCenter Spaces) and ITS details.
    Sign Assertions	Checked	Specifies whether generated assertions for this SAML Relying Party are signed.
    Include KeyInfo	Checked	Indicates whether a <ds:keyinfo> element containing the signing certificate should be included when signing assertions. The default value is true. This value is ignored if Sign Assertions is false.

    
    

12. Repeat steps 1 - 8 to configure a relying party for the Worklist Integration service using the settings shown in Table 23-2. Leave the remaining parameters on the Relying Parties pages set to their default values. Click Save when finished.

    Table 23-8 Relying Party Settings for Worklist Integration

    Parameter	Value	Description
    Enabled	Checked	The state of this SAML Relying Party.
    Description	WebCenter SDP	A short description of this Worklist Integration
    Target URL		The destination site URL for which authentication is requested (for example: http://example.com:8001/integration/worklistapp).
    Assertion Consumer URL		The URL at which an Assertion Consumer Service for this SAML Relying Party can be reached (for example, http://exmple.com:8001/workflow/sdpmessagingsca-ui-worklist/samlacs/acs). Indicates the URL to which an assertion or artifact should be POSTed or redirected. Note: If you have checked ACS requires SSL while configuring destination site federation services, then use https protocol and the SSL port for the SOA managed server.
    Assertion Consumer Properties	APID=ap_00003	One or more optional query parameters, in the form name=value, that will be added to the ACS URL when redirecting to the destination site. In the case of POST profile, these parameters will be included as form variables when using the default POST form. In this case ap_00003 indicates the ID of the asserting party configured the for Worklist Integration application in the SAML Identity Asserter of the SOA domain, which provides the source site (WebCenter Spaces) and ITS details.
    Sign Assertions	Checked	Specifies whether generated assertions for this SAML Relying Party are signed.
    Include KeyInfo	Checked	Indicates whether a <ds:keyinfo> element containing the signing certificate should be included when signing assertions. The default value is true. This value is ignored if Sign Assertions is false.

    
    

13. Repeat steps 1 - 8 to configure a relying party for the RSS application using the settings shown in Table 23-2. Leave the remaining parameters on the Relying Parties pages set to their default values. Click Save when finished.

    Table 23-9 Relying Party Settings for RSS

    Parameter	Value	Description
    Enabled	Checked	The state of this SAML Relying Party.
    Description	RSS	A short description of this Relying Party
    Target URL		The destination site URL for which authentication is requested (for example: http://example.com:8888/rss/rssservlet).
    Assertion Consumer URL		The URL at which an Assertion Consumer Service for this SAML Relying Party can be reached (for example, http://exmple.com:8888/rss/samlacs/acs). Indicates the URL to which an assertion or artifact should be POSTed or redirected. Note: If you have checked ACS requires SSL while configuring destination site federation services, then use https protocol and the SSL port for the WLS_Spaces managed server.
    Assertion Consumer Properties	APID=ap_00002	One or more optional query parameters, in the form name=value, that will be added to the ACS URL when redirecting to the destination site. In the case of POST profile, these parameters will be included as form variables when using the default POST form. In this case ap_00002 indicates the ID of the asserting party configured for RSS in the SAML Identity Asserter of the WebCenter domain, which provides the source site (WebCenter Spaces) and ITS details.
    Sign Assertions	Checked	Specifies whether generated assertions for this SAML Relying Party are signed.
    Include KeyInfo	Checked	Indicates whether a <ds:keyinfo> element containing the signing certificate should be included when signing assertions. The default value is true. This value is ignored if Sign Assertions is false.

    
    

14. Repeat steps 1 - 8 to configure a relying party for the Discussions application using the settings shown in Table 23-2. Leave the remaining parameters on the Relying Parties pages set to their default values. Click Save when finished.

    Table 23-10 Relying Party Settings for Discussions

    Parameter	Value	Description
    Enabled	Checked	The state of this SAML Relying Party.
    Description	Discussions	A short description of this Relying Party
    Target URL		The destination site URL for which authentication is requested (for example: http://example.com:8890/owc_discussions/admin/content-main.jsp).
    Assertion Consumer URL		The URL at which an Assertion Consumer Service for this SAML Relying Party can be reached (for example, http://exmple.com:8890/owc_discussions/samlacs/acs). Indicates the URL to which an assertion or artifact should be POSTed or redirected. Note: If you have checked ACS requires SSL while configuring destination site federation services, then use https protocol and the SSL port for the managed server.
    Assertion Consumer Properties	APID=ap_00003	One or more optional query parameters, in the form name=value, that will be added to the ACS URL when redirecting to the destination site. In the case of POST profile, these parameters will be included as form variables when using the default POST form. In this case ap_00003 indicates the ID of the asserting party configured for the Discussions application in the SAML Identity Asserter of the WebCenter domain, which provides the source site (WebCenter Spaces) and ITS details.
    Sign Assertions	Checked	Specifies whether generated assertions for this SAML Relying Party are signed.
    Include KeyInfo	Checked	Indicates whether a <ds:keyinfo> element containing the signing certificate should be included when signing assertions. The default value is true. This value is ignored if Sign Assertions is false.

    
    

23.7.3.2.5 Configuring Source Site Federation Services

This section describes how to create and configure source site Federation services.

To configure Source Site Federation Services:

1. Log in to the WebLogic Server Administration Console.

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

2. On the Domain Structure pane, expand the Environment node and click Servers.

   The Summary of Servers page displays (see Figure 23-110).

   Figure 23-110 Summary of Servers Page

   
   Description of "Figure 23-110 Summary of Servers Page"
   
   

3. Click WLS_Spaces and open the Configuration tab.

4. Open the Federation Services subtab and the SAML 1.1 Source Site subtab.

   The Federation Services Configuration SAML 1.1 Source Site Settings page for the WLS_Spaces server displays (see Figure 23-111).

   Figure 23-111 Federation Services Configuration SAML 1.1 Source Site Settings Page

   
   Description of "Figure 23-111 Federation Services Configuration SAML 1.1 Source Site Settings Page"
   
   

5. Configure the SAML source site attributes as shown in Figure 23-111. Leave the remaining parameters set to their default values.

   Table 23-11 Source Site Federation Services Parameters

   Parameter	Value	Description
   Source Site Enabled	Checked	Allow the WebLogic server instance to serve as a SAML source site by setting Source Site Enabled to true.
   Source Site URL		Set the URL for the SAML source site (for example, http://example.com:8888/webcenter). This is the URL that hosts the Intersite Transfer Service and Assertion Retrieval Service. The source site URL is encoded as a source ID in hex and Base64.
   Signing Key Alias		The SAML source site requires a trusted certificate with which to sign assertions. Add this certificate to the keystore and enter the alias (for example, testalias) to be used to access the certificate. The server's SSL identity key/certificates will be used by default if a signing alias and passphrase are not supplied.
   Signing Key Passphrase		The SAML source site requires a trusted certificate with which to sign assertions. Add this certificate to the keystore and enter the passphrase (for example, testkeypass) to be used to access the certificate. The server's SSL identity key/certificates will be used by default if a signing alias and passphrase are not supplied.
   Intersite Transfer URIs	/webcenter/samlits/its [add on top, leave the rest]	Specify the URIs for the Intersite Transfer Service. These URIs are also specified in the configuration of an Asserting Party.
   Assertion Retrieval URIs	/webcenter/samlars/ars [add on top, leave the rest]	N/A - URI for Assertion Retrieval Service used when artifact profile is used.
   ITS Requires SSL	Unchecked	Note: If you check this, then you need to change the Source Site ITS URL specified in the SAML Asserting Party configuration in the SAML Identity provider as HTTPS and the server's SSL port.
   ARS Requires SSL	Unchecked	Applicable only when Artifact profile is used

   
   

6. Click Save to save your settings when done.

7. Restart the WLS_Spaces managed server.

23.7.3.2.6 Configuring the SAML Identity Assertion Provider

This section describes how to create and configure a SAML Identity Assertion Provider V2 instance (the SAML Identity Assertion provider is not part of the default security realm). This section also describes how to establish trust by registering the source site's SSL certificate in the certificate registry maintained by the SAML Identity Assertion provider.

To create a SAML Identity Assertion Provider

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-112).

   Figure 23-112 Summary of Security Realms Pane

   
   Description of "Figure 23-112 Summary of Security Realms Pane"
   
   

3. Click your security realm.

   The Settings page for the security realm displays (see Figure 23-113).

   Figure 23-113 Security Realm Settings Page

   
   Description of "Figure 23-113 Security Realm Settings Page"
   
   

4. Open the Providers tab and select the Authentication subtab.

   The Authentication Settings pane displays (see Figure 23-114).

   Figure 23-114 Authentication Settings Pane

   
   Description of "Figure 23-114 Authentication Settings Pane"
   
   

5. Click New.

   The Create a New Authentication Provider page displays (see Figure 23-115).

   Figure 23-115 Create a New Authentication Provider Page

   
   Description of "Figure 23-115 Create a New Authentication Provider Page"
   
   

6. Enter a Name for the new SAML Identity Asserter, and select the Type as SAMLIdentityAsserterV2.

7. Click OK to save your settings.

8. Restart the WebLogic Administration server if indicated in the Messages area.

9. Go to the SOA domain and create a SAML Identity Asserter provider there as well using the steps above.

To configure a certificate for the SAML ID Asserter

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-116).

   Figure 23-116 Summary of Security Realms Pane

   
   Description of "Figure 23-116 Summary of Security Realms Pane"
   
   

3. Click your security realm.

   The Settings page for the security realm displays (see Figure 23-117).

   Figure 23-117 Security Realm Settings Page

   
   Description of "Figure 23-117 Security Realm Settings Page"
   
   

4. Open the Providers tab and select the Authentication subtab.

   The Authentication Settings pane displays (see Figure 23-118).

   Figure 23-118 Authentication Settings Pane

   
   Description of "Figure 23-118 Authentication Settings Pane"
   
   

5. Click the SAML Identity Asserter you created and open the Management tab and the Certificates subtab.

   The Certificate Settings pane displays (see Figure 23-119).

   Figure 23-119 Certificate Settings Pane

   
   Description of "Figure 23-119 Certificate Settings Pane"
   
   

6. Click New.

   The Create a New Identity Asserter Certificate page displays (see Figure 23-120).

   Figure 23-120 Create a New Identity Asserter Certificate Page

   
   Description of "Figure 23-120 Create a New Identity Asserter Certificate Page"
   
   

7. Configure the certificate as shown in Table 23-12.

   Table 23-12 Certificates Page Parameters

   Parameter	Value	Description
   alias		The name to assign to your new Certificate This is the alias of the keystore you created in Section 23.7.3.2.2, "Generating and Registering Certificates."
   Path		Specify the path name of the .der file containing the X509 certificate you wish to import. This is the file you created in Section 23.7.3.2.2, "Generating and Registering Certificates."

   
   

8. Click OK to save your settings.

9. Repeat the previous step for the SAML ID Asserter created in the SOA domain. Be sure to copy over testalias.der (assuming that this was the name given to your .DER file) from your WebLogic Home to the machine hosting the SOA domain.

To Configure an Asserting Party

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-121).

   Figure 23-121 Summary of Security Realms Pane

   
   Description of "Figure 23-121 Summary of Security Realms Pane"
   
   

3. Click your security realm.

   The Settings page for the security realm displays (see Figure 23-122).

   Figure 23-122 Security Realm Settings Page

   
   Description of "Figure 23-122 Security Realm Settings Page"
   
   

4. Open the Providers tab and select the Authentication subtab.

   The Authentication Settings pane displays (see Figure 23-123).

   Figure 23-123 Authentication Settings Pane

   
   Description of "Figure 23-123 Authentication Settings Pane"
   
   

5. Click the SAML Identity Asserter you created and open the Management tab and the Asserting Parties subtab.

   The Asserting Parties Settings pane displays (see Figure 23-124).

   Figure 23-124 Asserting Parties Settings Pane

   
   Description of "Figure 23-124 Asserting Parties Settings Pane"
   
   

6. Click New.

   The Create a New Asserting Party page displays (see Figure 23-125).

   Figure 23-125 Create a New Asserting Party Page

   
   Description of "Figure 23-125 Create a New Asserting Party Page"
   
   

7. Select the Profile and provide a Description for the Asserting Party.

   Use the same SAML profile you chose for the corresponding relying party (for example, Browser/POST).

8. Click OK to save your settings.

9. From the Asserting Parties Settings pane, click the Partner ID of the Asserting Party you just created (the Partner ID is assigned automatically).

   The Settings page for the new Asserting Party displays (see Figure 23-126).

   Figure 23-126 Asserting Party Settings Page

   
   Description of "Figure 23-126 Asserting Party Settings Page"
   
   

10. Configure the Asserting Party for the WebCenter domain Wiki service as shown in Table 23-13. For more information, see Table 23-5, "Relying Party Settings for Wiki Service".

    Table 23-13 WebCenter Domain - Asserting Party for Wiki

    Parameter	Value	Description
    Enabled	Checked	Specifies whether this Asserting Party can be used to obtain SAML assertions
    Description		A short description of this Asserting Party (for example, WebCenter Spaces for Wiki)
    Target URL		The target URL of this SAML Asserting Party (for example, http://example.com:8888/webcenter)
    POST Signing Certificate alias		The alias of the certificate trusted for verifying signatures on SAML protocol elements from this Asserting Party (for example, testalias). Must be set when using the Browser/POST profile.
    Source Site Redirect URIs	/owc_wiki/user/login.jz	An optional set of URIs from which unauthenticated users will be redirected to the configured ITS URL. If set, the IntersiteTransferURL must also be set. Note: Based on this setting, when you first access the destination site, you are redirected to the configured ITS URL (which in this case is within the source application), your session is established with the source application and then redirected to the destination site.
    Source Site ITS URL		The Intersite Transfer Service (ITS) URL of the SAML Source Site for this Asserting Party (for example, http://example.com:8888/webcenter/samlits/its). Used with SSO profiles only, to support the destination site first scenario, whereby a user tries to access a destination site URL prior to being authenticated and is redirected to the source site to be authenticated and obtain a SAML assertion. The Redirect URIs attribute must also be configured for source-site redirection to work. Note: If you check ITS requires SSL in Source Site Federation Services, you must also change the Source Site ITS URL to use HTTPS and the server's SSL port.
    Source Site ITS parameters	RPID=rp_00001	Optionally, zero or more query parameters, of the form name=value, that will be added to the ITS URL when redirecting to the source site. In this case, rp_00001 is the relying party ID for the OWC Wiki application specified in the SAML Credential Mapping Provider of the WebCenter domain which provides the destination site details. For more information, see Table 23-5, "Relying Party Settings for Wiki Service".
    Issuer URI		The issuer URI of the SAML Authority issuing assertions for this SAML Asserting Party (for example, http://www.example.com/webcenter). This URI should be same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 23-4, "SAML Credential Mapping Provider Security Realm Settings".
    Signature Required	Checked	If true, assertions must be signed. If false, signature elements are not required, but will be verified if present.
    Assertion Signing Certificate alias		The alias of the certificate trusted for verifying signatures on assertions from this Asserting Party (for example, testalias). This must be set if Signature Required is checked. The certificate must also be registered in the SAML Identity Asserter's certificate registry.

    
    

11. Click Save to save your settings.

12. Repeat steps 1 - 11 using the settings shown in Table 23-14 to configure the Asserting party for the WebCenter domain RSS application.

    Table 23-14 WE Domain - Asserting Party for RSS

    Parameter	Value	Description
    Enabled	Checked	Specifies whether this Asserting Party can be used to obtain SAML assertions.
    Description		A short description of this Asserting Party (for example, WebCenter Spaces for RSS)
    Target URL		The target URL of this SAML Asserting Party (for example, http://example.com:8888/webcenter)
    POST Signing Certificate alias		The alias of the certificate trusted for verifying signatures on SAML protocol elements from this Asserting Party (for example, testalias). Must be set when using the Browser/POST profile.
    Source Site Redirect URIs	/rss/rssservlet	An optional set of URIs from which unauthenticated users will be redirected to the configured ITS URL. If set, the IntersiteTransferURL must also be set. Note: Based on this setting, when you first access the destination site, you are redirected to the configured ITS URL (which in this case is within the source application), your session is established with the source application and then redirected to the destination site.
    Source Site ITS URL		The Intersite Transfer Service (ITS) URL of the SAML Source Site for this Asserting Party (for example, http://example.com:8888/webcenter/samlits/its). Used with SSO profiles only, to support the destination site first scenario, whereby a user tries to access a destination site URL prior to being authenticated and is redirected to the source site to be authenticated and obtain a SAML assertion. The Redirect URIs attribute must also be configured for source-site redirection to work. Note: If you check ITS requires SSL in Source Site Federation Services, you must also change the Source Site ITS URL to use HTTPS and the server's SSL port.
    Source Site ITS parameters	RPID=rp_00002	Optionally, zero or more query parameters, of the form name=value, that will be added to the ITS URL when redirecting to the source site. In this case rp_00002 is the relying party ID for RSS specified in the SAML Credential Mapping provider of the WebCenter domain which provides the destination site details. See Table 23-9, "Relying Party Settings for RSS" for more information about RSS settings.
    Issuer URI		The issuer URI of the SAML Authority issuing assertions for this SAML Asserting Party (for example, http://www.example.com/webcenter). This URI should be same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 23-4, "SAML Credential Mapping Provider Security Realm Settings".
    Signature Required	Checked	If true, assertions must be signed. If false, signature elements are not required, but will be verified if present.
    Assertion Signing Certificate alias		The alias of the certificate trusted for verifying signatures on assertions from this Asserting Party (for example, testalias). This must be set if Signature Required is checked. The certificate must also be registered in the SAML Identity Asserter's certificate registry.

    
    

13. Repeat steps 1 - 11 using the settings shown in Table 23-15 to configure the Asserting party for the WebCenter domain Discussions application.

    Table 23-15 WebCenter Domain - Asserting Party for Discussions

    Parameter	Value	Description
    Enabled	Checked	Specifies whether this Asserting Party can be used to obtain SAML assertions.
    Description		A short description of this Asserting Party (for example, WebCenter Spaces for Discussions)
    Target URL		The target URL of this SAML Asserting Party (for example, http://example.com:8888/webcenter)
    POST Signing Certificate alias		The alias of the certificate trusted for verifying signatures on SAML protocol elements from this Asserting Party (for example, testalias). This must be set when using the Browser/POST profile.
    Source Site Redirect URIs	/owc_discussions/admin/content-main.jsp /owc_discussions/login!withRedirect.jspa /owc_discussions/login!default.jspa /owc_discussions/login.jspa	An optional set of URIs from which unauthenticated users will be redirected to the configured ITS URL. If set, the IntersiteTransferURL must also be set. Note: Based on this setting, when you first access the destination site, you are redirected to the configured ITS URL (which in this case is within the source application), your session is established with the source application and then redirected to the destination site.
    Source Site ITS URL		The Intersite Transfer Service (ITS) URL of the SAML Source Site for this Asserting Party (for example, http://example.com:8888/webcenter/samlits/its). Used with SSO profiles only, to support the destination site first scenario, whereby a user tries to access a destination site URL prior to being authenticated and is redirected to the source site to be authenticated and obtain a SAML assertion. The Redirect URIs attribute must also be configured for source-site redirection to work. Note: If you check ITS requires SSL in Source Site Federation Services, you must also change the Source Site ITS URL to use HTTPS and the server's SSL port.
    Source Site ITS parameters	RPID=rp_00006	Optionally, zero or more query parameters, of the form name=value, that will be added to the ITS URL when redirecting to the source site. In this case rp_00006 is the relying party ID for OWC Discussions specified in the SAML Credential Mapping provider of the WebCenter domain which provides the destination site details. See Table 23-10, "Relying Party Settings for Discussions" for more information about Discussions settings.
    Issuer URI		The issuer URI of the SAML Authority issuing assertions for this SAML Asserting Party (for example, http://www.example.com/webcenter). This URI should be same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 23-4, "SAML Credential Mapping Provider Security Realm Settings".
    Signature Required	Checked	If true, assertions must be signed. If false, signature elements are not required, but will be verified if present.
    Assertion Signing Certificate alias		The alias of the certificate trusted for verifying signatures on assertions from this Asserting Party (for example, testalias). This must be set if Signature Required is checked. The certificate must also be registered in the SAML Identity Asserter's certificate registry.

    
    

14. Change domains to the SOA domain and repeat steps 1 - 11 using the settings shown in Table 23-16 to configure the Asserting Party for the SOA domain Worklist Community Detail service.

    Table 23-16 SOA Domain - Asserting Party for Worklist Community Detail

    Parameter	Value	Description
    Enabled	Checked	Specifies whether this Asserting Party can be used to obtain SAML assertions
    Description		A short description of this Asserting Party (for example, WebCenter Spaces for Worklist Detail)
    Target URL		The target URL of this SAML Asserting Party (for example, http://example.com:8888/webcenter)
    POST Signing Certificate alias		The alias of the certificate trusted for verifying signatures on SAML protocol elements from this Asserting Party (for example, testalias). Must be set when using Browser/POST profile.
    Source Site Redirect URIs	/workflow/WebCenterWorklistDetail/faces/adf.task-flow	An optional set of URIs from which unauthenticated users will be redirected to the configured ITS URL. If set, the IntersiteTransferURL must also be set. Note: Based on this setting, when you first access the destination site, you are redirected to the configured ITS URL (which in this case is within the source application), your session is established with the source application and then redirected to the destination site.
    Source Site ITS URL		The Intersite Transfer Service (ITS) URL of the SAML Source Site for this Asserting Party (for example, http://example.com:8888/webcenter/samlits/its). Used with SSO profiles only, to support the destination site first scenario, whereby a user tries to access a destination site URL prior to being authenticated and is redirected to the source site to be authenticated and obtain a SAML assertion. The Redirect URIs attribute must also be configured for source-site redirection to work. Note: If you check ITS requires SSL in Source Site Federation Services, you must also change the Source Site ITS URL to use HTTPS and the server's SSL port.
    Source Site ITS parameters	RPID=rp_00002	Optionally, zero or more query parameters, of the form name=value, that will be added to the ITS URL when redirecting to the source site. In this case rp_00002 is the relying party ID for the Worklist Detail application specified in the SAML Credential Mapping provider for the WebCenter domain, which provides the destination site details. For more information, see Table 23-6, "Relying Party Settings for Worklist Community Detail".
    Issuer URI		The issuer URI of the SAML Authority issuing assertions for this SAML Asserting Party (for example, http://www.example.com/webcenter). This URI should be same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 23-4, "SAML Credential Mapping Provider Security Realm Settings".
    Signature Required	Checked	If checked, assertions must be signed. If unchecked, signature elements are not required, but will be verified if present.
    Assertion Signing Certificate alias		The alias of the certificate trusted for verifying signatures on assertions from this Asserting Party (for example, testalias). This must be set if Signature Required is checked. The certificate must also be registered in the SAML Identity Asserter's certificate registry.

    
    

15. Change domains to the SOA domain and repeat steps 1 - 11 using the settings shown in Table 23-17 to configure the Asserting Party for the SOA domain Worklist SDP service. For more information see Table 23-7, "Relying Party Settings for Worklist SDP" and Table 23-8, "Relying Party Settings for Worklist Integration".

    Table 23-17 SOA Domain - Asserting Party for Worklist SDP

    Parameter	Value	Description
    Enabled	Checked	Specifies whether this Asserting Party can be used to obtain SAML assertions.
    Description		A short description of this Asserting Party (for example, WebCenter Spaces for Worklist SDP)
    Target URL		The target URL of this SAML Asserting Party (for example, http://example.com:8888/webcenter)
    POST Signing Certificate alias		The alias of the certificate trusted for verifying signatures on SAML protocol elements from this Asserting Party (for example, testalias). Must be set when using Browser/POST profile.
    Source Site Redirect URIs	/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow	An optional set of URIs from which unauthenticated users will be redirected to the configured ITS URL. If set, the IntersiteTransferURL must also be set. Note: Based on this setting, when you first access the destination site, you are redirected to the configured ITS URL (which in this case is within the source application), your session is established with the source application and then redirected to the destination site.
    Source Site ITS URL		The Intersite Transfer Service (ITS) URL of the SAML Source Site for this Asserting Party (for example, http://example.com:8888/webcenter/samlits/its). Used with SSO profiles only, to support the destination site first scenario, whereby a user tries to access a destination site URL prior to being authenticated and is redirected to the source site to be authenticated and obtain a SAML assertion. The Redirect URIs attribute must also be configured for source-site redirection to work. Note: If you check ITS requires SSL in Source Site Federation Services, you must also change the Source Site ITS URL to use HTTPS and the server's SSL port.
    Source Site ITS parameters	RPID=rp_00003	Optionally, zero or more query parameters, of the form name=value, that will be added to the ITS URL when redirecting to the source site. In this case rp_00003 is the relying party ID for the Worklist SDP application specified in the SAML Credential Mapping provider of the WebCenter domain, which provides the destination site details. For more information, see Table 23-7, "Relying Party Settings for Worklist SDP".
    Issuer URI		The issuer URI of the SAML Authority issuing assertions for this SAML Asserting Party (for example, http://www.example.com/webcenter). This URI should be same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 23-4, "SAML Credential Mapping Provider Security Realm Settings".
    Signature Required	Checked	If true, assertions must be signed. If false, signature elements are not required, but will be verified if present.
    Assertion Signing Certificate alias		The alias of the certificate trusted for verifying signatures on assertions from this Asserting Party (for example, testalias). This must be set if Signature Required is checked. The certificate must also be registered in the SAML Identity Asserter's certificate registry.

    
    

16. Change domains to the SOA domain and repeat steps 1 - 11 using the settings shown in Table 23-18 to configure the Asserting Party for the SOA domain Worklist Community Integration service.

    Table 23-18 In SOA Domain, Asserting party For Worklist Integration

    Parameter	Value	Description
    Enabled	Checked	Specifies whether this Asserting Party can be used to obtain SAML assertions
    Description	WebCenter Spaces for Worklist SDP	A short description of this Asserting Party (for example, WebCenter Spaces for Worklist SDP)
    Target URL		The target URL of this SAML Asserting Party (for example, http://example.com:8888/webcenter)
    POST Signing Certificate alias		The alias of the certificate trusted for verifying signatures on SAML protocol elements from this Asserting Party (for example, testalias). Must be set when using Browser/POST profile.
    Source Site Redirect URIs	/integration/worklistapp/ssologin /integration/worklistapp/faces/home.jspx	An optional set of URIs from which unauthenticated users will be redirected to the configured ITS URL. If set, the IntersiteTransferURL must also be set. Note: Based on this setting, when you first access the destination site, you are redirected to the configured ITS URL (which in this case is within the source application), your session is established with the source application and then redirected to the destination site.
    Source Site ITS URL		The Intersite Transfer Service (ITS) URL of the SAML Source Site for this Asserting Party (for example, http://example.com:8888/webcenter/samlits/its). Used with SSO profiles only, to support the destination site first scenario, whereby a user tries to access a destination site URL prior to being authenticated and is redirected to the source site to be authenticated and obtain a SAML assertion. The Redirect URIs attribute must also be configured for source-site redirection to work. Note: If you check ITS requires SSL in Source Site Federation Services, you must also change the Source Site ITS URL to use HTTPS and the server's SSL port.
    Source Site ITS parameters	RPID=rp_00004	Optionally, zero or more query parameters, of the form name=value, that will be added to the ITS URL when redirecting to the source site. In this case rp_00004 is the relying party ID for the Worklist Integration application specified in the SAML Credential Mapping provider of the WebCenter domain, which provides the destination site details. For more information, see Table 23-8, "Relying Party Settings for Worklist Integration".
    Issuer URI		The issuer URI of the SAML Authority issuing assertions for this SAML Asserting Party (for example, http://www.example.com/webcenter). This URI should be same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 23-4, "SAML Credential Mapping Provider Security Realm Settings".
    Signature Required	Checked	If true, assertions must be signed. If false, signature elements are not required, but will be verified if present.
    Assertion Signing Certificate alias		The alias of the certificate trusted for verifying signatures on assertions from this Asserting Party (for example, testalias). This must be set if Signature Required is checked. The certificate must also be registered in the SAML Identity Asserter's certificate registry.

    
    

23.7.3.2.7 Configuring Destination Site Federation Services

This section describes how to configure the Destination Site Federation Services for the Wiki service, RSS, and the Worklist service on the WebCenter domain.

To configure the Destination Site Federation Services:

1. Log in to the WebLogic Server Administration Console.

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

2. On the Domain Structure pane, expand the Environment node and click Servers.

   The Summary of Servers page displays (see Figure 23-127).

   Figure 23-127 Summary of Servers Page

   
   Description of "Figure 23-127 Summary of Servers Page"
   
   

3. Click WLS_Services (the managed server where the Wiki service and Discussions service are deployed) and open the Configuration tab.

4. Open the Federation Services tab and the SAML 1.1 Destination Site subtab.

   The SAML 1.1 Destination Site Settings pane displays (see Figure 23-128).

   Figure 23-128 SAML 1.1 Destination Site Settings Pane (Wiki and Discussions)

   
   Description of "Figure 23-128 SAML 1.1 Destination Site Settings Pane (Wiki and Discussions)"
   
   

5. Configure the SAML destination site attributes for the Wiki and Discussions applications as shown in Table 23-19.

   Table 23-19 SAML Destination Site Attributes (Wiki and Discussions)

   Parameter	Value	Description
   Destination Site Enabled	Checked	Specifies whether the Destination Site is enabled.
   ACS Requires SSL	Unchecked	Specifies whether the Assertion Consumer Service requires SSL. If checked, then ensure that the ACS URL specified in the Credential Mapper's relying party uses HTTPS and target server's SSL port.
   Assertion Consumer URIs	/owc_wiki/samlacs/acs /owc_discussions/samlacs/acs [add on top, leave rest as is]	The Assertion Consumer URIs. In this case, we have chosen for the ACS to reside within the target app so that it uses the same login cookie.
   POST Recipient Check Enabled	Checked	Specifies whether the POST recipient check is enabled. When checked, the recipient of the SAML Response must match the URL in the HTTP Request.
   POST One use Check Enabled	Checked	Specifies whether the POST one-use check is enabled.

   
   

6. Click Save to save your settings, and restart the WLS_Services server so that they take effect.

7. From the Domain Structure pane, expand the Environment node and click Servers.

8. Click WLS_Spaces (the managed server where RSS is deployed) and open the Configuration tab.

9. Open the Federation Services tab and the SAML 1.1 Destination Site subtab.

   The SAML 1.1 Destination Site Settings pane displays (see Figure 23-129).

   Figure 23-129 SAML 1.1 Destination Site Settings Pane (RSS)

   
   Description of "Figure 23-129 SAML 1.1 Destination Site Settings Pane (RSS)"
   
   

10. Configure the SAML destination site attributes for RSS as shown in Table 23-20.

    Table 23-20 SAML Destination Site Attributes (RSS)

    Parameter	Value	Description
    Destination Site Enabled	Checked	Specifies whether the Destination Site is enabled.
    ACS Requires SSL	Unchecked	Specifies whether the Assertion Consumer Service requires SSL. If checked, then ensure that ACS URL specified in Credential Mapper's relying party uses https and target server's SSL port.
    Assertion Consumer URIs	/rss/samlacs/acs (add on top, leave rest as is)	The Assertion Consumer URIs. In this case, we have chosen for the ACS to reside within the target app so that it uses the same login cookie.
    POST Recipient Check Enabled	Checked	Specifies whether the POST recipient check is enabled. When true, the recipient of the SAML Response must match the URL in the HTTP Request.
    POST One use Check Enabled	Checked	Specifies whether the POST one-use check is enabled.

    
    

11. Click Save to save your settings, and restart the WSL_Spaces server so that they take effect.

12. Navigate to the SOA domain and then to soa_server1, or the managed server where the Worklist applications are deployed.

13. Follow the same steps as above to open the SAML 1.1 Destination Site subtab.

    The SAML 1.1 Destination Site Settings pane displays (see Figure 23-130).

    Figure 23-130 SAML 1.1 Destination Site Settings Pane (Worklist Detail and SDP)

    
    Description of "Figure 23-130 SAML 1.1 Destination Site Settings Pane (Worklist Detail and SDP)"
    
    

14. Configure the SAML 1.1 Destination Site attributes for Worklist Detail and SDP as shown in Table 23-21.

    Table 23-21 SOA Domain - SAML Destination Site Attributes (Worklist Detail and SDP)

    Parameter	Value	Description
    Destination Site Enabled	Checked	Specifies whether the Destination Site is enabled.
    ACS Requires SSL	Unchecked	Specifies whether the Assertion Consumer Service requires SSL. If checked, then ensure that ACS URL specified in Credential Mapper's relying party uses HTTPS and the target server's SSL port.
    Assertion Consumer URIs	/workflow/WebCenterWorklistDetail/samlacs/acs /workflow/sdpmessagingsca-ui-worklist/samlacs/acs /integration/worklistapp/samlacs/acs (add on top, leave rest as is)	The Assertion Consumer URIs. In this case, we have chosen for the ACS to reside within the target app so that it uses the same login cookie.
    POST Recipient Check Enabled	Checked	Specifies whether the POST recipient check is enabled. When checked, the recipient of the SAML Response must match the URL in the HTTP Request.
    POST One use Check Enabled	Checked	Specifies whether the POST one-use check is enabled.

    
    

15. Click Save to save your settings.

16. Restart the SOA managed server.

23.7.3.2.8 Checking Your Configuration

The last step in the process is to check that your single sign-on configuration is working. To do that:

1. Check that when you try to access the Wiki and RSS applications independently, you are taken to the WebCenter Spaces login page (source site) and then directed to the URL you were trying to access.

2. Now log into WebCenter Spaces and check that you're not challenged for credentials when:

   • You access the Wiki from a group space

   • You access RSS from a list task flow

   • You click Forum Administration from Group Space Settings > Services > Discussions (assuming this service is provisioned for the group space)

   • You click a Forum from Group Space Settings from Discussions

23.7.4 Configuring SSO with Microsoft Clients

This section describes how to set up single sign-on (SSO) with Microsoft clients, using Windows authentication based on the Simple and Protected Negotiate (SPNEGO) mechanism and the Kerberos protocol, together with the WebLogic Negotiate Identity Assertion provider for the WebCenter Spaces application. This SSO approach enables Microsoft clients (such as browsers), authenticated in a Windows domain using Kerberos, to be transparently authenticated to web applications (such as WebCenter Spaces) in a WebLogic domain based on the same credentials, and without the need to type in their password again.

Cross-platform authentication is achieved by emulating the negotiate behavior of native Windows-to-Windows authentication services that use the Kerberos protocol. In order for cross-platform authentication to work, non-Windows servers (in this case, WebLogic Server) need to parse SPNEGO tokens in order to extract Kerberos tokens, which are then used for authentication.

This section contains the following sub-sections:

• Section 23.7.4.1, "Microsoft Client SSO Concepts"

• Section 23.7.4.2, "System Requirements"

• Section 23.7.4.3, "Configuring SSO with Microsoft Clients"

23.7.4.1 Microsoft Client SSO Concepts

Understanding Kerberos

Kerberos is a secure method for authenticating a request for a service in a network. The Kerberos protocol comprises three parties: a client, a server and a trusted third party to mediate between them, known as the KDC (Key Distribution Center). Under Kerberos, a server allows a user to access its service if the user can provide the server a Kerberos ticket that proves its identity. Both the user and the service are required to have keys registered with the KDC.

The diagram below describes the basic exchanges that must take place before a client connects to a server.

Figure 23-131 Connecting to a Server Through a Key Distribution Center

Description of "Figure 23-131 Connecting to a Server Through a Key Distribution Center"

Understanding SPNEGO

SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is a GSSAPI "pseudo mechanism" that is used to negotiate one of a number of possible real mechanisms. SPNEGO is used when a client application wants to authenticate to a remote server, but neither end is sure what authentication protocols the other supports. The pseudo-mechanism uses a protocol to determine what common GSSAPI mechanisms are available, selects one, and then dispatches all further security operations to it. This can help organizations deploy new security mechanisms in a phased manner.

SPNEGO's most visible use is in Microsoft's HTTP Negotiate authentication extension. The negotiable sub-mechanisms include NTLM and Kerberos, both used in Active Directory.

This feature enables a client browser to access a protected resource on WebLogic Server, and to transparently provide the WebLogic Server with authentication information from the Kerberos database using a SPNEGO ticket. The WebLogic Server is able to recognize the ticket and extract the information from it. WebLogic Server then uses the information for authentication and grants access to the resource if the authenticated user is authorized to access it. (Kerberos is responsible for authentication only; authorization is still handled by WebLogic Server.)

Figure 23-132 SPNEGO-based Authentication

Description of "Figure 23-132 SPNEGO-based Authentication"

23.7.4.2 System Requirements

To use SSO with Microsoft clients you need:

A host computer with:

• Windows 2000 or later installed

• Fully-configured Active Directory authentication service. Specific Active Directory requirements include:

  • User accounts for mapping Kerberos services

  • Service Principal Names (SPNs) for those accounts

  • Key tab files created and copied to the start-up directory in the WebLogic Server domain

• WebLogic Server installed and configured properly to authenticate through Kerberos, as described in this section

Client systems with:

• Windows 2000 Professional SP2 or later installed

• One of the following types of clients:

  • A properly configured Internet Explorer browser. Internet Explorer 6.01 or later is supported.

  • .NET Framework 1.1 and a properly configured Web Service client.

Note:

Clients must be logged on to a Windows 2000 domain and have Kerberos credentials acquired from the Active Directory server in the domain. Local logons will not work.

23.7.4.3 Configuring SSO with Microsoft Clients

Configuring SSO with Microsoft clients requires configuring the Microsoft Active Directory, the client, and the WebLogic Server domain shown in Figure 23-133. For detailed configuration steps and troubleshooting, see "Configuring Single Sign-On with Microsoft Clients" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

Figure 23-133 Configuring SSO with Microsoft Clients

Description of "Figure 23-133 Configuring SSO with Microsoft Clients"

To configure Microsoft clients for SSO:

1. Configure your network domain to use Kerberos.

2. Create a Kerberos identification for WebLogic Server.

   1. Create a user account in the Active Directory for the host on which WebLogic Server is running.

   2. Create a Service Principal Name for this account.

   3. Create a user mapping and keytab file for this account.

3. Choose a Microsoft client (in this case Internet Explorer) and configure it to use Windows Integrated authentication.

4. Set up the WebLogic Server domain (wc_domain in this case) to use Kerberos authentication.

   1. Create a JAAS login file that points to the Active Directory server in the Microsoft domain and the keytab file created in Step 2.

   2. Configure a Negotiate Identity Assertion provider in the WebLogic Server security realm (see Section 23.7.4.3.1, "Configuring the Negotiate Identity Assertion Provider").

   3. Configure the WebLogic Server domain to use the Active Directory Authenticator so that the WebLogic domain uses the same Active Directory of the domain as the identity store. You could also use a different identity store and match the users in this store with the Active Directory users of your domain, but using the Active Directory authenticator is recommended as maintaining two different identity stores risks them getting out of sync. See Section 23.7.4.3.2, "Configuring an Active Directory Authentication Provider").

      Caution:

      Ensure that only the identity store is configured for Active Directory. The policy and credential stores are not certified for Active Directory.

5. Start the WebLogic Servers (Administration Server and managed servers) using specific start-up arguments. Repeat steps 4 and 5 for the SOA Domain to enable single sign-on for SOA applications.

6. Configure WebCenter Spaces (see Section 23.7.4.3.3, "Configuring WebCenter Spaces").

7. Configure the discussions server (see Section 23.7.4.3.4, "Configuring the Discussions Server for SSO").

23.7.4.3.1 Configuring the Negotiate Identity Assertion Provider

This section provides instructions for creating and configuring a Negotiate Identity Assertion provider. The Negotiate Identity Assertion provider enables single sign-on (SSO) with Microsoft clients. The identity assertion provider decodes Simple and Protected Negotiate (SPNEGO) tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps them to WebLogic users. The Negotiate Identity Assertion provider uses the Java Generic Security Service (GSS) Application Programming Interface (API) to accept the GSS security context via Kerberos.

To configure the Negotiate Identity Assertion provider:

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-134).

   Figure 23-134 Summary of Security Realms Pane

   
   Description of "Figure 23-134 Summary of Security Realms Pane"
   
   

3. Click your security realm.

   The Settings page for the security realm displays (see Figure 23-135).

   Figure 23-135 Security Realm Settings Page

   
   Description of "Figure 23-135 Security Realm Settings Page"
   
   

4. Open the Providers tab and select the Authentication subtab.

   The Authentication Settings pane displays (see Figure 23-136).

   Figure 23-136 Authentication Settings Pane

   
   Description of "Figure 23-136 Authentication Settings Pane"
   
   

5. Click New.

   The Create a New Authentication Provider pane displays (see Figure 23-137).

   Figure 23-137 Create a New Authentication Provider Pane

   
   Description of "Figure 23-137 Create a New Authentication Provider Pane"
   
   

6. Enter a Name for the identity asserter, and select NegotiateIdentityAsserter as the Type.

7. Click OK.

23.7.4.3.2 Configuring an Active Directory Authentication Provider

Follow the steps below to configure an Active Directory authentication provider using the WebLogic Administration Console.

To configure an Active Directory Authentication provider:

1. Log in to the WebLogic Server Administration Console.

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

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

   The Summary of Security Realms pane displays (see Figure 23-138).

   Figure 23-138 Summary of Security Realms Pane

   
   Description of "Figure 23-138 Summary of Security Realms Pane"
   
   

3. Click your security realm.

   The Settings page for the security realm displays (see Figure 23-139).

   Figure 23-139 Security Realm Settings Page

   
   Description of "Figure 23-139 Security Realm Settings Page"
   
   

4. Open the Providers tab and select the Authentication subtab.

   The Authentication Settings pane displays (see Figure 23-140).

   Figure 23-140 Authentication Settings Pane

   
   Description of "Figure 23-140 Authentication Settings Pane"
   
   

5. Click New.

   The Create a New Authentication Provider pane displays (see Figure 23-141).

   Figure 23-141 Create a New Authentication Provider Pane

   
   Description of "Figure 23-141 Create a New Authentication Provider Pane"
   
   

6. Enter a Name for the authentication provider, and select ActiveDirectoryAuthenticator as the Type.

7. Click OK.

8. Click on the authentication provider you just created in the list of providers.

   The Settings page for the provider displays (see Figure 23-142).

   Figure 23-142 Provider Settings Page

   
   Description of "Figure 23-142 Provider Settings Page"
   
   

9. Open the Configuration tab and the Common subtab.

10. Set the Control Flag to SUFFICIENT and click Save.

    Note:

    The Control Flag settings of any other authenticators must also be changed to SUFFICIENT. If there is a pre-existing Default Authenticator that has its Control Flag set to REQUIRED, it must be changed to SUFFICIENT.

11. Open the Provider Specific subtab.

    The Provider Specific Settings pane displays (see Figure 23-143).

    Figure 23-143 Provider Specific Settings Pane

    
    Description of "Figure 23-143 Provider Specific Settings Pane"
    
    

12. Complete the fields as shown in the table below. Leave the rest of the fields set to their default values.

    Table 23-22 Active Directory Authenticator Settings

    Parameter	Value	Description
    Host:		The host ID of the LDAP server
    Port:		The port number of the LDAP server
    Principal:		The LDAP administrator principal
    Credential:
    User Base DN:		The user search base (for example, OU=spnego unit,DC=admin,DC=oracle,DC=com)
    User From Name Filter:	(&(cn=%u)(objectclass=user))
    User Search Scope:	subtree
    User Name Attribute:	cn
    User Search Scope:	user
    Group Base DN:		The group search base (same as User Base DN)
    Group From Name Filter:	(&(cn=%g)(objectclass=group))
    Group Search Scope:	subtree
    Static Group Name Attribute:	cn
    Static Group Object Class:	group
    Static Member DN Attribute:	member
    Static Group DNs from Member DN Filter:	(&(member=%M)(objectclass=group))

    
    

13. Click Save.

14. On the Provider Summary page, reorder the providers in the following order, making sure that their Control Flags are set to SUFFICIENT where applicable:

    1. Negotiate Identity Asserter

    2. ActiveDirectoryAuthenticator (SUFFICIENT)

    3. DefaultAuthenticator (SUFFICIENT)

    4. Other authenticators...

23.7.4.3.3 Configuring WebCenter Spaces

Once you have completed the steps for configuring the Negotiate Identity Assertion Provider and Active Directory Authenticator, and all applications on your WebLogic domain are configured for single sign-on with Microsoft clients in the required domain, a final step is required to provide a seamless single-sign-on experience for your users when accessing WebCenter Spaces. There are two options for doing this:

• Turn off public access, by logging into WebCenter Spaces as an administrator and removing view access from the Public role. Once public access has been turned off, accessing the URL http://host:port/webcenter will directly take the user to the authenticated view rather than the default public page which has a login section. This is recommended when users will be accessing WebCenter Spaces only using Internet Explorer, and will be confined to the domain where WNA is set up.

• If you need to retain public access to WebCenter Spaces, then the recommendation is to use the oracle.webcenter.osso.enabled flag when starting the WLS_Spaces server. This flag tells WebCenter Spaces that SSO is being used and no login form should be displayed on the default landing page. A login link is displayed instead that the user can click to invoke the SSO authentication where the user will be automatically logged in. If Firefox is used to access WebCenter Spaces within the Windows network configured for WNA, or any browser is used to access WebCenter Spaces from outside the Windows network domain, the user will see the login page after clicking the Login link.

23.7.4.3.4 Configuring the Discussions Server for SSO

This section describes how to configure Oracle WebCenter Discussions Server for single sign-on. Before configuring the discussions server for SSO, be sure that it has been configured to use the same identity store LDAP as WebCenter Spaces, as described in Section 23.3.4.1, "Migrating the WebCenter Discussions Server to use an External LDAP."

To set up the discussions server for SSO:

1. Log in to the Oracle WebCenter Discussions Server Admin Console at:

   http://host:port/owc_discussions/admin
   

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

2. Open the System Properties page and edit (if it already exists) or add the owc_discussions.sso.mode property, setting it's value to true.

3. Edit or add the jiveURL property to point to the base URL of the SSO server. For example:

   jiveURL = example.com:8890/owc_discussions
   

23.8 Configuring WS-Security

This section describes setting up WS-Security for WebCenter applications (including WebCenter Spaces and custom WebCenter applications) and related components based on your topology. This section covers the following configurations:

• a simple topology, with the WebCenter application and all components sharing the same domain,

• a typical topology, with the WebCenter application and components divided across two domains, and

• a complex topology, with the WebCenter application and components divided across multiple domains.

Within these three topologies, configuration is described for the WebCenter application, Oracle WebCenter Discussions, the Worklist service, and WSRP producers. These configurations and the steps for two additional WS-Security configurations are covered in the following sections:

• Section 23.8.1, "Configuring WS-Security for a Simple Topology"

• Section 23.8.2, "Configuring WS-Security for a Typical Topology"

• Section 23.8.3, "Configuring WS-Security for a Complex Topology"

• Section 23.8.4, "Securing Oracle WebLogic Communication Services (OWLCS) with WS-Security"

• Section 23.8.5, "Securing a WSRP Producer with WS-Security"

• Section 23.8.6, "Securing WebCenter Spaces for Applications Consuming Spaces Client APIs with WS-Security"

23.8.1 Configuring WS-Security for a Simple Topology

This section describes how to configure WS-Security for a topology where the WebCenter application, the BPEL server, and WSRP producers share the same domain (Figure 23-144).

Figure 23-144 WS-Security for a Simple Configuration

Description of "Figure 23-144 WS-Security for a Simple Configuration"

The steps to configure WS-Security for a simple single-domain WebCenter topology are described in the following sections:

• Section 23.8.1.1, "Setting Up the WebCenter Domain Keystore"

• Section 23.8.1.2, "Configuring the Discussions Server for a Simple Topology"

• Section 23.8.1.3, "Configuring the BPEL Server for a Simple Topology"

23.8.1.1 Setting Up the WebCenter Domain Keystore

The security credentials of the WebCenter application, discussions server, BPEL server, and WSRP producers can be retrieved and managed using a Java Keystore (JKS). A keystore is a file that provides information about available public and private keys. Keys are used for a variety of purposes, including authentication and data integrity. User certificates and the trust points needed to validate the certificates of peers are also stored securely in the wallet or keystore. See the Oracle Fusion Middleware Security and Administrator's Guide for Web Services for information about JKS.

This section contains the following subsections:

• Section 23.8.1.1.1, "Creating the WebCenter Domain Keystore"

• Section 23.8.1.1.2, "Configuring the Keystore with WLST"

• Section 23.8.1.1.3, "Configuring the Keystore Using Fusion Middleware Control"

• Section 23.8.1.1.4, "Unconfiguring a Keystore Provider Using Fusion Middleware Control"

23.8.1.1.1 Creating the WebCenter Domain Keystore

This section describes how to create a keystore and keys using a Java Keystore (JKS). JKS is the proprietary keystore format defined by Sun Microsystems. To create and manage the keys and certificates in the JKS, use the keytool utility that is distributed with the Java JDK 6.

To create the WebCenter domain keystore:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, generate a key pair:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias orakey -keypass key_password -keystore keystore -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the name of the consumer (for example, cn=spaces,dc=example,dc=com)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore is the keystore name, (for example, webcenter.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1064).

     Example 23-1 Generating the Keypair

     keytool -genkeypair -keyalg RSA -dname "cn=spaces,dc=example,dc=com" -alias orakey -keypass welcome1 -keystore webcenter.jks -storepass welcome1 -validity 1064
     

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

3. Export the certificate containing the public key:

   keytool -exportcert -v -alias orakey -keystore keystore -storepass keystore_password -rfc -file orakey.cer
   

   Where:

   • keystore is the keystore name, (for example, webcenter.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   Example 23-2 Exporting the Certificate Containing the Public Key

   keytool -exportcert -v -alias orakey -keystore webcenter.jks -storepass welcome1 -rfc -file orakey.cer
   

4. Import the certificate with the alias webcenter_spaces_ws (choose Yes when prompted whether to overwrite the existing certificate with the alias orakey):

   keytool -importcert -alias webcenter_spaces_ws -file orakey.cer -keystore webcenter.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password

   Example 23-3 Importing the Certificate

   keytool -importcert -alias webcenter_spaces_ws -file orakey.cer -keystore webcenter.jks -storepass welcome1
   

5. Continue by configuring the keystore using either WLST as described in Section 23.8.1.1.2, "Configuring the Keystore with WLST," or using Fusion Middleware Control as described in Section 23.8.1.1.3, "Configuring the Keystore Using Fusion Middleware Control."

   Table 23-23 shows the keystore contents you should wind up with after creating and configuring the keystore.

   Table 23-23 WebCenter Domain Keystore Contents for a Simple Topology

   Key Alias	Description
   orakey	Key pair used to sign and encrypt outbound messages from WebCenter Spaces. This key is used by both OWSM (Portlets and Worklist) and Discussions.
   webcenter_spaces_ws	Certificate containing the public key for the orakey private key used in the WebCenter domain. The certificate is used to encrypt outbound WebService messages from the Workflow application on BPEL Server1 in the WebCenter domain, to the WebService APIs on WebCenter domain.

   
   

23.8.1.1.2 Configuring the Keystore with WLST

After creating the keystore, configure the keystore service and update the credential store so that OWSM can read the keystore and keys correctly.

To configure the credential store:

1. Go to the <DOMAIN_HOME>/config/fmwconfig directory, and open the file jps-config.xml in an editor.

2. Locate the <serviceInstance node for the keystore.provider Provider

3. Make sure that the webcenter.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./webcenter.jks.

4. Use the following WLST commands to update the credential store:

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password=keystore_password, desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="orakey", password=private_key_password, desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="orakey", password=private_key_password, desc="Signing key")
   

   Where:

   • keystore_password is the keystore password specified in step 2 of Section 23.8.1.1.1, "Creating the WebCenter Domain Keystore," (for example, welcome1)

   • private_key_password is the private key password specified in step 2 of Section 23.8.1.1.1, "Creating the WebCenter Domain Keystore," (for example, welcome1)

   Example 23-4 Updating the Credential Store

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="orakey", password="welcome1", desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="orakey", password="welcome1", desc="Signing key")
   

5. Restart all servers.

23.8.1.1.3 Configuring the Keystore Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider as described in Section 23.8.1.1.4, "Unconfiguring a Keystore Provider Using Fusion Middleware Control." Otherwise, continue with the steps below.

To configure the keystore provider:

1. Make sure that the webcenter.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./webcenter.jks.

2. Open Fusion Middleware Control and log into the WebCenter domain.

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

3. In the Navigation pane, expand the WebLogic Domain node and click on the WebCenter domain (webcenter by default).

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

   The Security Provider Configuration page displays (see Figure 23-145).

   Figure 23-145 Security Provider Configuration Page

   
   Description of "Figure 23-145 Security Provider Configuration Page"
   
   

5. Expand the Keystore section on the Security Provider Configuration page.

6. Click Configure.

   The Keystore Configuration page displays (see Figure 23-146).

   Figure 23-146 Keystore Configuration Page

   
   Description of "Figure 23-146 Keystore Configuration Page"
   
   

7. Check Configure Keystore Management and use the following settings to specify the location of the keystore that contains the certificate and private key, and the signature key and encryption key aliases:

   • Keystore Path: ./webcenter.jks

   • Password: Enter and confirm the password for the keystore.

   • Key Alias: orakey

   • Signature Password: Enter and confirm the password for the signature key.

   • Crypt Alias: orakey

   • Crypt Password: Enter and confirm the password for the encryption key.

8. Click OK to save your settings.

9. Restart the Administration server for the domain.

23.8.1.1.4 Unconfiguring a Keystore Provider Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider before configuring a new provider. If a keystore provider is not already configured, ignore this section and continue with the steps to configure the keystore in Section 23.8.1.1.3, "Configuring the Keystore Using Fusion Middleware Control."

To unconfigure a keystore provider using Fusion Middleware Control:

1. Open Fusion Middleware Control and log into the target domain.

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

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

   The Security Provider Configuration page displays (see Figure 23-147).

   Figure 23-147 Security Provider Configuration Page

   
   Description of "Figure 23-147 Security Provider Configuration Page"
   
   

3. Expand the Keystore section on the Security Provider Configuration page.

4. Click Configure.

   The Keystore Configuration page displays (see Figure 23-148).

   Figure 23-148 Keystore Configuration Page

   
   Description of "Figure 23-148 Keystore Configuration Page"
   
   

5. Uncheck Configure Keystore Management.

6. Click OK.

23.8.1.2 Configuring the Discussions Server for a Simple Topology

To use the Oracle WebCenter Discussions with WebCenter Spaces or a custom WebCenter application, you must enable Web Services Security (WS-Security) trusted authentication. WS-Security establishes a trust relationship between your WebCenter application and Oracle WebCenter Discussions so that the application can pass the user identity information to the discussions server without knowing the user's credentials.

Note:

Discussions-specific Web Services messages sent by WebCenter applications to the Oracle WebCenter Discussions server are not encrypted. For message confidentiality, the Discussions server URL must be accessed over Secure Socket Layer (SSL). For more information, see Section 23.6, "Configuring WebCenter Applications and Components to Use SSL."

This section describes how to add the WS-Security-related properties in your Oracle WebCenter Discussions connection into WebCenter Spaces or your WebCenter application. For information on how to add new properties, see Table 12-4, "Additional Discussion Connection Properties" in Section 12.3.1, "Registering Discussions Servers Using Fusion Middleware Control."

To configure WS-Security on the discussions server side, you must create a keystore certificate properties file, specify it for the ClassLoader, and modify the webservices.soap.custom.crypto.fileName system property. These configuration steps are described in the following sub-sections:

• Section 23.8.1.2.1, "Importing the WebCenter Domain Certificate"

• Section 23.8.1.2.2, "Creating the Keystore Certificate Properties File"

• Section 23.8.1.2.3, "Specifying the Properties File for ClassLoader"

• Section 23.8.1.2.4, "Updating the System Properties for WS-Security"

• Section 23.8.1.2.5, "Configuring the Discussions Server Connection Settings"

23.8.1.2.1 Importing the WebCenter Domain Certificate

Create a keystore by importing the certificate containing the public key of the WebCenter domain.

To import the WebCenter domain certificate:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, import the certificate containing the public key of the WebCenter domain:

   keytool -importcert -alias df_orakey_public -file orakey.cer -keystore owc_discussions.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   • Example 23-5 Importing the WebCenter Domain Certificate

     keytool -importcert -alias df_orakey_public -file orakey.cer -keystore owc_discussions.jks -storepass welcome1
     

3. At the prompt "Trust this certificate?", choose yes.

23.8.1.2.2 Creating the Keystore Certificate Properties File

The server-side keystore certificate configuration must be stored in a properties file (keystore.properties) and specified as a system property on the discussions server. The properties file must then be loaded in the ClassLoader for the WS-Secure Handler to pick it up.

To create the properties file:

1. Create a properties file with the following entries:

   org.apache.ws.security.crypto.provider= <Specify your crypto provider (typically org.apache.ws.security.components.crypto.Merlin)>
   org.apache.ws.security.crypto.merlin.keystore.type=jks
   org.apache.ws.security.crypto.merlin.keystore.password=<Specify the keystore password of your server certificate. Note that the password stored in this file is in clear text because of a limitation of the Ws-Security provider WSS4J used in Oracle Discussions Server.>
   org.apache.ws.security.crypto.merlin.keystore.alias=df_orakey_public
   org.apache.ws.security.crypto.merlin.file=<Absolute path of directory containing the certificate file created above>/owc_discussions.jks 
   

2. Save the file as keystore.properties.

23.8.1.2.3 Specifying the Properties File for ClassLoader

There are two ways you can choose to specify your keystore.properties file based on your setup. Using the same file mounted across different servers is recommended when using a Clustered Discussions Server installation in Linux.

To specify the properties file for ClassLoader, do one of the following:

• Specify the properties file as the CLASSPATH in setDomainEnv.sh.

  For Linux:

  1. Place the keystore.properties file in a directory (for example, . /home/user/keystore/)

  2. Open DOMAIN_HOME/bin/setDomainEnv.sh.

  3. Towards the end of the file, add the following lines to specify this directory as the CLASSPATH.

     if [ "${CLASSPATH}" != "" ] ; then
       CLASSPATH="${CLASSPATH}${CLASSPATHSEP}/home/user/keystore/"
       export CLASSPATH
     else
       CLASSPATH="/home/user/keystore/"
       export CLASSPATH
     fi
     

     Note that the CLASSPATH directory name must end with "/".

  For Windows:

  1. Place the keystore.properties file in a directory (for example, c:\keystore\).

  2. Open DOMAIN_HOME\bin\setDomainEnv.cmd.

  3. Towards the end of the file, add the following lines to specify this directory in CLASSPATH.

       if NOT "%CLASSPATH%"=="" (
         set CLASSPATH=%CLASSPATH%;c:\keystore\
       ) else (
         set CLASSPATH=c:\keystore\
       )
     

     Note that the CLASSPATH directory name must end with "\".

• Or, add the keystore.properties file to a .JAR file and place the .JAR file in your DOMAIN_HOME/lib directory. Be sure to also set the system property webservices.soap.custom.crypto.fileName to keystore.properties as described in Section 23.8.1.2.4, "Updating the System Properties for WS-Security."

23.8.1.2.4 Updating the System Properties for WS-Security

This section describes how to add the WS-Security-related properties in your Oracle WebCenter Discussions connection into WebCenter Spaces or your WebCenter application. For information on how to add new properties, see Table 12-4, "Additional Discussion Connection Properties" in Section 12.3.1, "Registering Discussions Servers Using Fusion Middleware Control."

To update your system properties:

1. Log in to the Oracle WebCenter Discussions Administration Console at the following URL:

   http://host:port/owc_discussions/admin

   Where host and port are the address and the port number of the server where you deployed Oracle WebCenter Discussions (for example, http://localhost:7001/owc_discussions).

2. Click System Properties under Forum System to display the Jive Properties page.

3. Modify the system property webservices.soap.custom.crypto.fileName and specify the properties file that you created (i.e., keystore.properties).

   Be sure to specify the name of the file, and not the directory or .JAR name.

4. Click OK.

5. Restart the WLS_Services Managed Server.

23.8.1.2.5 Configuring the Discussions Server Connection Settings

After setting the system properties, your WebCenter application also needs to supply the WS-Security client certificate through the connection settings for Oracle Discussion Forum and Announcement Server as described in Section 12.3, "Registering Discussions Servers." Figure 23-149 shows example settings for the Edit Discussions and Announcement Connection page.

Figure 23-149 Edit Discussions and Announcement Connection Page

Description of "Figure 23-149 Edit Discussions and Announcement Connection Page"

23.8.1.3 Configuring the BPEL Server for a Simple Topology

The BPEL server's Worklist connection must be configured to use message protected SAML service policy. The BPEL server's oracle-webservices.xml file must also be edited so that the server-side SAML policy matches that of the client's policy.

To configure the BPEL server:

1. To configure the Worklist connection on the BPEL server to use the SAML policy with message protection, follow the steps in Section 20.3.2, "Registering Worklist Connections" selecting SAML Token With Message Client Policy in Fusion Middleware Control, or entering oracle/wss10_saml_token_with_message_protection_client_policy as the policy value if using WLST.

2. Use grep to find the strings TaskQueryServicePortSAML and provider-name in all the BPEL server's oracle-webservices.xml files. For example:

   cd <domain home>
   find . | grep webservices.xml | xargs grep TaskQueryServicePortSAML | grep provider-name
   ./servers/BPEL Server 1/tmp/_WL_user/soa-infra/ugh7wb/war/WEB-INF/oracle-webservices.xml: 
   <provider-name>TaskQueryServicePortSAML</provider-name>
   

3. Back up the file. For example:

   cp
   ./servers/BPEL Server 1/tmp/_WL_user/soa-infra/ugh7wb/war/WEB-INF/oracle-webservices.xml
   ./servers/BPEL Server 1/tmp/_WL_user/soa-infra/ugh7wb/war/WEB-INF/oracle-webservices.xml.original
   

4. Edit the file, replacing:

   <policy-reference uri="oracle/wss10_saml_token_service_policy" category="security" enabled="true"/>
   

   with:

   <policy-reference uri="oracle/wss10_saml_token_with_message_protection_service_policy" category="security" enabled="true"/>
   

5. Save the file and restart the Managed Servers. The message protected SAML access is now configured. Examine the managed server diagnostic logs for exception stack information should the worklist service still not work to obtain information about configuration issues.

23.8.2 Configuring WS-Security for a Typical Topology

This section describes how to configure WS-Security for a topology where the WebCenter application and the WSRP producers share the same domain, but the BPEL server is in an external domain - the SOA domain (see Figure 23-150).

Figure 23-150 Typical WS-Security Configuration

Description of "Figure 23-150 Typical WS-Security Configuration"

The steps to configure WS-Security for a typical two domain WebCenter topology are described in the following sections:

• Section 23.8.2.1, "Setting Up the WebCenter Domain Keystore"

• Section 23.8.2.2, "Configuring the Discussions Server for a Typical Topology"

• Section 23.8.3.3, "Setting Up the First SOA Domain"

• Section 23.8.2.4, "Configuring the BPEL Server for a Typical Topology"

23.8.2.1 Setting Up the WebCenter Domain Keystore

The security credentials of a WebCenter application, discussions server, BPEL server (in a separate domain), and WSRP producers can be retrieved and managed using a Java Keystore (JKS). A keystore is a file that provides information about available public and private keys. Keys are used for a variety of purposes, including authentication and data integrity. User certificates and the trust points needed to validate the certificates of peers are also stored securely in the wallet or keystore. See the Oracle Fusion Middleware Security and Administrator's Guide for Web Services for information about JKS.

This section contains the following subsections:

• Section 23.8.2.1.1, "Creating the WebCenter Domain Keystore"

• Section 23.8.2.1.2, "Configuring the Keystore Using WLST"

• Section 23.8.2.1.4, "Unconfiguring a Keystore Provider"

• Section 23.8.2.1.3, "Configuring the Keystore Using Fusion Middleware Control"

23.8.2.1.1 Creating the WebCenter Domain Keystore

This section describes how to create a keystore and keys using a Java Keystore (JKS). JKS is the proprietary keystore format defined by Sun Microsystems. To create and manage the keys and certificates in the JKS, use the keytool utility that is distributed with the Java JDK 6.

To create the WebCenter domain keystore:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, generate a key pair:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias webcenter -keypass key_password -keystore keystore -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the name of the consumer (for example, cn=spaces,dc=example,dc=com)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore is the keystore name, (for example, webcenter.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1064).

     Example 23-6 Generating the Keypair

     keytool -genkeypair -keyalg RSA -dname "cn=spaces,dc=example,dc=com" -alias webcenter -keypass welcome1 -keystore webcenter.jks -storepass welcome1 -validity 1064
     

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

3. Export the certificate containing the public key:

   keytool -exportcert -v -alias orakey -keystore keystore -storepass keystore_password -rfc -file webcenter_public.cer
   

   Where:

   • keystore is the keystore name, (for example, webcenter.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   Example 23-7 Exporting the Certificate Containing the Public Key

   keytool -exportcert -v -alias webcenter -keystore webcenter.jks -storepass welcome1 -rfc -file webcenter_public.cer
   

4. Continue by configuring the keystore using either WLST, as described in Section 23.8.2.1.2, "Configuring the Keystore Using WLST," or Fusion Middleware Control, as described in Section 23.8.2.1.3, "Configuring the Keystore Using Fusion Middleware Control."

   Table 23-24 shows the keystore contents you should wind up with after creating and configuring the keystore.

   Table 23-24 WebCenter Domain Keystore Contents for a Typical Topology

   Key Alias	Description
   webcenter	Key pair used to sign and encrypt outbound messages from WebCenter Spaces. This key is used by both OWSM (Portlets and Worklist) and Discussions.
   orakey	Certificate containing the public key for the BPEL private key used in the SOA domain. The certificate is used to encrypt outbound WebService messages from the Workflow application on BPEL Server1 in the WebCenter domain, to the Worklist service to the SOA server on the SOA domain.

   
   

23.8.2.1.2 Configuring the Keystore Using WLST

After creating the WebCenter domain keystore, configure the keystore service and update the credential store so that OWSM can read the keystore and keys correctly.

To configure the keystore service:

1. Go to the <DOMAIN_HOME>/config/fmwconfig directory, and open the file jps-config.xml in an editor.

2. Locate the <serviceInstance node for the keystore.provider Provider

3. Make sure that the webcenter.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./webcenter.jks.

4. Use the following WLST commands to update the credential store:

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password=keystore_password, desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="webcenter", password=private_key_password, desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="webcenter", password=private_key_password, desc="Signing key")
   

   Where:

   • keystore_password is the keystore password specified in step 2 of Section 23.8.2.1.1, "Creating the WebCenter Domain Keystore," (for example, welcome1)

   • private_key_password is the private key password specified in step 2 of Section 23.8.2.1.1, "Creating the WebCenter Domain Keystore," (for example, welcome1)

   Example 23-8 Updating the Credential Store

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="webcenter", password="welcome1", desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="webcenter", password="welcome1", desc="Signing key")
   

5. Restart all servers.

23.8.2.1.3 Configuring the Keystore Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider as described in Section 23.8.2.1.4, "Unconfiguring a Keystore Provider." Otherwise, continue with the steps below.

To configure the keystore provider:

1. Open Fusion Middleware Control and log into the WebCenter domain.

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

2. In the Navigation pane, expand the WebLogic Domain node and click on the WebCenter domain (webcenter by default).

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

   The Security Provider Configuration page displays (see Figure 23-151).

   Figure 23-151 Security Provider Configuration Page

   
   Description of "Figure 23-151 Security Provider Configuration Page"
   
   

4. Expand the Keystore section on the Security Provider Configuration page.

5. Click Configure.

   The Keystore Configuration page displays (see Figure 23-152).

   Figure 23-152 Keystore Configuration Page

   
   Description of "Figure 23-152 Keystore Configuration Page"
   
   

6. Check Configure Keystore Management and use the following settings to specify the location of the keystore that contains the certificate and private key, and the signature key and encryption key aliases:

   • Keystore Path: ./webcenter.jks

   • Password: Enter and confirm the password for the keystore.

   • Key Alias: webcenter

   • Signature Password: Enter and confirm the password for the signature key.

   • Crypt Alias: webcenter

   • Crypt Password: Enter and confirm the password for the encryption key.

7. Click OK to save your settings.

8. Restart the Administration server for the domain.

23.8.2.1.4 Unconfiguring a Keystore Provider

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider before configuring a new provider. If a keystore provider is not already configured, continue with the steps to configure the keystore in Section 23.8.2.1.3, "Configuring the Keystore Using Fusion Middleware Control."

To unconfigure a keystore provider using Fusion Middleware Control:

1. Open Fusion Middleware Control and log into the target domain.

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

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

   The Security Provider Configuration page displays (see Figure 23-153).

   Figure 23-153 Security Provider Configuration Page

   
   Description of "Figure 23-153 Security Provider Configuration Page"
   
   

3. Expand the Keystore section on the Security Provider Configuration page.

4. Click Configure.

   The Keystore Configuration page displays (see Figure 23-154).

   Figure 23-154 Keystore Configuration Page

   
   Description of "Figure 23-154 Keystore Configuration Page"
   
   

5. Uncheck Configure Keystore Management.

6. Click OK.

23.8.2.2 Configuring the Discussions Server for a Typical Topology

To use Oracle WebCenter Discussions with WebCenter Spaces or custom WebCenter applications, you must enable Web Services Security (WS-Security) trusted authentication. WS-Security establishes a trust relationship between your WebCenter application and Oracle WebCenter Discussions so that the application can pass the user identity information to the discussions server without knowing the user's credentials.

Note:

Discussions-specific Web Services messages sent by WebCenter applications to the Oracle WebCenter Discussions server are not encrypted. For message confidentiality, the Discussions server URL must be accessed over Secure Socket Layer (SSL). For more information, see Section 23.6, "Configuring WebCenter Applications and Components to Use SSL."

This section describes how to add the WS-Security-related properties in your Oracle WebCenter Discussions connection into WebCenter Spaces or your WebCenter application. For information on how to add new properties, see Table 12-4, "Additional Discussion Connection Properties" in Section 12.3.1, "Registering Discussions Servers Using Fusion Middleware Control."

To configure WS-Security on the discussions server side, you must create a keystore certificate properties file, specify it for the ClassLoader, and modify the webservices.soap.custom.crypto.fileName system property.

These configuration steps are described in the following sub-sections:

• Section 23.8.1.2.1, "Importing the WebCenter Domain Certificate"

• Section 23.8.1.2.2, "Creating the Keystore Certificate Properties File"

• Section 23.8.1.2.3, "Specifying the Properties File for ClassLoader"

• Section 23.8.1.2.4, "Updating the System Properties for WS-Security"

23.8.2.2.1 Importing the WebCenter Domain Certificate

Create a keystore by importing the certificate containing public key of the WebCenter domain.

To import the WebCenter domain certificate:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, import the certificate containing the public key of the WebCenter domain:

   keytool -importcert -alias df_webcenter_public -file webcenter_public.cer -keystore owc_discussions.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   • Example 23-9 Importing the WebCenter Domain Certificate

     keytool -importcert -alias df_webcenter_public -file webcenter_public.cer -keystore owc_discussions.jks -storepass welcome1
     

23.8.2.2.2 Creating the Keystore Certificate Properties File

The server-side keystore certificate configuration must be stored in a properties file (keystore.properties) and specified as a system property on the discussions server. The properties file must then be loaded in the ClassLoader for the WS-Secure Handler to pick it up.

To create the properties file:

1. Create a properties file with the following entries:

   org.apache.ws.security.crypto.provider= <Specify your crypto provider (typically org.apache.ws.security.components.crypto.Merlin)>
   org.apache.ws.security.crypto.merlin.keystore.type=jks
   org.apache.ws.security.crypto.merlin.keystore.password=<Specify the keystore password of your server certificate. Note that the password stored in this file is in clear text because of a limitation of the Ws-Security provider WSS4J used in Oracle Discussions Server.>
   org.apache.ws.security.crypto.merlin.keystore.alias=df_orakey_public
   org.apache.ws.security.crypto.merlin.file=<Absolute path of directory containing the keystore (owc_discussions.jks) created above.>
   

2. Save the file as keystore.properties.

23.8.2.2.3 Specifying the Properties File for ClassLoader

There are two ways you can choose to specify your keystore.properties file based on your setup. Using the same file mounted across different servers is recommended when using a Clustered Discussions Server installation in Linux.

To specify the properties file for ClassLoader, do one of the following:

• Specify the properties file as the CLASSPATH in setDomainEnv.sh.

  For Linux:

  1. Place the keystore.properties file in a directory (for example, . /home/user/keystore/)

  2. Open DOMAIN_HOME/bin/setDomainEnv.sh.

  3. Towards the end of the file, add the following lines to specify this directory as the CLASSPATH.

     if [ "${CLASSPATH}" != "" ] ; then
       CLASSPATH="${CLASSPATH}${CLASSPATHSEP}/home/user/keystore/"
       export CLASSPATH
     else
       CLASSPATH="/home/user/keystore/"
       export CLASSPATH
     fi
     

     Note that the CLASSPATH directory name must end with "/".

  For Windows:

  1. Place the keystore.properties file in a directory (for example, c:\keystore\).

  2. Open DOMAIN_HOME\bin\setDomainEnv.cmd.

  3. Towards the end of the file, add the following lines to specify this directory in CLASSPATH.

       if NOT "%CLASSPATH%"=="" (
         set CLASSPATH=%CLASSPATH%;c:\keystore\
       ) else (
         set CLASSPATH=c:\keystore\
       )
     

     Note that the CLASSPATH directory name must end with "\".

• Or, add the keystore.properties file to a .JAR file and place the .JAR file in your DOMAIN_HOME/lib directory. Be sure to also set the system property webservices.soap.custom.crypto.fileName to keystore.properties as described in Section 23.8.2.2.4, "Updating the System Properties for WS-Security."

23.8.2.2.4 Updating the System Properties for WS-Security

To update your system properties:

1. Log in to the Oracle WebCenter Discussions Admin Console at the following URL:

   http://host:port/owc_discussions/admin

   Where host and port are the address and the port number of the server where you deployed Oracle WebCenter Discussions (for example, http://localhost:7001/owc_discussions).

2. Click System Properties under Forum System to display the Jive Properties page.

3. Modify the system property webservices.soap.custom.crypto.fileName and specify the properties file that you created (i.e., keystore.properties).

   Be sure to specify the name of the file, and not the directory or .JAR name.

4. Click OK.

5. Restart the WLS_Services Managed Server.

23.8.2.2.5 Configuring the Discussions Server Connection Settings

After setting the system properties, your WebCenter application also needs to supply the WS-Security client certificate through the connection settings for Oracle Discussion Forum and Announcement Server as described in Section 12.3, "Registering Discussions Servers." Figure 23-155 shows example settings for the Edit Discussions and Announcement Connection page.

Figure 23-155 Edit Discussions and Announcement Connection Page

Description of "Figure 23-155 Edit Discussions and Announcement Connection Page"

23.8.2.3 Setting Up the SOA Domain

This section describes how to set up the SOA domain keystore and contains the following subsections:

• Section 23.8.2.3.1, "Creating the SOA Domain Keystore"

• Section 23.8.2.3.2, "Configuring the Keystore Using WLST"

• Section 23.8.2.3.4, "Unconfiguring a Keystore Provider"

• Section 23.8.2.3.3, "Configuring the Keystore Using Fusion Middleware Control"

23.8.2.3.1 Creating the SOA Domain Keystore

This section describes how to create a SOA domain keystore and keys using a Java Keystore (JKS).

To create the SOA domain keystore:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Create a keystore by importing the public certificate (webcenter_public.cer) from the WebCenter domain:

   keytool -importcert -alias webcenter_spaces_ws -file webcenter_public.cer -keystore bpel.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   • Example 23-10 Importing the Public Certificate

     keytool -importcert -alias webcenter_spaces_ws -file webcenter_public.cer -keystore bpel.jks -storepass welcome1
     

3. Using keytool, create a keypair to be used in the SOA domain for signing and encrypting messages:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias bpel -keypass key_password -keystore keystore -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the name of the consumer (for example, cn=bpel,dc=example,dc=com)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore is the keystore name, (for example, bpel.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1064).

     Example 23-11 Generating the Keypair

     keytool -genkeypair -keyalg RSA -dname "cn=bpel,dc=example,dc=com" -alias bpel -keypass welcome1 -keystore bpel.jks -storepass welcome1 -validity 1064
     

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

4. Export the certificate so it can be imported in the WebCenter domain using the orakey alias:

   keytool -exportcert -v -alias orakey -keystore keystore -storepass keystore_password -rfc -file orakey.cer
   

   Where:

   • keystore is the keystore name, (for example, webcenter.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   Example 23-12 Exporting the Certificate Containing the Public Key

   keytool -exportcert -v -alias bpel -keystore bpel.jks -storepass welcome1 -rfc -file orakay.cer
   

5. Import the certificate with a different alias (choose Yes when prompted whether to overwrite the existing certificate with the alias orakey):

   keytool -importcert -alias orakey -file orakey.cer -keystore webcenter.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password

   Example 23-13 Importing the Certificate

   keytool -importcert -alias orakey -file orakay.cer -keystore webcenter.jks -storepass welcome1
   

23.8.2.3.2 Configuring the Keystore Using WLST

After creating the SOA domain keystore, configure the keystore service and update the credential store so that OWSM can read the keystore and keys correctly.

To configure the keystore service:

1. Go to the <DOMAIN_HOME>/config/fmwconfig directory, and open the file jps-config.xml in an editor.

2. Locate the <serviceInstance node for the keystore.provider Provider

3. Make sure that the bpel.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./bpel.jks.

4. Use the following WLST commands to configure the credential store:

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="bpel", password="welcome1", desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="bpel", password="welcome1", desc="Signing key")
   

5. Restart all servers.

23.8.2.3.3 Configuring the Keystore Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider as described in Section 23.8.2.3.4, "Unconfiguring a Keystore Provider." Otherwise, continue with the steps below.

To configure the keystore provider:

1. Open Fusion Middleware Control and log into the WebCenter domain.

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

2. In the Navigation pane, expand the WebLogic Domain node and click on the WebCenter domain (webcenter by default).

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

4. Expand the Keystore section on the Security Provider Configuration page.

5. Click Configure.

   The Keystore Configuration page displays (see Figure 23-156).

   Figure 23-156 Keystore Configuration Page

   
   Description of "Figure 23-156 Keystore Configuration Page"
   
   

6. Check Configure Keystore Management and use the following settings to specify the location of the keystore that contains the certificate and private key, and the signature key and encryption key aliases:

   • Keystore Path: ./webcenter.jks

   • Password: Enter and confirm the password for the keystore.

   • Key Alias: orakey

   • Signature Password: Enter and confirm the password for the signature key.

   • Crypt Alias: orakey

   • Crypt Password: Enter and confirm the password for the encryption key.

7. Click OK to save your settings.

8. Restart the Administration server for the domain.

23.8.2.3.4 Unconfiguring a Keystore Provider

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider before configuring a new provider. If a keystore provider is not already configured, continue with the steps to configure the keystore in Section 23.8.2.3.3, "Configuring the Keystore Using Fusion Middleware Control."

To unconfigure a keystore provider using Fusion Middleware Control:

1. Open Fusion Middleware Control and log into the target domain.

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

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

3. Expand the Keystore section on the Security Provider Configuration page.

4. Click Configure.

   The Keystore Configuration page displays (see Figure 23-157).

   Figure 23-157 Keystore Configuration Page

   
   Description of "Figure 23-157 Keystore Configuration Page"
   
   

5. Uncheck Configure Keystore Management.

6. Click OK.

23.8.2.4 Configuring the BPEL Server for a Typical Topology

The BPEL server's Worklist connection must be configured to use message protected SAML service policy. The BPEL server's oracle-webservices.xml file must also be edited so that the server-side SAML policy matches that of the client's policy.

To configure the BPEL server:

1. To configure the Worklist connection on the BPEL server to use the SAML policy with message protection, follow the steps in Section 20.3.2, "Registering Worklist Connections," selecting SAML Token With Message Client Policy in Fusion Middleware Control, or entering oracle/wss10_saml_token_with_message_protection_client_policy as the policy value if using WLST.

2. Use grep to find the strings TaskQueryServicePortSAML and provider-name in all the BPEL server's oracle-webservices.xml files. For example:

   cd <domain home>
   find . | grep webservices.xml | xargs grep TaskQueryServicePortSAML | grep provider-name
   ./servers/BPEL Server 1/tmp/_WL_user/soa-infra/ugh7wb/war/WEB-INF/oracle-webservices.xml: 
   <provider-name>TaskQueryServicePortSAML</provider-name>
   

3. Back up the file. For example:

   cp
   ./servers/BPEL Server 1/tmp/_WL_user/soa-infra/ugh7wb/war/WEB-INF/oracle-webservices.xml
   ./servers/BPEL Server 1/tmp/_WL_user/soa-infra/ugh7wb/war/WEB-INF/oracle-webservices.xml.original
   

4. Edit the file, replacing:

   <policy-reference uri="oracle/wss10_saml_token_service_policy" category="security" enabled="true"/>
   

   with:

   <policy-reference uri="oracle/wss10_saml_token_with_message_protection_service_policy" category="security" enabled="true"/>
   

5. Save the file and restart the Managed Servers. The message protected SAML access is now configured. Examine the managed server diagnostic logs for exception stack information should the worklist service still not work to obtain information about configuration issues.

23.8.3 Configuring WS-Security for a Complex Topology

This section describes how to configure WS-Security for a complex topology where the WebCenter application, the discussions server (Jive), and a WSRP producer are in the same domain, two BPEL servers are in separate SOA domains, and one WSRP producer is in an external portlet domain (see Figure 23-158).

Figure 23-158 Complex Configuration

Description of "Figure 23-158 Complex Configuration"

The steps to configure WS-Security for a typical two domain WebCenter topology are described in the following sections:

• Section 23.8.3.1, "Setting Up the WebCenter Domain Keystore"

• Section 23.8.3.2, "Configuring the Discussions Server for a Complex Topology"

• Section 23.8.3.3, "Setting Up the First SOA Domain"

• Section 23.8.3.4, "Setting Up the Second SOA Domain"

• Section 23.8.3.5, "Configuring the BPEL Server for a Complex Topology"

• Section 23.8.3.6, "Setting Up the External Portlet Domain Keystore"

• Section 23.8.3.7, "Setting Up the External WebCenter Domain Keystore"

23.8.3.1 Setting Up the WebCenter Domain Keystore

The security credentials of WebCenter Spaces, discussions server, BPEL servers (in separate domains), and WSRP producers (also in separate domains) can be retrieved and managed using a Java Keystore (JKS). A keystore is a file that provides information about available public and private keys. Keys are used for a variety of purposes, including authentication and data integrity. User certificates and the trust points needed to validate the certificates of peers are also stored securely in the wallet or keystore. See the Oracle Fusion Middleware Security and Administrator's Guide for Web Services for information about JKS.

This section contains the following subsections:

• Section 23.8.3.1.1, "Creating the WebCenter Domain Keystore"

• Section 23.8.3.1.2, "Configuring the Keystore Using WLST"

• Section 23.8.3.1.3, "Configuring the Keystore Using Fusion Middleware Control"

• Section 23.8.3.1.4, "Unconfiguring a Keystore Provider"

23.8.3.1.1 Creating the WebCenter Domain Keystore

This section describes how to create a keystore and keys using a Java Keystore (JKS). JKS is the proprietary keystore format defined by Sun Microsystems. To create and manage the keys and certificates in the JKS, use the keytool utility that is distributed with the Java JDK 6.

To create the WebCenter domain keystore:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, generate a key pair:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias webcenter -keypass key_password -keystore keystore -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the name of the consumer (for example, cn=spaces,dc=example,dc=com)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore is the keystore name, (for example, webcenter.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1064).

     Example 23-14 Generating the Keypair

     keytool -genkeypair -keyalg RSA -dname "cn=spaces,dc=example,dc=com" -alias webcenter -keypass welcome1 -keystore webcenter.jks -storepass welcome1 -validity 1064
     

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

3. Export the certificate containing the public key:

   keytool -exportcert -v -alias webcenter -keystore wecenter.jks -storepass keystore_password -rfc -file webcenter_public.cer
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   Example 23-15 Exporting the Certificate Containing the Public Key

   keytool -exportcert -v -alias webcenter -keystore webcenter.jks -storepass welcome1 -rfc -file webcenter_public.cer
   

4. Continue by configuring the keystore using either WLST, as described in Section 23.8.3.1.2, "Configuring the Keystore Using WLST," or using Fusion Middleware Control, as described in Section 23.8.3.1.3, "Configuring the Keystore Using Fusion Middleware Control."

   Table 23-25 shows the keystore contents you should wind up with after creating and configuring the keystore.

   Table 23-25 WebCenter Domain Keystore Contents for a Complex Topology

   Key Alias	Description
   webcenter	Key pair used to sign and encrypt outbound messages from WebCenter Spaces. This key is used by both OWSM (Portlets and Worklist) and Discussions.
   orakey	Certificate containing the public key for the BPEL private key used in the SOA 1 domain. The certificate is used to encrypt outbound messages from the Worklist service to SOA_Server3 in the SOA 1 domain.
   soa_server3_public_key	Certificate containing the public key for the soa_server3 private key used in the SOA 2 domain. The certificate is used to encrypt outbound messages from the Worklist service to BPEL Server2 in SOA 2 domain.
   producer_public_key	Certificate containing public key for the producer private key used in the external portlet domain that hosts the WSRP Producer 1 application. This certificate is used to encrypt outbound messages from WebCenter Spaces to WSRP Producer 1 registered in the WebCenter Spaces application.
   external_webcenter_custom_public_key	Certificate containing the public key for the external_webcenter_custom private key used in the external WebCenter domain that hosts the custom WebCenter application that makes WebService call to the WebCenter Spaces WebService. This certificate is used to encrypt outbound messages from WebCenter Spaces to custom WebCenter applications in the external WebCenter domain.

   
   

23.8.3.1.2 Configuring the Keystore Using WLST

After creating the WebCenter domain keystore, configure the keystore service and update the credential store so that OWSM can read the keystore and keys correctly.

To configure the keystore service:

1. Go to the <DOMAIN_HOME>/config/fmwconfig directory, and open the file jps-config.xml in an editor.

2. Locate the <serviceInstance node for the keystore.provider Provider

3. Make sure that the webcenter.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./webcenter.jks.

4. Use the following WLST commands to update the credential store:

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="webcenter", password="welcome1", desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="webcenter", password="welcome1", desc="Signing key")
   

5. Restart all servers.

23.8.3.1.3 Configuring the Keystore Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider as described in Section 23.8.3.1.4, "Unconfiguring a Keystore Provider." Otherwise, continue with the steps below.

To configure the keystore provider:

1. Open Fusion Middleware Control and log into the WebCenter domain.

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

2. In the Navigation pane, expand the WebLogic Domain node and click on the WebCenter domain (wc_domain by default).

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

   The Security Provider Configuration page displays (see Figure 23-159).

   Figure 23-159 Security Provider Configuration Page

   
   Description of "Figure 23-159 Security Provider Configuration Page"
   
   

4. Expand the Keystore section on the Security Provider Configuration page.

5. Click Configure.

   The Keystore Configuration page displays (see Figure 23-160).

   Figure 23-160 Keystore Configuration Page

   
   Description of "Figure 23-160 Keystore Configuration Page"
   
   

6. Check Configure Keystore Management and use the following settings to specify the location of the keystore that contains the certificate and private key, and the signature key and encryption key aliases:

   • Keystore Path: ./webcenter.jks

   • Password: Enter and confirm the password for the keystore.

   • Key Alias: webcenter

   • Signature Password: Enter and confirm the password for the signature key.

   • Crypt Alias: webcenter

   • Crypt Password: Enter and confirm the password for the encryption key.

7. Click OK to save your settings.

8. Restart the Administration server for the domain.

23.8.3.1.4 Unconfiguring a Keystore Provider

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider before configuring a new provider. If a keystore provider is not already configured, continue with the steps to configure the keystore in Section 23.8.3.1.3, "Configuring the Keystore Using Fusion Middleware Control."

To unconfigure a keystore provider using Fusion Middleware Control:

1. Open Fusion Middleware Control and log into the target domain.

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

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

   The Security Provider Configuration page displays (see Figure 23-161).

   Figure 23-161 Security Provider Configuration Page

   
   Description of "Figure 23-161 Security Provider Configuration Page"
   
   

3. Expand the Keystore section on the Security Provider Configuration page.

4. Click Configure.

   The Keystore Configuration page displays (see Figure 23-162).

   Figure 23-162 Keystore Configuration Page

   
   Description of "Figure 23-162 Keystore Configuration Page"
   
   

5. Uncheck Configure Keystore Management.

6. Click OK.

23.8.3.2 Configuring the Discussions Server for a Complex Topology

To use the Oracle WebCenter Discussions with WebCenter Spaces or custom WebCenter applications, you must enable Web Services Security (WS-Security) trusted authentication. WS-Security establishes a trust relationship between your WebCenter application and Oracle WebCenter Discussions so that the application can pass the user identity information to the discussions server without knowing the user's credentials.

Note:

Discussions-specific Web Services messages sent by WebCenter applications to the Oracle WebCenter Discussions server are not encrypted. For message confidentiality, the Discussions server URL must be accessed over Secure Socket Layer (SSL). For more information, see Section 23.6, "Configuring WebCenter Applications and Components to Use SSL."

This section describes how to add the WS-Security-related properties in your Oracle WebCenter Discussions connection into WebCenter Spaces or your WebCenter application. For information on how to add new properties, see Table 12-4, "Additional Discussion Connection Properties" in Section 12.3.1, "Registering Discussions Servers Using Fusion Middleware Control."

To configure WS-Security on the discussions server side, you must create a keystore certificate properties file, specify it for the ClassLoader, and modify the webservices.soap.custom.crypto.fileName system property. These configuration steps are described in the following sub-sections:

• Section 23.8.3.2.1, "Importing the WebCenter Domain Certificate"

• Section 23.8.3.2.2, "Creating the Keystore Certificate Properties File"

• Section 23.8.3.2.3, "Specifying the Properties File for ClassLoader"

• Section 23.8.3.2.4, "Updating the System Properties for WS-Security"

23.8.3.2.1 Importing the WebCenter Domain Certificate

Create a keystore by importing the certificate containing public key of the WebCenter domain.

To import the WebCenter domain certificate:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, import the certificate containing the public key of the WebCenter domain:

   keytool -importcert -alias df_orakey_public -file webcenter_public.cer -keystore owc_discussions.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   • Example 23-16 Importing the WebCenter Domain Certificate

     keytool -importcert -alias df_webcenter_public -file webcenter_public.cer -keystore owc_discussions.jks -storepass welcome1
     

23.8.3.2.2 Creating the Keystore Certificate Properties File

The server-side keystore certificate configuration must be stored in a properties file (keystore.properties) and specified as a system property on the discussions server. The properties file must then be loaded in the ClassLoader for the WS-Secure Handler to pick it up.

To create the properties file:

1. Create a properties file with the following entries:

   org.apache.ws.security.crypto.provider= <Specify your crypto provider (typically org.apache.ws.security.components.crypto.Merlin)>
   org.apache.ws.security.crypto.merlin.keystore.type=jks
   org.apache.ws.security.crypto.merlin.keystore.password=<Specify the keystore password of your server certificate. Note that the password stored in this file is in clear text because of a limitation of the Ws-Security provider WSS4J used in Oracle Discussions Server.>
   org.apache.ws.security.crypto.merlin.keystore.alias=df_webcenter_public
   org.apache.ws.security.crypto.merlin.file=<Absolute path of directory containing the keystore created above.> 
   

2. Save the file as keystore.properties.

23.8.3.2.3 Specifying the Properties File for ClassLoader

There are two ways you can choose to specify your keystore.properties file based on your setup. Using the same file mounted across different servers is recommended when using a Clustered Discussions Server installation in Linux.

To specify the properties file for ClassLoader, do one of the following:

• Specify the properties file as the CLASSPATH in setDomainEnv.sh.

  For Linux:

  1. Place the keystore.properties file in a directory (for example, . /home/user/keystore/)

  2. Open DOMAIN_HOME/bin/setDomainEnv.sh.

  3. Towards the end of the file, add the following lines to specify this directory as the CLASSPATH.

     if [ "${CLASSPATH}" != "" ] ; then
       CLASSPATH="${CLASSPATH}${CLASSPATHSEP}/home/user/keystore/"
       export CLASSPATH
     else
       CLASSPATH="/home/user/keystore/"
       export CLASSPATH
     fi
     

     Note that the CLASSPATH directory name must end with "/".

  For Windows:

  1. Place the keystore.properties file in a directory (for example, c:\keystore\).

  2. Open DOMAIN_HOME\bin\setDomainEnv.cmd.

  3. Towards the end of the file, add the following lines to specify this directory in CLASSPATH.

       if NOT "%CLASSPATH%"=="" (
         set CLASSPATH=%CLASSPATH%;c:\keystore\
       ) else (
         set CLASSPATH=c:\keystore\
       )
     

     Note that the CLASSPATH directory name must end with "\".

• Or, add the keystore.properties file to a .JAR file and place the .JAR file in your DOMAIN_HOME/lib directory. Be sure to also set the system property webservices.soap.custom.crypto.fileName to keystore.properties as described in Section 23.8.3.2.4, "Updating the System Properties for WS-Security."

23.8.3.2.4 Updating the System Properties for WS-Security

To update your system properties:

1. Log in to the Oracle WebCenter Discussions Administration Console at the following URL:

   http://host:port/owc_discussions/admin

   Where host and port are the address and the port number of the server where you deployed Oracle WebCenter Discussions (for example, http://localhost:7001/owc_discussions).

2. Click System Properties under Forum System to display the Jive Properties page.

3. Modify the system property webservices.soap.custom.crypto.fileName and specify the properties file that you created (i.e., keystore.properties).

   Be sure to specify the name of the file, and not the directory or .JAR name.

4. Click OK.

5. Restart the WLS_Services Managed Server.

23.8.3.2.5 Configuring the Discussions Server Connection Settings

After setting the system properties, your WebCenter application also needs to supply the WS-Security client certificate through the connection settings for Oracle Discussion Forum and Announcement Server as described in Section 12.3, "Registering Discussions Servers." Figure 23-163 shows example settings for the Edit Discussions and Announcement Connection page.

Figure 23-163 Edit Discussions and Announcement Connection Page

Description of "Figure 23-163 Edit Discussions and Announcement Connection Page"

23.8.3.3 Setting Up the First SOA Domain

This section describes how to set up the SOA domain keystore and contains the following subsections:

• Section 23.8.3.3.1, "Creating the SOA Domain Keystore"

• Section 23.8.3.3.2, "Configuring the Keystore Using WLST"

• Section 23.8.3.3.3, "Configuring the Keystore Using Fusion Middleware Control"

• Section 23.8.3.3.4, "Unconfiguring a Keystore Provider"

23.8.3.3.1 Creating the SOA Domain Keystore

This section describes how to create a SOA domain keystore and keys using a Java Keystore (JKS).

To create the SOA domain keystore:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Create a keystore by importing the public certificate (webcenter_public.cer) from the WebCenter domain:

   keytool -importcert -alias webcenter_spaces_ws -file webcenter_public.cer -keystore bpel.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   • Example 23-17 Importing the Public Certificate

     keytool -importcert -alias webcenter_spaces_ws -file webcenter_public.cer -keystore bpel.jks -storepass welcome1
     

3. Using keytool, create a keypair to be used in the SOA domain for signing and encrypting messages:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias bpel -keypass key_password -keystore bpel.jks -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the name of the consumer (for example, cn=bpel,dc=example,dc=com)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1064).

     Example 23-18 Generating the Keypair

     keytool -genkeypair -keyalg RSA -dname "cn=bpel,dc=example,dc=com" -alias bpel -keypass welcome1 -keystore bpel.jks -storepass welcome1 -validity 1064
     

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

4. Export the certificate so it can be imported in the WebCenter domain using the orakey alias:

   keytool -exportcert -v -alias bpel -keystore bpel.jks -storepass keystore_password -rfc -file orakey.cer
   

   Where:

   • keystore_password is the keystore password (for example, welcome1)

   Example 23-19 Exporting the Certificate Containing the Public Key

   keytool -exportcert -v -alias bpel -keystore bpel.jks -storepass welcome1 -rfc -file orakay.cer
   

5. Import the certificate to the WebCenter domain again with a different alias (choose Yes when prompted whether to overwrite the existing certificate with the alias orakey):

   keytool -importcert -alias orakey -file orakey.cer -keystore webcenter.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password (for example, welcome1)

   Example 23-20 Importing the Certificate

   keytool -importcert -alias orakey -file orakay.cer -keystore webcenter.jks -storepass welcome1
   

6. Continue by configuring the keystore using either WLST as described in Section 23.8.3.3.2, "Configuring the Keystore Using WLST,", or using Fusion Middleware Control as described in Section 23.8.3.3.3, "Configuring the Keystore Using Fusion Middleware Control."

   Table 23-26 shows the keystore contents you should wind up with after creating and configuring the SOA 1 domain keystore.

   Table 23-26 SOA 1 Domain Keystore Contents for a Complex Topology

   Key Alias	Description
   bpel	Private key used to sign outbound messages from the SOA 1 domain servers. This key is used by the Worklist application deployed on the SOA 1 domain's SOA server.
   webcenter_spaces_ws	Certificate containing the public key for the webcenter private key used in the WebCenter domain. The certificate is used to encrypt outbound Workflow messages on BPEL Server1 in the SOA 1 domain to WebService APIs on the Spaces domain.

   
   

23.8.3.3.2 Configuring the Keystore Using WLST

After creating the SOA domain keystore, configure the keystore service and update the credential store so that OWSM can read the keystore and keys correctly.

To configure the keystore service:

1. Go to the <DOMAIN_HOME>/config/fmwconfig directory, and open the file jps-config.xml in an editor.

2. Locate the <serviceInstance node for the keystore.provider Provider

3. Make sure that the bpel.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./bpel.jks.

4. Use the following WLST commands to update the credential store:

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="bpel", password="welcome1", desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="bpel", password="welcome1", desc="Signing key")
   

5. Restart all servers.

23.8.3.3.3 Configuring the Keystore Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider as described in Section 23.8.3.3.4, "Unconfiguring a Keystore Provider." Otherwise, continue with the steps below.

To configure the keystore provider:

1. Open Fusion Middleware Control and log into the WebCenter domain.

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

2. In the Navigation pane, expand the WebLogic Domain node and click on the SOA domain.

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

4. Expand the Keystore section on the Security Provider Configuration page.

5. Click Configure.

   The Keystore Configuration page displays (see Figure 23-164).

   Figure 23-164 Keystore Configuration Page

   
   Description of "Figure 23-164 Keystore Configuration Page"
   
   

6. Check Configure Keystore Management and use the following settings to specify the location of the keystore that contains the certificate and private key, and the signature key and encryption key aliases:

   • Keystore Path: ./bpel.jks

   • Password: Enter and confirm the password for the keystore.

   • Key Alias: bpel

   • Signature Password: Enter and confirm the password for the signature key.

   • Crypt Alias: bpel

   • Crypt Password: Enter and confirm the password for the encryption key.

7. Click OK to save your settings.

8. Restart the Administration server for the domain.

23.8.3.3.4 Unconfiguring a Keystore Provider

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider before configuring a new provider. If a keystore provider is not already configured, continue with the steps to configure the keystore in Section 23.8.3.3.3, "Configuring the Keystore Using Fusion Middleware Control."

To unconfigure a keystore provider using Fusion Middleware Control:

1. Open Fusion Middleware Control and log into the target domain.

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

2. From the SOA Domain menu, select Security -> Security Provider Configuration.

3. Expand the Keystore section on the Security Provider Configuration page.

4. Click Configure.

   The Keystore Configuration page displays (see Figure 23-165).

   Figure 23-165 Keystore Configuration Page

   
   Description of "Figure 23-165 Keystore Configuration Page"
   
   

5. Uncheck Configure Keystore Management.

6. Click OK.

23.8.3.4 Setting Up the Second SOA Domain

This section describes how to set up a second SOA domain keystore and contains the following subsections:

• Section 23.8.3.4.1, "Creating the SOA Domain Keystore"

• Section 23.8.3.4.2, "Configuring the Keystore Using WLST"

• Section 23.8.3.4.3, "Configuring the Keystore Using Fusion Middleware Control"

• Section 23.8.3.4.4, "Unconfiguring a Keystore Provider"

23.8.3.4.1 Creating the SOA Domain Keystore

This section describes how to create a SOA domain keystore and keys using a Java Keystore (JKS).

To create the SOA domain keystore:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, create a keypair to be used in the SOA domain for signing and encrypting messages:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias soa_server3 -keypass key_password -keystore soa_server3.jks -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the name of the consumer (for example, cn=soa_server3,dc=example,dc=com)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1064).

     Example 23-21 Generating the Keypair

     keytool -genkeypair -keyalg RSA -dname "cn=soa_server3,dc=example,dc=com" -alias soa_server3 -keypass welcome1 -keystore soa_server3.jks -storepass welcome1 -validity 1064
     

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

3. Export the certificate so it can be imported in the WebCenter domain using the orakey alias:

   keytool -exportcert -v -alias soa_server3 -keystore soa_server3.jks -storepass keystore_password -rfc -file soa_server3_public_key.cer
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   Example 23-22 Exporting the Certificate Containing the Public Key

   keytool -exportcert -v -alias soa_server3 -keystore soa_server3.jks -storepass welcome1 -rfc -file soa_server3_public_key.cer
   

4. Import the certificate to the WebCenter domain with a different alias (choose Yes when prompted whether to overwrite the existing certificate with the alias soa_server3_public_key):

   keytool -importcert -alias soa_server3_public_key -file soa_server3_public_key.cer -keystore webcenter.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password (for example, welcome1)

   Example 23-23 Importing the Certificate

   keytool -importcert -alias soa_server3_public_key -file soa_server3_public_key.cer -keystore webcenter.jks -storepass welcome1
   

5. Continue by configuring the keystore using either WLST as described in Section 23.8.3.4.2, "Configuring the Keystore Using WLST,", or using Fusion Middleware Control as described in Section 23.8.3.4.3, "Configuring the Keystore Using Fusion Middleware Control."

   Table 23-27 shows the keystore contents you should wind up with after creating and configuring the SOA 2 domain keystore.

   Table 23-27 SOA 2 Domain Keystore Contents for a Complex Topology

   Key Alias	Description
   webcenter	Key pair used to sign and encrypt outbound messages from WebCenter Spaces. This key is used by both OWSM (Portlets and Worklist) and Discussions.
   orakey	Certificate containing the public key for the BPEL private key used in the SOA 1 domain. The certificate is used to encrypt outbound messages from the Worklist service to SOA_Server3 in the SOA 1 domain.
   soa_server3_public_key	Certificate containing the public key for the soa_server3 private key used in the SOA 2 domain. The certificate is used to encrypt outbound messages from the Worklist service to BPEL Server2 in SOA 2 domain.
   producer_public_key	Certificate containing public key for the producer private key used in the external portlet domain that hosts the WSRP Producer 1 application. This certificate is used to encrypt outbound messages from WebCenter Spaces to WSRP Producer 1 registered in the WebCenter Spaces application.
   external_webcenter_custom_public_key	Certificate containing the public key for the external_webcenter_custom private key used in the external WebCenter domain that hosts the custom WebCenter application that makes WebService call to the WebCenter Spaces WebService. This certificate is used to encrypt outbound messages from WebCenter Spaces to custom WebCenter applications in the external WebCenter domain.

   
   

23.8.3.4.2 Configuring the Keystore Using WLST

After creating the second SOA domain keystore, configure the keystore service and update the credential store so that OWSM can read the keystore and keys correctly.

To configure the keystore service:

1. Go to the <DOMAIN_HOME>/config/fmwconfig directory, and open the file jps-config.xml in an editor.

2. Locate the <serviceInstance node for the keystore.provider Provider

3. Make sure that the soa_server3.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./soa_server3.jks.

4. Use the following WLST commands to update the credential store:

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="soa_server3", password="welcome1", desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="soa_server3", password="welcome1", desc="Signing key")
   

5. Restart all servers.

23.8.3.4.3 Configuring the Keystore Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider as described in Section 23.8.3.4.4, "Unconfiguring a Keystore Provider." Otherwise, continue with the steps below.

To configure the keystore provider:

1. Open Fusion Middleware Control and log into the WebCenter domain.

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

2. In the Navigation pane, expand the WebLogic Domain node and click on the SOA domain.

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

4. Expand the Keystore section on the Security Provider Configuration page.

5. Click Configure.

   The Keystore Configuration page displays (see Figure 23-166).

   Figure 23-166 Keystore Configuration Page

   
   Description of "Figure 23-166 Keystore Configuration Page"
   
   

6. Check Configure Keystore Management and use the following settings to specify the location of the keystore that contains the certificate and private key, and the signature key and encryption key aliases:

   • Keystore Path: ./soa_server3.jks

   • Password: Enter and confirm the password for the keystore.

   • Key Alias: soa_server3

   • Signature Password: Enter and confirm the password for the signature key.

   • Crypt Alias: soa_server3

   • Crypt Password: Enter and confirm the password for the encryption key.

7. Click OK to save your settings.

8. Restart the Administration server for the domain.

23.8.3.4.4 Unconfiguring a Keystore Provider

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider before configuring a new provider. If a keystore provider is not already configured, continue with the steps to configure the keystore in Section 23.8.3.4.3, "Configuring the Keystore Using Fusion Middleware Control."

To unconfigure a keystore provider using Fusion Middleware Control:

1. Open Fusion Middleware Control and log into the target domain.

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

2. From the SOA Domain menu, select Security -> Security Provider Configuration.

3. Expand the Keystore section on the Security Provider Configuration page.

4. Click Configure.

   The Keystore Configuration page displays (see Figure 23-167).

   Figure 23-167 Keystore Configuration Page

   
   Description of "Figure 23-167 Keystore Configuration Page"
   
   

5. Uncheck Configure Keystore Management.

6. Click OK.

23.8.3.5 Configuring the BPEL Server for a Complex Topology

WebCenter Spaces Worklist connections use oracle/wss10_saml_token_with_message_protection_client_policy as the secure OWSM policy for generating outbound SOAP messages to the SOA server. However, by default, this policy uses orakey to encrypt outbound messages.

When the WebCenter domain (where WebCenter Spaces is installed) is configured to use two or more Worklist connections simultaneously, and those connections use a secure message propagation OWSM policy, an additional OWSM policy must be created. This policy must be configured so that the recipient key alias matches the alias by which the certificate of the intended SOA server is stored on the WebCenter Spaces side.

The following steps are required to use more than one external SOA Domain configuration simultaneously on the WebCenter Spaces server:

1. Export the certificate from the external SOA domain and import it into the WebCenter domain under a specific alias (soa_server3_key in the following example).

2. Use Fusion Middleware Control to create a new OWSM policy, and override the recipient key alias to use the same alias as in step 1 above.

3. Create a BPEL connection and use WLST to set the security policy to the policy created in step 2 above.

The following steps show how to carry out steps 2 and 3 above. Note that the keystore should already have been created in Section 23.8.3.4, "Setting Up the Second SOA Domain."

To configure the BPEL server for multiple Worklist connections:

1. Create a new OWSM security policy and register the new policy in WebCenter Spaces using Fusion Middleware Control.

   1. Open Fusion Middleware Control and log into the target domain.

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

   2. From the WebLogic Domain menu, select Web Services > Policies.

      The Web Services Policies page displays (see Figure 23-168).

      Figure 23-168 Web Services Policies Page

      
      Description of "Figure 23-168 Web Services Policies Page"
      
      

   3. Select a client policy to use as a base for creating a new policy and click Create Like.

      The Create Policy page displays (see Figure 23-169).

      Figure 23-169 Create Policy Page

      
      Description of "Figure 23-169 Create Policy Page"
      
      

   4. Name the policy oracle_wss10_saml_token_with_message_protection_client_policy_soa_server3.

   5. On the Configuration tab, select the row for recipient.key.alias and click Edit.

   6. Enter soa_server3_key as the Value and click OK.

   7. On the Create Policy page, click Save. The new policy should now be listed on the Web Services Policies page.

2. Create a BPEL connection that uses the new security policy with the following WLST command:

   setBPELConnection(appName='webcenter', name='WebCenter-Worklist-SOAServer3',url='<your_url>', policy='oracle/wss10_saml_token_with_message_protection_client_policy_soa_server3')
   

23.8.3.6 Setting Up the External Portlet Domain Keystore

This section describes how to set up the keystore for the external portlet domain used by one of the WSRP producers for this complex topology.

This section contains the following subsections:

• Section 23.8.3.6.1, "Creating the External Portlet Domain Keystore"

• Section 23.8.3.6.2, "Configuring the Keystore Using WLST"

• Section 23.8.3.6.3, "Configuring the Keystore Using Fusion Middleware Control"

• Section 23.8.3.6.4, "Unconfiguring a Keystore Provider"

23.8.3.6.1 Creating the External Portlet Domain Keystore

To create the external portlet domain keystore:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, generate the keystore by importing the WebCenter domain's public certificate:

   keytool -importcert -alias webcenter_public -file webcenter_public.cer -keystore producer.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password

   Example 23-24 Importing the Certificate

   keytool -importcert -alias webcenter_public -file webcenter_public.cer -keystore producer.jks -storepass welcome1
   

3. Using keytool, generate a key pair:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias producer -keypass key_password -keystore producer.jks -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the name of the consumer (for example, cn=producer,dc=example,dc=com)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore is the keystore name, (for example, webcenter.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1064).

     Example 23-25 Generating the Keypair

     keytool -genkeypair -keyalg RSA -dname "cn=producer,dc=example,dc=com" -alias producer -keypass welcome1 -keystore producer.jks -storepass welcome1 -validity 1064
     

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

4. Export the certificate containing the public key so that it can be imported into the WebCenter Spaces domain's keystore:

   keytool -exportcert -v -alias producer -keystore producer.jks -storepass keystore_password -rfc -file producer_public_key.cer
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   Example 23-26 Exporting the Certificate Containing the Public Key

   keytool -exportcert -v -alias producer -keystore producer.jks -storepass welcome1 -rfc -file producer_public_key.cer
   

5. Import the certificate to the WebCenter domain with a different alias (choose Yes when prompted whether to overwrite the existing certificate with the alias producer_public_key):

   keytool -importcert -alias producer_public_key -file producer_public_key.cer -keystore webcenter.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password (for example, welcome1)

   Example 23-27 Importing the Certificate

   keytool -importcert -alias producer_public_key -file producer_public_key.cer -keystore webcenter.jks -storepass welcome1
   

6. Continue by configuring the keystore using either WLST as described in Section 23.8.3.6.2, "Configuring the Keystore Using WLST,", or using Fusion Middleware Control as described in Section 23.8.3.6.3, "Configuring the Keystore Using Fusion Middleware Control."

23.8.3.6.2 Configuring the Keystore Using WLST

After creating the external portlet domain keystore, configure the keystore service and update the credential store so that OWSM can read the keystore and keys correctly.

To configure the keystore service:

1. Go to the <DOMAIN_HOME>/config/fmwconfig directory, and open the file jps-config.xml in an editor.

2. Locate the <serviceInstance node for the keystore.provider Provider

3. Make sure that the producer.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./producer.jks.

4. Use the following WLST commands to update the credential store:

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="producer", password="welcome1", desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="producer", password="welcome1", desc="Signing key")
   

5. Restart all servers.

23.8.3.6.3 Configuring the Keystore Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider as described in Section 23.8.3.6.4, "Unconfiguring a Keystore Provider." Otherwise, continue with the steps below.

To configure the keystore provider:

1. Open Fusion Middleware Control and log into the WebCenter domain.

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

2. In the Navigation pane, expand the WebLogic Domain node and click on the WebCenter domain (webcenter by default).

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

4. Expand the Keystore section on the Security Provider Configuration page.

5. Click Configure.

   The Keystore Configuration page displays (see Figure 23-170).

   Figure 23-170 Keystore Configuration Page

   
   Description of "Figure 23-170 Keystore Configuration Page"
   
   

6. Check Configure Keystore Management and use the following settings to specify the location of the keystore that contains the certificate and private key, and the signature key and encryption key aliases:

   • Keystore Path: ./producer.jks

   • Password: Enter and confirm the password for the keystore.

   • Key Alias: producer

   • Signature Password: Enter and confirm the password for the signature key.

   • Crypt Alias: producer

   • Crypt Password: Enter and confirm the password for the encryption key.

7. Click OK to save your settings.

8. Restart the Administration server for the domain.

23.8.3.6.4 Unconfiguring a Keystore Provider

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider before configuring a new provider. If a keystore provider is not already configured, continue with the steps to configure the keystore in Section 23.8.3.6.3, "Configuring the Keystore Using Fusion Middleware Control."

To unconfigure a keystore provider using Fusion Middleware Control:

1. Open Fusion Middleware Control and log into the target domain.

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

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

   The Security Provider Configuration page displays (see Figure 23-171).

   Figure 23-171 Security Provider Configuration Page

   
   Description of "Figure 23-171 Security Provider Configuration Page"
   
   

3. Expand the Keystore section on the Security Provider Configuration page.

4. Click Configure.

   The Keystore Configuration page displays (see Figure 23-172).

   Figure 23-172 Keystore Configuration Page

   
   Description of "Figure 23-172 Keystore Configuration Page"
   
   

5. Uncheck Configure Keystore Management.

6. Click OK.

23.8.3.7 Setting Up the External WebCenter Domain Keystore

This section describes how to set up an external WebCenter domain used by a custom WebCenter application making WebCenter Spaces WebService calls.

This section contains the following subsections:

• Section 23.8.3.7.1, "Creating the External WebCenter Domain Keystore"

• Section 23.8.3.7.2, "Configuring the Keystore Using WLST"

• Section 23.8.3.7.3, "Configuring the Keystore Using Fusion Middleware Control"

• Section 23.8.3.7.4, "Unconfiguring a Keystore Provider"

23.8.3.7.1 Creating the External WebCenter Domain Keystore

To create the external WebCenter domain keystore:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, generate the keystore by importing the WebCenter domain's public certificate:

   keytool -importcert -alias webcenter_public -file webcenter_public.cer -keystore external_webcenter_custom.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password

   Example 23-28 Importing the Certificate

   keytool -importcert -alias webcenter_public -file webcenter_public.cer -keystore external_webcenter_custom.jks -storepass welcome1
   

3. Using keytool, generate a key pair:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias external_webcenter_custom -keypass key_password -keystore external_webcenter_custom.jks -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the name of the consumer (for example, cn=external_webcenter_custom,dc=example,dc=com)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1064).

     Example 23-29 Generating the Keypair

     keytool -genkeypair -keyalg RSA -dname "cn=external_webcenter_custom,dc=example,dc=com" -alias external_webcenter_custom -keypass welcome1 -keystore external_webcenter_custom.jks -storepass welcome1 -validity 1064
     

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

4. Export the certificate containing the public key so that it can be imported into the WebCenter Spaces domain's keystore:

   keytool -exportcert -v -alias external_webcenter_custom -keystore external_webcenter_custom.jks -storepass keystore_password -rfc -file external_webcenter_custom_public_key.cer
   

   Where:

   • keystore_password is the keystore password, (for example, welcome1)

   Example 23-30 Exporting the Certificate Containing the Public Key

   keytool -exportcert -v -alias external_webcenter_custom -keystore external_webcenter_custom.jks -storepass welcome1 -rfc -file external_webcenter_custom_public_key.cer
   

5. Import the certificate to the WebCenter domain with a different alias (choose Yes when prompted whether to overwrite the existing certificate with the alias external_webcenter_custom_public_key):

   keytool -importcert -alias external_webcenter_custom_public_key -file external_webcenter_custom_public_key.cer -keystore webcenter.jks -storepass keystore_password
   

   Where:

   • keystore_password is the keystore password (for example, welcome1)

   Example 23-31 Importing the Certificate

   keytool -importcert -alias external_webcenter_custom_public_key -file external_webcenter_custom_public_key.cer -keystore webcenter.jks -storepass welcome1
   

6. Continue by configuring the keystore using either WLST as described in Section 23.8.3.7.2, "Configuring the Keystore Using WLST,", or using Fusion Middleware Control as described in Section 23.8.3.7.3, "Configuring the Keystore Using Fusion Middleware Control."

23.8.3.7.2 Configuring the Keystore Using WLST

After creating the external WebCenter domain keystore, configure the keystore service and update the credential store so that OWSM can read the keystore and keys correctly.

To configure the keystore service:

1. Go to the <DOMAIN_HOME>/config/fmwconfig directory, and open the file jps-config.xml in an editor.

2. Locate the <serviceInstance node for the keystore.provider Provider

3. Make sure that the webcenter.jks keystore file is copied to the <DOMAIN_HOME>/config/fmwconfig directory, and then specify the location as ./webcenter.jks.

4. Use the following WLST commands to update the credential store:

   createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
   createCred(map="oracle.wsm.security", key="enc-csf-key", user="external_webcenter_custom", password="welcome1", desc="Encryption key")
   createCred(map="oracle.wsm.security", key="sign-csf-key", user="external_webcenter_custom", password="welcome1", desc="Signing key")
   

5. Restart all servers.

23.8.3.7.3 Configuring the Keystore Using Fusion Middleware Control

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider as described in Section 23.8.3.7.4, "Unconfiguring a Keystore Provider." Otherwise, continue with the steps below.

To configure the keystore provider:

1. Open Fusion Middleware Control and log into the WebCenter domain.

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

2. In the Navigation pane, expand the WebLogic Domain node and click on the WebCenter domain (webcenter by default).

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

4. Expand the Keystore section on the Security Provider Configuration page.

5. Click Configure.

   The Keystore Configuration page displays (see Figure 23-173).

   Figure 23-173 Keystore Configuration Page

   
   Description of "Figure 23-173 Keystore Configuration Page"
   
   

6. Check Configure Keystore Management and use the following settings to specify the location of the keystore that contains the certificate and private key, and the signature key and encryption key aliases:

   • Keystore Path: ./external_webcenter_custom.jks

   • Password: Enter and confirm the password for the keystore.

   • Key Alias: external_webcenter_custom

   • Signature Password: Enter and confirm the password for the signature key.

   • Crypt Alias: external_webcenter_custom

   • Crypt Password: Enter and confirm the password for the encryption key.

7. Click OK to save your settings.

8. Restart the Administration server for the domain.

23.8.3.7.4 Unconfiguring a Keystore Provider

If a keystore provider is already configured, you will first need to unconfigure the existing keystore provider before configuring a new provider. If a keystore provider is not already configured, continue with the steps to configure the keystore in Section 23.8.3.7.3, "Configuring the Keystore Using Fusion Middleware Control."

To unconfigure a keystore provider using Fusion Middleware Control:

1. Open Fusion Middleware Control and log into the target domain.

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

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

3. Expand the Keystore section on the Security Provider Configuration page.

4. Click Configure.

   The Keystore Configuration page displays (see Figure 23-174).

   Figure 23-174 Keystore Configuration Page

   
   Description of "Figure 23-174 Keystore Configuration Page"
   
   

5. Uncheck Configure Keystore Management.

6. Click OK.

23.8.3.7.5 Calling WebCenter Spaces WebServices

In your client project, where you are setting up the GroupSpaceWSContext, set the recipient key alias to be the same as the WebCenter Spaces certificate alias as shown below:

GroupSpaceWSContext context = new GroupSpaceWSContext();
context.setRecipientKeyAlias("webcenter_public");

23.8.4 Securing Oracle WebLogic Communication Services (OWLCS) with WS-Security

Follow the steps below to configure WS-Security for Oracle WebLogic Communication Services (OWLCS):

1. Provide the policyURI when creating the Instant Messaging and Presence (IMP) connection.

   When you create the connection to the WS-Security enabled OWLCS server, you must provide the policyURI. The value of policyURI should be set to oracle/wss11_saml_token_with_message_protection_client_policy. If no policyURI is supplied, the application will use a non-secure connection. See also Section 14.1, "What You Should Know About Instant Messaging and Presence Connections."

2. Supply an alias name for the private key to the IMP connection.

   Provide an additional property in the WebCenter IMP connection named recipient.alias. Set the value of this property to the alias under which to import the OWLCS certificate. Ensure that this value is unique and is not used already by some other service. If no alias name is supplied, the application uses the default value webcenter_owlcs. See also Section 14.3, "Registering Instant Messaging and Presence Servers."

3. Determine the private key in the OWLCS keystore (located on the OWLCS instance at DOMAIN_HOME/config/fmwconfig).

   Use the following command to list the keystore contents:

   keytool -list -v -keystore Serversidekeystore.jks -storepass password
   

   Find the entry with the Entry type set to keyEntry. The alias name of this entry is the private key (orakey by default).

4. Export the private key from the OWLCS server keystore.

   Use the following command to export orakey to a certificate file (for example, orakey.cer).

   keytool -exportcert -v -alias orakey -keystore Serversidekeystore.jks
   -storepass welcome -rfc -file orakey.cer
   

5. Determine the private key in the WebCenter keystore (on the WebCenter instance at DOMAIN_HOME/config/fmwconfig).

   If no keystore is found, proceed to step 6. Otherwise, use the following command to list the keystore contents:

   keytool -list -v -keystore default-keystore.jks -storepass welcome
   

   Find the entry with Entry type set to keyEntry or PrivateKeyEntry. The alias name of this entry is the private key.

   If no such entry is found, proceed to step 6. Otherwise, continue at step 7.

6. Generate a private key on WebCenter.

   Go to DOMAIN_HOME/config/fmwconfig in your WebCenter installation and run the following command to add a key pair to the keystore. The command creates a keystore named default-keystore.jks if it doesn't already exist, and adds a new private key entry with alias orasig and the password set to welcome1. You can optionally change the alias, password and domain name command when you run the command.

   keytool -genkeypair -keyalg RSA -dname "cn=consumer,dc=example,dc=com" -alias orasig -keypass welcome1 -keystore default-keystore.jks -storepass welcome1 -validity 360
   

7. Configure OWLCS on your WebCenter instance to use the private key.

   Run the WLST createCred command substituting the values for user and password in the first two commands with your private key alias and password.

   createCred(map='oracle.wsm.security', key='enc-csf-key', user='orasig', password='welcome1', desc='EncryptionKey')
   
   createCred(map='oracle.wsm.security', key='sign-csf-key', user='orasig', password='welcome1', desc='SigningKey')
   
   createCred(map='oracle.wsm.security', key='keystore-csf-key', user='owsm', password='welcome1', desc='KeystoreKey')
   

8. Export the private key pair to a certificate.

   Export the private key found in step 5 or created in step 6 to a certificate file using the following command:

   keytool -exportcert -v -alias orasig -keystore default-keystore.jks -storepass welcome1 -rfc -file orasig.cer
   

9. Import the certificate generated on the OWLCS Server to the WebCenter keystore.

   Copy the certificate generated in step 4 to a temporary location on the WebCenter instance. Import the certificate in the WebCenter instance using the alias name from step 2.

   Use the following command to import the certificate in the WebCenter keystore:

   keytool -importcert -alias webcenter_owlcs -file orakey.cer -keystore default-keystore.jks -storepass welcome1 
   

10. Import the WebCenter certificate on the OWLCS instance.

    Copy the certificate created in step 8 to a temporary location on the OWLCS instance. Go to DOMAIN_HOME/config/fmwconfig and import the certificate in the keystore under a meaningful alias (for example, webcenter_key) using the following command:

    keytool -importcert -alias webcenter_key -file orasig.cer -keystore Serversidekeystore.jks -storepass welcome
    

23.8.5 Securing a WSRP Producer with WS-Security

The following sections describe how to secure access to JSR-168 standards-based WSRP portlets from WebCenter applications:

• Section 23.8.5.1, "Deploying the Producer"

• Section 23.8.5.2, "Attaching a Policy to the Producer Endpoint"

• Section 23.8.5.3, "Setting Up the Keystores"

For a conceptual overview of securing WSRP producers, see "Securing Identity Propagation Through WSRP Producers with WS-Security" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

23.8.5.1 Deploying the Producer

Before you configure the producer for WS-Security, you must first deploy your standards-compliant portlet producer to an Oracle WebLogic managed server by performing the steps described in Section 21.8, "Deploying Portlet Producer Applications."

23.8.5.2 Attaching a Policy to the Producer Endpoint

This section describes how to attach a security policy to a WSRP producer endpoint. The following policies are supported for WSRP producers:

• Username token with password

  wss10_username_token_with_message_protection_service_policy

  This policy enforces message-level protection (message integrity and confidentiality) and authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard. It uses WS-Security's Basic 128 suite of asymmetric key technologies (specifically, RSA key mechanism for message confidentiality, SHA-1 hashing algorithm for message integrity, and AES-128 bit encryption). The keystore is configured through the security configuration. Authentication is enforced using credentials in the WS-Security UsernameToken SOAP header. The Subject is established against the currently configured identity store.

• Username token without password

  wss10_username_id_propagation_with_msg_protection_service_policy

  This policy enforces message level protection (message integrity and confidentiality) and identity propagation for inbound SOAP requests using mechanisms described by the WS-Security 1.0 standard. Message protection is provided using WS-Security's Basic 128 suite of asymmetric key technologies (specifically, RSA key mechanisms for confidentiality, SHA-1 hashing algorithm for integrity, and AES-128 bit encryption). Identity is set using the user name provided by the UsernameToken WS-Security SOAP header. The Subject is established against the currently configured identity store.

• SAML token

  There are four SAML token policies:

  • WSS 1.0 SAML token Policy:

    wss10_saml_token_service_policy

    This policy authenticates users using credentials provided in SAML tokens in the WS-Security SOAP header. The credentials in the SAML token are authenticated against a SAML login module. This policy can be applied to any SOAP-based endpoint.

  • WSS 1.0 SAML token with message integrity:

    wss10_saml_token_with_message_integrity_service_policy

    This policy provides message-level integrity protection and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard. It uses WS-Security's Basic 128 suite of asymmetric key technologies, specifically RSA key mechanisms for message confidentiality, and SHA-1 hashing algorithm for message integrity.

  • WSS 1.0 SAML token with message protection:

    wss10_saml_token_with_message_protection_service_policy

    This policy enforces message-level protection and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.0 standard. It uses WS-Security's Basic 128 suite of asymmetric key technologies, specifically RSA key mechanisms for message confidentiality, SHA-1 hashing algorithm for message integrity, and AES-128 bit encryption.

  • WSS 1.1 SAML token with message protection:

    wss11_saml_token_with_message_protection_service_policy

    This policy enforces message-level protection (that is, message integrity and message confidentiality) and SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard. Messages are protected using WS-Security's Basic 128 suite of symmetric key technologies, specifically RSA key mechanisms for message confidentiality, SHA-1 hashing algorithm for message integrity, and AES-128 bit encryption. The keystore is configured through the security configuration. It extracts the SAML token from the WS-Security binary security token, and uses those credentials to validate users against the configured identity store. This policy can be attached to any SOAP-based endpoint.

  The keystore is configured through the security configuration. It extracts the SAML token from the WS-Security binary security token, and uses those credentials to validate users against the configured identity store.

To attach a policy to a producer endpoint

1. Open Fusion Middleware Control and log into the target domain.

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

2. In the Navigation pane, expand the Application Deployments node, and click the producer to attach a policy to.

3. From the Application Deployment menu, select Web Services.

   The Web Services Summary page for the producer displays (see Figure 23-175).

   Figure 23-175 Web Services Summary Page

   
   Description of "Figure 23-175 Web Services Summary Page"
   
   

4. Open the Web Service Endpoint tab and click the endpoint to which to attach a policy.

   Note:

   Only the markup service ports should be secured (WSRP_V2_Markup_Service and WSRP_V1_Markup_Service).

   The Web Service Endpoints page for the producer displays (see Figure 23-176).

   Figure 23-176 Web Service Endpoints Page

   
   Description of "Figure 23-176 Web Service Endpoints Page"
   
   

5. Open the Policies tab to display the currently attached policies for the producer (see Figure 23-177).

   Figure 23-177 Web Services Endpoint Policies Page

   
   Description of "Figure 23-177 Web Services Endpoint Policies Page"
   
   

6. Click Attach/Detach to add or remove a policy.

   The Attach/Detach Policies page is shown listing the available policies and their descriptions (see Figure 23-178).

   Figure 23-178 Attach/Detach Policies Page

   
   Description of "Figure 23-178 Attach/Detach Policies Page"
   
   

7. Under Available Policies, select Category and Security as the policy category to search, and click the Search icon to list the security policies.

8. Select the policies to attach and click Attach. Use the Ctrl key to select multiple policies.

   The policies appear in the list under Attached Policies (see Figure 23-179).

   Figure 23-179 Attach Detach Policy Page with Policy Attached

   
   Description of "Figure 23-179 Attach Detach Policy Page with Policy Attached"
   
   

9. When finished adding polices to attach to the producer endpoint, click OK.

23.8.5.3 Setting Up the Keystores

The steps to create and configure keystores for a WSRP producer depend on the topology of your WebCenter environment, and are covered in the following sections:

• Section 23.8.1, "Configuring WS-Security for a Simple Topology"

• Section 23.8.2, "Configuring WS-Security for a Typical Topology"

• Section 23.8.3, "Configuring WS-Security for a Complex Topology"

Please refer to these sections for more complete instructions for setting up the keystores, and other WS-Security aspects of configuring WSRP producers.

23.8.6 Securing WebCenter Spaces for Applications Consuming Spaces Client APIs with WS-Security

This section describes the administrator tasks required to configure WS-Security for WebCenter Spaces so that the communication between the an application exposing WebCenter Spaces APIs (the consumer) and WebCenter Spaces (the producer) is secure, and that the identity of the user invoking the APIs is protected.

You will need to create a Java keystore and update the credential store so that WebCenter Spaces can verify the authenticity of the SAML-based security tokens received from your application. You must then register this keystore and update the credential store. For information about the developer tasks for developing applications that consume WebCenter Spaces client APIs, see "How to Set Up Your Custom WebCenter Application to Use the WebCenter Spaces APIs" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

This section includes the following subsections:

• Section 23.8.6.1, "Generating the Keystores"

• Section 23.8.6.2, "Providing the Keystores and Keystore Information to the Application Developer"

• Section 23.8.6.3, "Registering the Keystores"

• Section 23.8.6.4, "Updating the Credential Stores"

23.8.6.1 Generating the Keystores

Follow the steps below to generate Java keystores for the consumer (the custom WebCenter application) and producer (WebCenter Spaces).

To generate keystores for the consumer and producer:

1. Go to JDK_HOME/jdk/bin and open a command prompt.

2. Using keytool, generate a key pair:

   keytool -genkeypair -keyalg RSA -dname "consumer_dname" -alias consumer_alias -keypass key_password 
   -keystore keystore -storepass keystore_password -validity days_valid
   

   Where:

   • consumer_dname is the distinguished name of the consumer (for example, cn=consumer,dc=example,dc=com). The value could be anything but typically matches the distinguished name (DN) of the machine on which the keystore would reside.

   • consumer_alias is the alias of the consumer (for example, consumer)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore is the keystore name, (for example, consumer.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 360).

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key is incompatible with Oracle WebServices Security Manager requirements.

3. Export the public key for the consumer:

   keytool -exportcert -v -alias consumer_alias -keystore keystore -storepass keystore_password -rfc -file certificate_file
   

   Where:

   • consumer_alias is the alias of the consumer (for example, consumer)

   • keystore is the keystore name, (for example, consumer.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • certificate_file is the file name for the certificate to export the key to (for example, consumer.cer)

4. Generate the producer keystore by importing the trusted certificate of the consumer:

   keytool -importcert -alias consumer_alias -file certificate_file -keystore keystore -storepass keystore_password
   

   Where:

   • consumer_alias is the alias of the consumer

   • certificate_file is the certificate file name

   • keystore is the keystore name

   • keystore_password is the keystore password

5. Generate the key pair for the producer:

   keytool -genkeypair -keyalg RSA -dname "producer_dname" -alias producer_alias -keypass key_password 
   -keystore keystore-storepass keystore_password -validity days_valid
   

   Where:

   • producer_dname is the name of the producer (for example, cn=producer,dc=example,dc=com)

   • producer_alias is the alias of the producer (for example, producer)

   • key_password is the password for the new public key, (for example, welcome1)

   • keystore is the keystore name, (for example, producer.jks)

   • keystore_password is the keystore password, (for example, welcome1)

   • days_valid is the number of days for which the key password is valid (for example, 1024)

   Note:

   You must use the -keyalg parameter and specify RSA as its value as shown above as the default algorithm (DSA) used by keytool for generating the key will not work.

6. List the contents of the keystore:

   keytool -list -v -keystore keystore_name -storepass password
   

   Where:

   • keystore_name is the name of the consumer keystore file (for example, portal.jks)

   • password is the keystore password.

   The keystore should now have two key entries.

7. Export the public key of the producer:

   keytool -exportcert -v -alias producer_alias -keystore keystore -storepass keystore_password -rfc -file certificate_file
    
   

   Where:

   • producer_alias is the alias of the producer (for example, producer)

   • keystore is the keystore name (for example, producer.jks)

   • keystore_password is the keystore password, (for example,welcome1

   • certificate_file is the certificate file name (for example, producer.cer)

8. Import the trusted certificate of the producer:

   keytool -importcert -alias producer_alias -file certificate_file -keystore keystore_name -storepass keystore_password
   

   Where:

   • producer_alias is the alias of the producer (for example, producer)

   • certificate_file is the file name or path for the producer's certificate file (for example,../producer/producer.cer)

   • keystore_name is the keystore name (for example, consumer.jks)

   • keystore_password is the keystore password, (for example, welcome1)

23.8.6.2 Providing the Keystores and Keystore Information to the Application Developer

Before registering the keystores, make sure that you have provided the following to the developer creating the application that will be consuming the WebCenter Spaces APIs.

• The consumer keystore to be used to secure the connection. This is a .jks file (for example, consumer.jks).

• The consumer public alias key stored in the keystore (for example, consumer).

• The password of the consumer public alias key (for example, welcome1).

• The producer public alias key stored in the consumer keystore (for example, producer). This is the alias used when importing the trusted certificate of the producer, and created in step 8 of Section 23.8.6.1, "Generating the Keystores."

• The consumer keystore password (for example, welcome1).

23.8.6.3 Registering the Keystores

After you have created the keystores, configure the keystore for WS-Security by performing the following steps. If a keystore provider is already configured, unconfigure the existing keystore provider before proceeding as described in Section 23.8.1.1.4, "Unconfiguring a Keystore Provider Using Fusion Middleware Control."

To register the keystore provider:

1. Copy the producer.jks file to the file system where your producer application is running (for example, DOMAIN_HOME/config/fmwconfig).

2. Log into Fusion Middleware Control.

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

3. In the Navigation pane, expand the WebLogic Domain node and click on the domain (for example, webcenter).

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

   The Security Provider Configuration page displays (see Figure 23-180).

   Figure 23-180 Security Provider Configuration Page

   
   Description of "Figure 23-180 Security Provider Configuration Page"
   
   

5. Expand the Keystore section on the Security Provider Configuration page.

6. Click Configure.

   The Keystore Configuration page displays (see Figure 23-181).

   Figure 23-181 Keystore Configuration Page

   
   Description of "Figure 23-181 Keystore Configuration Page"
   
   

7. In the Keystore Path field, specify the location of the keystore that contains the certificate and private key that is used for signing some parts (security token and SOAP message body) of the SOAP message, and enter and confirm the keystore Password.

8. In the Signature Key section, enter sign-csf-key as the Key Alias, and enter and confirm the signature key Password (the value used for <key_password> above) for the new public key, (for example, welcome1).

9. In the Encryption Key section, enter enc-csf-key in the Crypt Alias field, and enter and confirm the encryption key Password (the value used for <key_password> above) for the new public key, (for example, welcome1).

10. Click OK to save your settings.

11. Restart the Administration server for the domain.

23.8.6.4 Updating the Credential Stores

Follow the steps below to update the credential stores from the command line using WLST, or using Fusion Middleware Control.

This section contains the following subsections:

• Section 23.8.6.4.1, "Updating the Credential Store Using WLST"

• Section 23.8.6.4.2, "Updating the Credential Store Using Fusion Middleware Control"

23.8.6.4.1 Updating the Credential Store Using WLST

Update the credential store using the WLST createCred command. Use the following example values to add the keystore-csf-key, enc-csf-key, and sign-csf-key encryption keys. Before running the command, be sure to back up the cwallet.sso file.

Example 23-32 keystore-csf-key

createCred(map="oracle.wsm.security",key="keystore-csf-key",user="keystore-csf-key",password="welcome1",desc="Keystore Password")

Example 23-33 enc-csf-key

createCred(map="oracle.wsm.security",key="enc-csf-key",user="producer",password="welcome1",desc="Enc Password")

Example 23-34 sign-csf-key

createCred(map="oracle.wsm.security",key="sign-csf-key",user="producer",password="welcome1",desc="Enc Password")

23.8.6.4.2 Updating the Credential Store Using Fusion Middleware Control

1. Log into Fusion Middleware Control.

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

2. In the Navigation pane, expand the WebLogic Domain node and click on the domain (for example, webcenter).

3. From the WebLogic Domain menu, select Security -> Credentials.

   The Credentials page displays (see Figure 23-182).

   Figure 23-182 Credentials Page

   
   Description of "Figure 23-182 Credentials Page"
   
   

4. Click Create Map.

5. On the Create Map pop-up, enter oracle.wsm.security as the map name and click OK.

6. Click Create Key.

7. On the Create Key pop-up, select oracle.wsm.security as the map, enter keystore-csf-key as the Key, select Password as the Type, enter keystore-csf-key as the User Name, supply the Password (in this case, the keystore password of producer.jks) from when you created the keystores (for example, welcome1), enter an optional description, and click OK.

8. Click Create Key.

9. On the Create Key pop-up, select oracle.wsm.security as the map, enter sign-csf-key as the Key, select Password as the Type, enter the public key alias of the keystore used in the custom WebCenter application as the User Name, enter the password of the public key used in the custom WebCenter application as the Password, enter an optional description, and click OK.

10. Click Create Key.

11. On the Create Key pop-up, select oracle.wsm.security as the map, enter enc-csf-key as the Key, select Password as the Type, enter the public key alias of the keystore used in the WebCenter instance (for example, webcenter) as the User Name, enter the password of the public key used in the custom WebCenter application as the Password, enter an optional description, and click OK.

12. Restart the Administration server and WLS_Custom or managed server on which the custom WebCenter application is hosted.

23.9 Securing a PDK-Java Producer

A shared key can be defined for message integrity protection and should be used with SSL. The steps to store a shared key as a password credential are:

• Define a shared key as a password credential in the credential store of the administration server instance. This can be done using either Fusion Middleware Control or WLST.

• Restart the web producer and access the test page. Confirm that the shared key has been picked up correctly by checking the application logs.

Note:

Using a shared key provides only message integrity protection. For complete message protection SSL is required. For more information on securing PDK-Java portlets using SSL, see Section 23.6.5, "Securing the WebCenter Spaces Connection to Portlet Producers with SSL."

23.9.1 Defining a Shared Key as a Password Credential

You can define a shared key as a password credential in the credential store of the administration server instance using either Fusion Middleware Control or WLST commands.

23.9.1.1 Defining a Shared Key Using Fusion Middleware Control

To define a shared key using Fusion Middleware Control:

1. Log into Fusion Middleware Control.

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

2. In the Navigation pane, expand the WebLogic Domain node and click the target domain (for example, wc_domain).

3. From the WebLogic Domain menu, select Security > Credentials.

   The Credentials pane displays (see Figure 23-183).

   Figure 23-183 Credentials Pane

   
   Description of "Figure 23-183 Credentials Pane"
   
   

4. Click Create Map and enter PDK as the Map Name and click OK.

5. Click Create Key and select the map (PDK) you just created.

6. Enter a User Name (this value is not used so it could be anything), a Key in the form pdk.<service_id>.sharedKey (where <service_id> is the name of the producer), and a 10 to 20 hexadecimal digit Password and click OK.

   The new key is displayed in the Credential pane (see Figure 23-184).

   Figure 23-184 Credentials Pane with New Shared Key

   
   Description of "Figure 23-184 Credentials Pane with New Shared Key"
   
   

23.9.1.2 Defining a Shared Key Using WLST

You can also define a shared key using WLST:

1. Start WLST as described in Section 1.12.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands," and connect to the Administration Server instance for the target domain.

2. Connect to the 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. Add a shared key credential for a producer to the credential store using the WLST createCred command:

   createCred(map='PDK', key='pdk.service_id.sharedKey.user_name', user='user_name', password='password')
   

   Where:

   • service_id is the name of the producer to create the key for (for example, omniPortlet)

   • user_name is the name of the user. This value is not used so it could be anything.

   • password is a 10 to 20 hexadecimal digit value.

   For example:

   createCred(map='PDK', key='pdk.omniPortlet.sharedKey', user='sharedKey', password='1234567890abc')
   

   Note:

   After creating a credential, you can use the WLST updateCred command with the same parameters as above to update it.

4. Restart the producer.

   Web producers pick up properties the first time they handle a request (for example, a browser test page request or when they are first registered), so producers should be restarted once a shared key credential has been set up.

23.10 Troubleshooting Security Configuration Issues

This section includes the following sub-sections:

• Section 23.10.1, "Webcenter Spaces Does Not Find Users in LDAP Provider"

• Section 23.10.2, "Group Space Gets Created with Errors When Logged in as OID User"

• Section 23.10.3, "Users Cannot Do Self-Registration with WebCenter Spaces Configured with Active Directory"

• Section 23.10.4, "User Made Administrator Doesn't Have Administrator Privileges"

• Section 23.10.5, "OmniPortlet Producer Authorization Exception in SSO Environment"

23.10.1 Webcenter Spaces Does Not Find Users in LDAP Provider

Problem

Weblogic Server was configured with an external LDAP provider. Users in the external LDAP can log into WebCenter Spaces , but when trying to assign administrator roles in WebCenter Spaces to a user from the external LDAP, no users are found.

Solution

Change the Control Flag for the DefaultAuthenticator Authentication Provider to Sufficient as described in Section 23.3.1, "Reassociating the Identity Store with an External LDAP." Restart the Administration Server and Managed Servers for the domain.

23.10.2 Group Space Gets Created with Errors When Logged in as OID User

Problem

When logged into WebCenter as an OID user (e.g., orcladmin), and trying to create a Group Space, the Group Space gets created but with errors. The error message appears as "No matching users were found with search string <login user>" is shown.

Solution

The following property is missing in the jps-config.xml file:

<property name="jps.user.principal.class.name" value="weblogic.security.principal.WLSUserImpl"/> 

To fix this:

1. Edit <MIDDLEWARE_HOME>/user_projects/domains/WebCenter/config/fmwconfig/jps-config.xml.

2. Add this line in the general properties:

   <property name="jps.user.principal.class.name" value="weblogic.security.principal.WLSUserImpl"/>

3. Restart the WLS_Spaces server.

23.10.3 Users Cannot Do Self-Registration with WebCenter Spaces Configured with Active Directory

Problem

Users cannot do self-registration with Active Directory after configuring WebCenter Spaces to use AD authenticator. When a user tries to self-register, the following error message appears:

"User not created. Either the user name or the password does not adhere to the registration policy or the identity store is unavailable. Specify the required user credentials or contact your administrator for assistance."

Solution

To fix the problem:

1. Set the user name attribute to sAMAccountName while configuring Active Directory in the WebLogic Administration Console.

2. Use the HTTPS port of the LDAP and enable the SSL checkbox while configuring Active Directory in the WebLogic Administration Console.

23.10.4 User Made Administrator Doesn't Have Administrator Privileges

Problem

After logging in as orcladmin and making a user an administrator, after logging out and logging in as that user, the administrator link is still not available.

Solution

The problem is due to duplicate cn entries in the identity store. Since cn is mapped to the username attribute, it must be unique. Remove the duplicate from the identity store and the user should have the appropriate privileges.cn

23.10.5 OmniPortlet Producer Authorization Exception in SSO Environment

Problem

OmniPortlet producer receives an authorization exception when it tries to store connection information in the Credential Store Framework (CSF) wallet when WebCenter is configured with SSO.

Solution

Grant the required permissions to ssofilter.jar by connecting to the Oracle WebCenter Administration Server using WLST (for more information, see Section 1.12.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands") and running the following grant commands:

grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_user,keyName=*",
permActions="*")

grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_default,keyName=*",
permActions="*")
grantPermission(codeBaseURL="file:${oracle.home}/modules/oracle.ssofilter_11.1
.1/ssofilter.jar",
permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",
permTarget="context=SYSTEM,mapName=omniportlet_user,keyName=*",
permActions="*")