26 Configuring WebCenter Applications and Components to Use SSO

This chapter describes the available single sign-on (SSO) solutions for your WebCenter application to use, and how each is configured.

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 following subsections describe the setup required for each of these SSO solutions:

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

26.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 26.1.2, "Configuring OAM Using Scripts," and complete the instructions in Section 26.1.3, "Configuring the Webtier Components" and Section 26.1.6, "Configuring the Policy Manager," and any additional configurations as appropriate in Section 26.1.7, "Additional Configurations."

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

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

26.1.1 OAM Components and Topology

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

Figure 26-1 OAM Single Sign-On Components and Topology

Description of Figure 26-1 follows
Description of "Figure 26-1 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.

26.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 26.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 ones that you must 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,/cmisrestprelim"
    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 display. 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 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 displays (it will have the suffix _AG), click 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 26.1.6, "Configuring the Policy Manager," and any further configurations, as required, in Section 26.1.7, "Additional Configurations."

26.1.3 Configuring the Webtier Components

This section includes the following subsections:

26.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. Ensure 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=8888
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=8888
MatchExpression /cmisrestprelim WebLogicHost=webcenter.example.com|WebLogicPort=8888
</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.

26.1.3.2 Create an AccessGate Entry

An AccessGate entry must 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 an 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 26-1 shows settings for a typical AccessGate entry.

Table 26-1 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

 

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

26.1.4 Manually Configuring the Access System

To configure the Access System, you must 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.

26.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 26-2).

    Figure 26-2 Policy Manager Pane

    Description of Figure 26-2 follows
    Description of "Figure 26-2 Policy Manager Pane"

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

    The Create Policy Domain page displays (see Figure 26-3).

    Figure 26-3 Create Policy Domain Page

    Description of Figure 26-3 follows
    Description of "Figure 26-3 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 26-4).

    Figure 26-4 Policy Domain Resource Page

    Description of Figure 26-4 follows
    Description of "Figure 26-4 Policy Domain Resource Page"

  6. Add the resources that must 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
      /cmisrestprelim
      /webcenter/adfAuthentication
      /webcenter/content
      /workflow/sdpmessagingsca-ui-worklist
      /workflow/WebCenterWorklistDetail/faces
      /workflow/sdpmessagingsca-ui-worklist
      
    4. Enter a Description for the resource.

    5. Ensure 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, ensure 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 26-5).

    Figure 26-5 Authorization Rules Page

    Description of Figure 26-5 follows
    Description of "Figure 26-5 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 26-6).

    Figure 26-6 Allow Access Page

    Description of Figure 26-6 follows
    Description of "Figure 26-6 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 26-7).

    Figure 26-7 Access Manager Authentication Rules Page

    Description of Figure 26-7 follows
    Description of "Figure 26-7 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 26-8).

    Figure 26-8 Authorization Expression Page

    Description of Figure 26-8 follows
    Description of "Figure 26-8 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 26-9).

  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 26-10).

    Figure 26-10 Policies Page

    Description of Figure 26-10 follows
    Description of "Figure 26-10 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 26-10. 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 26-11).

    Figure 26-11 Policies List

    Description of Figure 26-11 follows
    Description of "Figure 26-11 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 26-12).

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

  30. Click Save.

26.1.6 Configuring the Policy Manager

This section includes the following subsections:

26.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 in to 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 26-13).

    Figure 26-13 Summary of Security Realms Pane

    Description of Figure 26-13 follows
    Description of "Figure 26-13 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 26-14).

    Figure 26-14 Settings Pane

    Description of Figure 26-14 follows
    Description of "Figure 26-14 Settings Pane"

  4. Open the Providers tab.

    The Provider Settings display (see Figure 26-15).

    Figure 26-15 Settings Pane - Providers

    Description of Figure 26-15 follows
    Description of "Figure 26-15 Settings Pane - Providers"

  5. Click New to create a provider.

    The Create a New Authentication Provider pane displays (see Figure 26-16).

    Figure 26-16 Create a New Authentication Provider Pane

    Description of Figure 26-16 follows
    Description of "Figure 26-16 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 26-17).

    Figure 26-17 Common Settings Pane

    Description of Figure 26-17 follows
    Description of "Figure 26-17 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 26-18).

    Figure 26-18 Provider Specific Settings for OID Authenticator

    Description of Figure 26-18 follows
    Description of "Figure 26-18 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.

26.1.6.2 Configuring the OAM Identity Asserter

An OAM identity asserter must 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 in to 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 26-19).

    Figure 26-19 Summary of Security Realms Pane

    Description of Figure 26-19 follows
    Description of "Figure 26-19 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 26-20).

    Figure 26-20 Settings Pane

    Description of Figure 26-20 follows
    Description of "Figure 26-20 Settings Pane"

  4. Open the Providers tab.

    The Provider Settings display (see Figure 26-21).

    Figure 26-21 Settings Pane - Providers

    Description of Figure 26-21 follows
    Description of "Figure 26-21 Settings Pane - Providers"

  5. Click New to create a provider.

    The Create a New Authentication Provider pane displays (see Figure 26-22).

    Figure 26-22 Create a New Authentication Provider Pane

    Description of Figure 26-22 follows
    Description of "Figure 26-22 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 26-23).

    Figure 26-23 Common Settings Pane

    Description of Figure 26-23 follows
    Description of "Figure 26-23 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 26-24).

    Figure 26-24 Provider Specific Settings for the OAMIdentityAsserter

    Description of Figure 26-24 follows
    Description of "Figure 26-24 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.

26.1.6.3 Configuring the Default Authenticator and Setting the Provider Order

After configuring the OAM identity asserter, ensure 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 26-21).

  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

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

26.1.7 Additional Configurations

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

26.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 26-25).

    Figure 26-25 Policy Manager Pane

    Description of Figure 26-25 follows
    Description of "Figure 26-25 Policy Manager Pane"

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

  4. Open the Resources tab and click Add.

    The Resource page displays (see Figure 26-26).

    Figure 26-26 Policy Domain Resource Page

    Description of Figure 26-26 follows
    Description of "Figure 26-26 Policy Domain Resource Page"

  5. Add the resources that must 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. Ensure 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=8888
      MatchExpression /cmisrestprelim  WebLogicHost=example.com|WebLogicPort=8888
      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.

26.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, ensure that it has been configured to use the same identity store LDAP as WebCenter Spaces, as described in Section 24.1, "Reassociating the Identity Store with an External LDAP." If you've chosen not to move the default administrator account to an external LDAP, be sure to also follow the instructions in Section 24.5.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
    
26.1.7.2.1 Creating a Discussions Server Connection for WebCenter Spaces

To create a discussions server connection for WebCenter Spaces:

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

    For information on logging in to 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 in to WebCenter Spaces, you automatically sign on to the discussion server as well.

26.1.7.3 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 initiates SSO.

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

  5. Save the changes.

26.1.7.4 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 in to 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 26-27).

    Figure 26-27 Security Filter Settings Page

    Description of Figure 26-27 follows
    Description of "Figure 26-27 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. You can use this information 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
    

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

26.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 26-28) shows the overall architecture of this integration:

Figure 26-28 OSSO Components and Topology

Description of Figure 26-28 follows
Description of "Figure 26-28 OSSO Components and Topology"

26.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=8888
    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=8888
    MatchExpression /cmisrestprelim WebLogicHost=webcenter.example.com|WebLogicPort=8888
    </IfModule>
    

26.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 in to 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 26-29).

    Figure 26-29 Summary of Security Realms Pane

    Description of Figure 26-29 follows
    Description of "Figure 26-29 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 26-30).

    Figure 26-30 Settings Pane

    Description of Figure 26-30 follows
    Description of "Figure 26-30 Settings Pane"

  4. Click the Providers tab.

    The Provider Settings display (see Figure 26-31).

    Figure 26-31 Settings Pane - Providers

    Description of Figure 26-31 follows
    Description of "Figure 26-31 Settings Pane - Providers"

  5. Click New to create a provider.

    The Create a New Authentication Provider pane displays (see Figure 26-32).

    Figure 26-32 Create a New Authentication Provider Pane

    Description of Figure 26-32 follows
    Description of "Figure 26-32 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. Ensure 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 Chapter 24, "Configuring the Identity Store."

    For OID, the provider list should appear as follows:

    • OracleInternetDirectoryAuthenticator (SUFFICIENT)

    • OSSOIdentityAsserter (OPTIONAL)

    • DefaultAuthenticator (SUFFICIENT)

    • DefaultIdentityAsserter (OPTIONAL)

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

26.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>
        <Location /cmisrestprelim>
          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
    

    Ensure that you 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 26.1.7.4, "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 26.1.6.4, "Configuring the Application for Oracle Access Manager SSO."

26.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, ensure that it has been configured to use the same identity store LDAP as WebCenter Spaces, as described in Section 24.5.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
    

26.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 (including the /rest webapp and /cmisrestprelim webapp) do not 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:

26.3.1 SAML Components and Topology

Figure 26-34 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 26-33 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 26-33 Detailed SAML Single Sign-on Components and Topology (POST Profile Configured)

Description of Figure 26-33 follows
Description of "Figure 26-33 Detailed SAML Single Sign-on Components and Topology (POST Profile Configured)"

Figure 26-34 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 26-34 SAML Single Sign-on Components and Topology (POST Profile Configured)

Description of Figure 26-34 follows
Description of "Figure 26-34 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 shares 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.

26.3.2 Configuring SAML-based Single Sign-on

This section describes how to configure WebCenter Spaces and services for SAML-based single sign-on. You can either use a set of automated scripts, or do the configuration manually. This section provides the steps for both approaches, along with a set of common prerequisites, and a set of steps to check that your single sign-on is working.

This section includes the following sub-sections:

26.3.2.1 Common Prerequisites

This section describes the common set of steps for configuring SAML-based single sign-on. These steps must be carried out first regardless of whether you're using the scripts or doing the configuration manually.

The prerequisites for SAML-based SSO are described in the following sub-sections:

26.3.2.1.1 Preparing WebCenter Spaces and Services for SAML SSO

Install WebCenter Spaces and related applications as required for your environment. After installing WebCenter Spaces and the Wiki and Worklist services, test the single sign-on configuration as described in the steps below.

To install and 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 in to WebCenter Spaces and create a page with a link to the Wiki service:

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

    2. In a group space, choose Create Page from the Page Actions menu.

    3. Enter an appropriate title for the page (for example, "Wiki"), choose the Web page template, and click Create.

    4. Click the Edit icon for the Web page component.

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

    7. Save the page.

    When you click the link, notice 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 are automatically logged in to the Wiki server.

  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 and Oracle Business Process Management Suite.

  4. Configure a connection between WebCenter Spaces and the BPEL server, as described in Section 20.3, "Setting Up Worklist Connections."

  5. To test the BPEL server connection used by the Worklist service:

    1. Log in to WebCenter Spaces, create a group space, and add your administrator account as a moderator.

    2. Log in to 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 in to the BPEL server 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 must deploy the SAML SSO version of the discussion server .EAR file.

    Note:

    Before configuring the discussions server for SSO, ensure that it is configured to use the same identity store LDAP as WebCenter Spaces, as described in Section 24.1, "Reassociating the Identity Store with an External LDAP." If you've chosen not to move the default administrator account to an external LDAP, be sure to also follow the instructions in Section 24.5.1, "Migrating the WebCenter Discussions Server to Use an External LDAP."
    1. Log in to the WebLogic Server Administration Console as an administrator.

      For information on logging in to 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 26-35).

      Figure 26-35 Deployment Summary Pane

      Description of Figure 26-35 follows
      Description of "Figure 26-35 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 in to the Discussions Server Administration Console as an administrator (see Section 26.1.7.2, "Configuring the Discussions Server for SSO" for more information on logging in to 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).

  7. To test RSS access from WebCenter Spaces, click the RSS link from Recent Documents or Lists.

26.3.2.1.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 -validity days_valid
    

    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)

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

  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 in to 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 26-36).

        Figure 26-36 Keystores Settings Pane

        Description of Figure 26-36 follows
        Description of "Figure 26-36 Keystores Settings Pane"

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

        Note that the cacerts file may be "read only", in which case you must 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 in to 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 26-37).

    Figure 26-37 Summary of Servers Pane

    Description of Figure 26-37 follows
    Description of "Figure 26-37 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 26-38).

    Figure 26-38 Settings Pane for WebCenter Spaces Server

    Description of Figure 26-38 follows
    Description of "Figure 26-38 Settings Pane for WebCenter Spaces Server"

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

    The Keystores pane displays (see Figure 26-39).

    Figure 26-39 Keystores Pane

    Description of Figure 26-39 follows
    Description of "Figure 26-39 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.

26.3.2.1.3 Setting Up SSL

If the WebCenter installation requires SSL for providing transport-level security, then SSL should be configured before configuring single sign-on as described in Section 26, "Configuring WebCenter Applications and Components to Use SSO." Note that setting up SSL is not related to enabling SSO.

26.3.2.2 Configuring SAML-based SSO Using Scripts

After installing WebCenter Spaces and services as required for your environment, continue by configuring SAML-based single sign-on using the scripts as described in this section.

The scripts set up SAML-based single sign-on in a WebLogic environment by configuring:

  • SAML Credential Mapping Provider

  • Necessary relying parties

  • Source Site Federation Services

  • SAML Identity Asserter

  • Necessary asserting parties

  • Destination Site Federation Services

The manual configuration details for each of the above configuration steps are also described in Section 26.3.2.3, "Configuring SAML-based SSO Manually."

This section includes the following sub-sections:

26.3.2.2.1 The Single Sign-on Script

The scripts are contained in a ZIP file (saml_scripts.zip) that can be downloaded from OTN at:

http://www.oracle.com/technology/products/webcenter/files/saml_scripts.zip

The ZIP file contains the scripts to configure SAML 1.1 SSO for WebCenter Spaces and related applications. The following files are contained in the ZIP file:

wcsamlsso.properties

This properties file encapsulates the necessary configuration information for the SAML SSO setup. The properties file has the following sections:

spaces_config

This section captures the login information, WebLogic Admin URL, WebCenter Spaces server and URL, and so forth, of the WebCenter domain required for the Credential Mapper and Source Site Federation Services configuration. All properties in this section must be completed.

  • configFile - Config file containing the weblogic user account and password for the WebCenter domain

  • keyFile - Key file to decrypt the weblogic user account and password for the WebCenter domain

  • adminURL - WebLogic Admin URL to connect to WLST

  • usesSSL - Indicates whether WebCenter Spaces is configured to use SSL

  • url - WebCenter URL. If usesSSL is "true", then change "http" to "https"

  • serverName - Server where WebCenter Spaces is deployed, typically WLS_Spaces

  • certAlias - Alias of certificate to sign SAML assertions

  • certPassword - Encrypted password of certificate to sign SAML assertions

services_config

This section captures the login information, admin URL, certificate file path, and so forth, of the Services domain required for the Identity Asserter and Destination Site Federation Services configuration. Only complete this section if your setup has Wiki and/or Discussions configured.

  • configFile - Config file containing weblogic user account and password for the Services domain

  • keyFile - Key file to decrypt weblogic user account and password for the Services domain

  • adminURL - WebLogic Admin URL to connect to WLST

  • usesSSL - Indicates whether Wiki/Discussions is configured to use SSL

  • serverName - Server where Wiki and Discussions are deployed (typically the WLS_Services Managed Server)

  • certAlias - Alias of certificate to verify SAML assertions

  • certPath - Path to exported certificate to verify SAML assertions

soa_config

This section captures the login information, admin URL, certificate file path, and so forth, of the SOA domain required for the Identity Asserter and Destination Site Federation Services configuration. Only complete this section if your setup has SOA configured.

  • configFile - Config File containing the weblogic user account and password for the SOA domain

  • keyFile - Key File to decrypt the weblogic user account and password for the SOA domain

  • adminURL - WebLogic Admin URL to connect to WLST

  • usesSSL - Indicates whether SOA applications are configured to use SSL

  • serverName - Server where SOA applications are deployed (typically soa_server1)

  • certAlias - Alias of certificate to verify SAML assertions

  • certPath - Path to exported certificate to verify SAML assertions

wiki_config

Specify whether your configuration has Wiki installed.

  • url - OWC Wiki URL. If usesSSL in services_config is "true", then change "http" to "https"

rss_config

This section must be completed.

  • url - RSS URL. If usesSSL in spaces_config is "true", then change "http" to "https"

forum_config

Specify whether your configuration has Discussions installed.

  • url - OWC Discussions URL. If usesSSL in services_config is "true", then change "http" to "https"

worklist_config

Specify whether SOA is installed and Worklist is configured for WebCenter Spaces.

  • worklist_detail - Worklist Detail application URL. If usesSSL in soa_config is "true", then change "http" to "https"

  • worklist_sdp - Worklist SDP application URL. If usesSSL in soa_config is "true", then change "http" to "https"

  • worklist_integration - Worklist Integration application URL. If usesSSL in soa_config is "true", then change "http" to "https"

wcsamlsso.py

Script file that contains utility functions invoked by rest of the configuration scripts

configureSpaces.py

Executable script to configure SAML 1.1 Credential Mapper, SAML 1.1 Identity Asserter and Source and Destination site federation services on the WebCenter domain

configureServices.py

Executable script to configure SAML 1.1 Identity Asserter and Destination site federation services on the Services domain

configureSOA.py

Executable script to configure SAML 1.1 Identity Asserter and Destination site federation services on the SOA domain

configureSSO.py

Executable script to configure asserting and relying parties for all related applications used in WebCenter Spaces (that is, RSS, Wiki, Discussions, and Worklist). If your setup does not have one or more of the six applications, then Oracle recommends that you run the specific scripts to configure individual applications described below.

configureRSS.py

Executable script to configure asserting and relying parties for the RSS application

configureWiki.py

Executable script to configure asserting and relying parties for the Wiki application

configureForum.py

Executable script to configure asserting and relying parties for the Discussions application

configureWorklistIntegration.py

Executable script to configure asserting and relying parties for the Worklist Integration application

configureWorklistDetail.py

Executable script to configure asserting and relying parties for the Worklist Community Detail application

configureWorklistSDP.py

Executable script to configure asserting and relying parties for the Worklist SDP application

26.3.2.2.2 Using the Scripts

Follow the steps below to use the scripts to configure SAML-based single sign-on:

  1. Download the ZIP file (saml_scripts.zip) from OTN at:

    http://www.oracle.com/technology/products/webcenter/files/saml_scripts.zip

  2. Unzip the contents of the zip file into $ORACLE_HOME. This extracts the contents into $ORACLE_HOME/wlserver_10.3/common/bin and $ORACLE_HOME/wlserver_10.3/common/wlst.

  3. Ensure that the Administration server for all the domains used in this configuration are up and running.

  4. Generate the config and key files containing the connection information for the various domains using the storeUserConfig WLST command. Use the command-line help (help('storeUserConfig')) for usage and syntax details.

    The wcsamlsso.properties file assumes that the config and key files exist in the same directory. You can change this when you edit the properties file in step 6 to specify the absolute paths of the config and key files if you choose different locations.

    1. Connect using WLST to the WebCenter domain using the admin username and password, and run the following command:

      storeUserConfig('spacesconfig.secure', 'spaceskey.secure')

      This creates a user configuration file and an associated key file. The user configuration file contains an encrypted username and password. The key file contains a secret key that is used to encrypt and decrypt the username and password. The above command stores the config and key files in the directory from where WLST was invoked, or you can optionally specify a more secure path.

    2. Repeat step 4a after connecting to the services domain using the admin username and password. Even if Wiki and Discussions are installed on the same domain as WebCenter Spaces (wc_domain), you must connect to the WebCenter domain and run this command:

      storeUserConfig('servicesconfig.secure', 'serviceskey.secure')

    3. Repeat step 4a after connecting to the SOA domain using the Admin username and password. Even if SOA is installed on the same domain as WebCenter Spaces, you must connect to the WebCenter domain and run this command:

      storeUserConfig('soaconfig.secure', 'soakey.secure')

  5. Launch WLST and run the WLST encrypt command to encrypt the certificate password. Use the command-line help (help('encrypt')) for usage and syntax details.

    print encrypt(obj='<certificatePassword>', domainDir='<full path to the Spaces domain directory>')

    This displays the encrypted certificate password. The encrypt command uses the encryption for a specified WebLogic Server domain root directory. The encrypted output needs to be set as the certPassword value in wcsamlsso.properties mentioned in the next step. Since this password will be set onto the credential mapper and source site federation services in the WebCenter domain, ensure that you run the encryption utility from the WebCenter domain.

  6. Edit $ORACLE_HOME/wlserver_10.3/common/bin/wcsamlsso.properties and complete the sections applicable to your setup. Refer to Section 26.3.2.2.1, "The Single Sign-on Script" for a detailed description of the sections in this properties file.

  7. Launch WLST from $ORACLE_HOME/wlserver_10.3/common/bin and execute the scripts in the order shown below.

    Note:

    Run the scripts in the WLST offline mode as the scripts include an explicit connect command.
    1. execfile('configureSpaces.py')

      Restart the Administration server and the WLS_Spaces Managed Server in the WebCenter domain.

    2. If you have a Wiki or Discussions setup, execute the configureServices.py script:

      execfile('configureServices.py')

      If Wiki and Discussions belong to the same domain as WebCenter Spaces, then only restart the WLS_Services Managed Server. Otherwise, restart the Administration server and the WLS_Services Managed Server in the Services domain.

    3. If you have Worklist configured for WebCenter Spaces, execute the configureSOA.py script:

      execfile('configureSOA.py')

      Restart the Administration server and the SOA server in the SOA domain.

  8. Follow either step a or b below depending on whether you have installed all related applications along with WebCenter Spaces, or have only selected some applications in your setup.

    1. If you have all applications installed (that is, RSS, Wiki, Discussions, Worklist Integration, Detail and SDP), then you can run this single command to configure asserting and relying parties for all applications:

      execfile('configureSSO.py')

      No restart is required after executing this script.

    2. If you do not have all applications installed, run the individual commands below as required.

      execfile('configureRSS.py') - No restart is required.

      execfile('configureWiki.py') - Do this if you have Wiki installed in your setup. No restart is required.

      execfile('configureForum.py') - Do this if you have Discussions installed in your setup. No restart is required.

      execfile('configureWorklistIntegration.py') - Do this if you have Worklist installed in your setup. No restart is required.

      execfile('configureWorklistDetail.py') - Do this if you have Worklist installed in your setup. No restart is required.

      execfile('configureWorklistSDP.py') - Do this if you have Worklist installed in your setup. No restart is required.

  9. Check your installation using the steps provided in Section 26.3.2.4, "Checking Your Configuration."

    IMPORTANT:

    Since the properties file contains sensitive information, delete it after you have configured and verified the SAML SSO setup. Also delete the config and key files you generated in step 4 above.

Note:

If you encounter errors when running the scripts, you must remove the asserting and relying parties set up by the scripts before running the scripts again.

To remove asserting and relying parties:

Continue by fixing the issue reported and re-running the scripts.

26.3.2.3 Configuring SAML-based SSO Manually

This section describes the equivalent manual steps to set up SAML-based single sign-on in a WebLogic environment to those performed by the scripts described in Section 26.3.2.2, "Configuring SAML-based SSO Using Scripts." These steps are not required if the scripts successfully configured single sing-on for your environment.

The manual steps consist of configuring:

  • SAML Credential Mapping Provider

  • Necessary relying parties

  • Source Site Federation Services

  • SAML Identity Asserter

  • Necessary asserting parties

  • Destination Site Federation Services

These steps are described in the following sub-sections:

26.3.2.3.1 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 in to 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 26-40).

    Figure 26-40 Summary of Security Realms Pane

    Description of Figure 26-40 follows
    Description of "Figure 26-40 Summary of Security Realms Pane"

  3. Click your security realm.

    The Settings page for the security realm displays (see Figure 26-41).

    Figure 26-41 Security Realm Settings Page

    Description of Figure 26-41 follows
    Description of "Figure 26-41 Security Realm Settings Page"

  4. Open the Providers tab and select the Credential Mapping subtab.

    The Credential Mapping pane displays (see Figure 26-42).

    Figure 26-42 Credential Mapping Pane

    Description of Figure 26-42 follows
    Description of "Figure 26-42 Credential Mapping Pane"

  5. Click New.

    The Create a New Credential Mapping Provider pane displays (see Figure 26-43).

    Figure 26-43 Create a New Credential Provider Pane

    Description of Figure 26-43 follows
    Description of "Figure 26-43 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 26-44).

    Figure 26-44 Provider Settings Pane

    Description of Figure 26-44 follows
    Description of "Figure 26-44 Provider Settings Pane"

  8. Open the Provider Specific tab.

    The Provider Specific Settings Pane displays (see Figure 26-45).

    Figure 26-45 Provider Specific Settings Pane

    Description of Figure 26-45 follows
    Description of "Figure 26-45 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 26-2. Leave the remaining parameters set to their default values.

    Table 26-2 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

     

    Reenter the credential password.


  10. Click Save to save your settings.

  11. Restart the WebLogic Administration server.

26.3.2.3.2 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 26-46).

    Figure 26-46 Summary of Security Realms Pane

    Description of Figure 26-46 follows
    Description of "Figure 26-46 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 26-47).

    Figure 26-47 Credential Mapping Providers Settings Pane

    Description of Figure 26-47 follows
    Description of "Figure 26-47 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 26-48).

    Figure 26-48 Relying Parties Management Settings Pane

    Description of Figure 26-48 follows
    Description of "Figure 26-48 Relying Parties Management Settings Pane"

  5. Click New.

    The Create a New Relying Parties page displays (see Figure 26-49).

    Figure 26-49 Create a New Relying Party Page

    Description of Figure 26-49 follows
    Description of "Figure 26-49 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 26-50).

    Figure 26-50 Relying Party Settings Page

    Description of Figure 26-50 follows
    Description of "Figure 26-50 Relying Party Settings Page"

  9. On the Relying Parties page, use the settings shown in Table 26-3 to configure a relying party for the Wiki service. Leave the remaining parameters set to their default values. Click Save when finished.

    Table 26-3 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 are 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 26-4. Leave the remaining parameters on the Relying Parties page set to their default values. Click Save when finished.

    Table 26-4 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 are 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 26-5. Leave the remaining parameters on the Relying Parties pages set to their default values. Click Save when finished.

    Table 26-5 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 are 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 26-6. Leave the remaining parameters on the Relying Parties pages set to their default values. Click Save when finished.

    Table 26-6 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 are 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 26-7. Leave the remaining parameters on the Relying Parties pages set to their default values. Click Save when finished.

    Table 26-7 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 are 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 26-8. Leave the remaining parameters on the Relying Parties pages set to their default values. Click Save when finished.

    Table 26-8 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 are 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.


26.3.2.3.3 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 in to 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 26-51).

    Figure 26-51 Summary of Servers Page

    Description of Figure 26-51 follows
    Description of "Figure 26-51 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 26-52).

    Figure 26-52 Federation Services Configuration SAML 1.1 Source Site Settings Page

    Description of Figure 26-52 follows
    Description of "Figure 26-52 Federation Services Configuration SAML 1.1 Source Site Settings Page"

  5. Configure the SAML source site attributes as shown in Figure 26-52. Leave the remaining parameters set to their default values.

    Table 26-9 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 hexadecimal 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 are 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 are 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 must 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.

26.3.2.3.4 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 in to 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 26-53).

    Figure 26-53 Summary of Security Realms Pane

    Description of Figure 26-53 follows
    Description of "Figure 26-53 Summary of Security Realms Pane"

  3. Click your security realm.

    The Settings page for the security realm displays (see Figure 26-54).

    Figure 26-54 Security Realm Settings Page

    Description of Figure 26-54 follows
    Description of "Figure 26-54 Security Realm Settings Page"

  4. Open the Providers tab and select the Authentication subtab.

    The Authentication Settings pane displays (see Figure 26-55).

    Figure 26-55 Authentication Settings Pane

    Description of Figure 26-55 follows
    Description of "Figure 26-55 Authentication Settings Pane"

  5. Click New.

    The Create a New Authentication Provider page displays (see Figure 26-56).

    Figure 26-56 Create a New Authentication Provider Page

    Description of Figure 26-56 follows
    Description of "Figure 26-56 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 in to 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 26-57).

    Figure 26-57 Summary of Security Realms Pane

    Description of Figure 26-57 follows
    Description of "Figure 26-57 Summary of Security Realms Pane"

  3. Click your security realm.

    The Settings page for the security realm displays (see Figure 26-58).

    Figure 26-58 Security Realm Settings Page

    Description of Figure 26-58 follows
    Description of "Figure 26-58 Security Realm Settings Page"

  4. Open the Providers tab and select the Authentication subtab.

    The Authentication Settings pane displays (see Figure 26-59).

    Figure 26-59 Authentication Settings Pane

    Description of Figure 26-59 follows
    Description of "Figure 26-59 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 26-60).

    Figure 26-60 Certificate Settings Pane

    Description of Figure 26-60 follows
    Description of "Figure 26-60 Certificate Settings Pane"

  6. Click New.

    The Create a New Identity Asserter Certificate page displays (see Figure 26-61).

    Figure 26-61 Create a New Identity Asserter Certificate Page

    Description of Figure 26-61 follows
    Description of "Figure 26-61 Create a New Identity Asserter Certificate Page"

  7. Configure the certificate as shown in Table 26-10.

    Table 26-10 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 26.3.2.1.2, "Generating and Registering Certificates."

    Path

     

    Specify the path name of the .der file containing the X.509 certificate you want to import. This is the file you created in Section 26.3.2.1.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. Ensure that you copy over testalias.der (if 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 in to 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 26-62).

    Figure 26-62 Summary of Security Realms Pane

    Description of Figure 26-62 follows
    Description of "Figure 26-62 Summary of Security Realms Pane"

  3. Click your security realm.

    The Settings page for the security realm displays (see Figure 26-63).

    Figure 26-63 Security Realm Settings Page

    Description of Figure 26-63 follows
    Description of "Figure 26-63 Security Realm Settings Page"

  4. Open the Providers tab and select the Authentication subtab.

    The Authentication Settings pane displays (see Figure 26-64).

    Figure 26-64 Authentication Settings Pane

    Description of Figure 26-64 follows
    Description of "Figure 26-64 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 26-65).

    Figure 26-65 Asserting Parties Settings Pane

    Description of Figure 26-65 follows
    Description of "Figure 26-65 Asserting Parties Settings Pane"

  6. Click New.

    The Create a New Asserting Party page displays (see Figure 26-66).

    Figure 26-66 Create a New Asserting Party Page

    Description of Figure 26-66 follows
    Description of "Figure 26-66 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 26-67).

    Figure 26-67 Asserting Party Settings Page

    Description of Figure 26-67 follows
    Description of "Figure 26-67 Asserting Party Settings Page"

  10. Configure the Asserting Party for the WebCenter domain Wiki service as shown in Table 26-11. For more information, see Table 26-3, "Relying Party Settings for Wiki Service".

    Table 26-11 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 are 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 before 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 26-3, "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 the same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 26-2, "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 26-12 to configure the Asserting party for the WebCenter domain RSS application.

    Table 26-12 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 before 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 26-7, "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 the same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 26-2, "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 26-13 to configure the Asserting party for the WebCenter domain Discussions application.

    Table 26-13 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 before 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 26-8, "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 the same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 26-2, "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 26-14 to configure the Asserting Party for the SOA domain Worklist Community Detail service.

    Table 26-14 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 before 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 26-4, "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 the same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 26-2, "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 26-15 to configure the Asserting Party for the SOA domain Worklist SDP service. For more information see Table 26-5, "Relying Party Settings for Worklist SDP" and Table 26-6, "Relying Party Settings for Worklist Integration".

    Table 26-15 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 before 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 26-5, "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 the same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 26-2, "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 26-16 to configure the Asserting Party for the SOA domain Worklist Community Integration service.

    Table 26-16 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 before 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 26-6, "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 the same as the Issuer URI for the SAML Credential Mapping provider as specified in Table 26-2, "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.


26.3.2.3.5 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 in to 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 26-68).

    Figure 26-68 Summary of Servers Page

    Description of Figure 26-68 follows
    Description of "Figure 26-68 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 26-69).

    Figure 26-69 SAML 1.1 Destination Site Settings Pane (Wiki and Discussions)

    Description of Figure 26-69 follows
    Description of "Figure 26-69 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 26-17.

    Table 26-17 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 26-70).

    Figure 26-70 SAML 1.1 Destination Site Settings Pane (RSS)

    Description of Figure 26-70 follows
    Description of "Figure 26-70 SAML 1.1 Destination Site Settings Pane (RSS)"

  10. Configure the SAML destination site attributes for RSS as shown in Table 26-18.

    Table 26-18 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 26-71).

    Figure 26-71 SAML 1.1 Destination Site Settings Pane (Worklist Detail and SDP)

    Description of Figure 26-71 follows
    Description of "Figure 26-71 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 26-19.

    Table 26-19 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.

  17. Check your configuration as described in Section 26.3.2.4, "Checking Your Configuration."

26.3.2.4 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 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. Using a new browser, log in to WebCenter Spaces and check that you're not challenged for credentials when:

    • You access a 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)

  3. If you see that you are still challenged to log in, or see a 401 or 403 error code, check the configuration in the Administration Console and compare it with the documented configuration in Section 26.3.2.3, "Configuring SAML-based SSO Manually."

26.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) must parse SPNEGO tokens in order to extract Kerberos tokens, which are then used for authentication.

This section contains the following sub-sections:

26.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 26-72 Connecting to a Server Through a Key Distribution Center

Description of Figure 26-72 follows
Description of "Figure 26-72 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 several 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 can 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 26-73 SPNEGO-based Authentication

Description of Figure 26-73 follows
Description of "Figure 26-73 SPNEGO-based Authentication"

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

26.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 26-74. For detailed configuration steps and troubleshooting, see "Configuring Single Sign-On with Microsoft Clients" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

Figure 26-74 Configuring SSO with Microsoft Clients

Description of Figure 26-74 follows
Description of "Figure 26-74 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 26.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 26.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 26.4.3.3, "Configuring WebCenter Spaces").

  7. Configure the discussions server (see Section 26.4.3.4, "Configuring the Discussions Server for SSO").

26.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 through Kerberos.

To configure the Negotiate Identity Assertion provider:

  1. Log in to the WebLogic Server Administration Console.

    For information on logging in to 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 26-75).

    Figure 26-75 Summary of Security Realms Pane

    Description of Figure 26-75 follows
    Description of "Figure 26-75 Summary of Security Realms Pane"

  3. Click your security realm.

    The Settings page for the security realm displays (see Figure 26-76).

    Figure 26-76 Security Realm Settings Page

    Description of Figure 26-76 follows
    Description of "Figure 26-76 Security Realm Settings Page"

  4. Open the Providers tab and select the Authentication subtab.

    The Authentication Settings pane displays (see Figure 26-77).

    Figure 26-77 Authentication Settings Pane

    Description of Figure 26-77 follows
    Description of "Figure 26-77 Authentication Settings Pane"

  5. Click New.

    The Create a New Authentication Provider pane displays (see Figure 26-78).

    Figure 26-78 Create a New Authentication Provider Pane

    Description of Figure 26-78 follows
    Description of "Figure 26-78 Create a New Authentication Provider Pane"

  6. Enter a Name for the identity asserter, and select NegotiateIdentityAsserter as the Type.

  7. Click OK.

26.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 in to 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 26-79).

    Figure 26-79 Summary of Security Realms Pane

    Description of Figure 26-79 follows
    Description of "Figure 26-79 Summary of Security Realms Pane"

  3. Click your security realm.

    The Settings page for the security realm displays (see Figure 26-80).

    Figure 26-80 Security Realm Settings Page

    Description of Figure 26-80 follows
    Description of "Figure 26-80 Security Realm Settings Page"

  4. Open the Providers tab and select the Authentication subtab.

    The Authentication Settings pane displays (see Figure 26-81).

    Figure 26-81 Authentication Settings Pane

    Description of Figure 26-81 follows
    Description of "Figure 26-81 Authentication Settings Pane"

  5. Click New.

    The Create a New Authentication Provider pane displays (see Figure 26-82).

    Figure 26-82 Create a New Authentication Provider Pane

    Description of Figure 26-82 follows
    Description of "Figure 26-82 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 the authentication provider you just created in the list of providers.

    The Settings page for the provider displays (see Figure 26-83).

    Figure 26-83 Provider Settings Page

    Description of Figure 26-83 follows
    Description of "Figure 26-83 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 26-84).

    Figure 26-84 Provider Specific Settings Pane

    Description of Figure 26-84 follows
    Description of "Figure 26-84 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 26-20 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...

26.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 in to WebCenter Spaces as an administrator and removing View access from the Public-User role. When public access is turned off, accessing the URL http://host:port/webcenter takes the user directly to the authenticated view rather than the default public page which has a login section. This is recommended when users are accessing WebCenter Spaces only using Internet Explorer, and are confined to the domain where WNA is set up.

  • If you must 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, users see the login page after clicking the Login link.

26.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, ensure that it has been configured to use the same identity store LDAP as WebCenter Spaces, as described in Section 24.5.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