32 Configuring Framework Applications for Single Sign-on

This chapter describes how to configure WebCenter Portal: Framework applications for single sign-on (SSO). All of the configurations described in this chapter assume that you have already configured SSO as described in Section 31, "Configuring Single Sign-on."

This chapter includes the following sections:

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

32.1 Configuration Overview

Oracle WebCenter Portal supports single sign-on (SSO) for the following SSO solutions for WebCenter Portal: Framework applications:

  • OAM 10g

  • OAM 11g

  • OSSO

  • SAML SSO (Framework application as a destination application)

  • SAML SSO (Framework application as the source application)

Before a Framework application can participate in single sign-on, in addition to the SSo configuration described in Chapter 31, "Configuring Single Sign-on," you must also configure the Framework application itself for the chosen SSO solution. To do this, follow the instructions in Chapter 32, "Single Sign-on Prerequisites," and then continue with the steps for your particular solution. The only exception to this is for SAML SSO, where the Framework application is acting as the source application where all the steps, including the prerequisites, are covered in Section 32.6.2, "Configuring SAML SSO for a Source Framework Application."

32.2 Single Sign-on Prerequisites

All Framework applications participating in SSO need to have certain common configurations in place regardless of the single sign-on solution used to protect the application. The only exception to this is for SAML SSO where the Framework application is acting as the source application (see Section 32.6.2, "Configuring SAML SSO for a Source Framework Application" for more information).

The common single sign-on prerequistes are covered in the following subsections:

32.2.1 Adding CLIENT-CERT in web.xml

All SSO solutions use an identity asserter configured on the WLS domain that asserts the type of assertion that an SSO configuration provides. For example, for OAM, it asserts based on the ObSSOCookie or OAM_REMOTE_USER header; for SAML SSO it asserts a SAML assertion.

For an asserter to assert identity, the application must specify CLIENT-CERT as its authentication method in its login configuration. Consequently, your application's web.xml file must have CLIENT-CERT specified as the auth-method as shown in the following example:

<login-config>
    <auth-method>CLIENT-CERT,FORM</auth-method>

Note that in Weblogic, you can specify comma-seperated authentication methods. In this example, if the SSO assertion is not available (CLIENT-CERT), then the application will fall back to FORM-based authentication.

32.2.2 Setting the Cookie Path for JSESSIONID

For SSO setups, Oracle recommends that you set an application cookie path. You can do this in WLS by editing the weblogic.xml file and adding the following entry:

  <session-descriptor>
    <cookie-path>/customportal</cookie-path>
  </session-descriptor>

where customportal is the context root of your application.

32.2.3 Determining the Public and Protected URIs for Your Application

An SSO configuration involves specifying the public and protected URIs of your application. Some SSO solutions, like OSSO and SAML SSO, require only the protected URIs to be specified. The following list shows the typical protected and public URIs for a Framework application:

Public URI:

/<app-context-root>

Protected URI:

/<app-context-root>/adfAuthentication

You can determine the protected URIs for your application by checking the security-constraint node of the web.xml file as shown in the following example:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>adfAuthentication</web-resource-name>
      <url-pattern>/adfAuthentication</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>valid-users</role-name>
    </auth-constraint>
  </security-constraint>

Note that the entries in the security-constraint node are always relative to the application context root. In this example, this security constraint translates to /app-context-root/adfAuthentication. If there were another security constraint specified, /admin for example, then that would translate to /app-context-root/admin.

32.2.4 Implications of Embedded Login

Framework applications typically use a form-based login mechanism where a login page is configured in the login-config section of the web.xml configuration file (note that there is no separate login configuration file). Applications can also embed a login area in the page template, or a provide landing page. This usually submits the users credentials to j_security_check for authentication. For SSO, however, authentication must be done through an SSO login challenge.

32.2.5 Handling Logout

The ADF Authentication Servlet is equipped to handle logout for all SSO solutions, and your application's logout should invoke the ADF Authentication Servlet for logout. To do this, modify the navigation rule for successful logout in your application's faces-config.xml file as shown in the example below:

<navigation-case>
      <from-outcome>logout_success</from-outcome>
      <to-view-id>/adfAuthentication?logout=true&amp;end_url=/</to-view-id>
      <redirect/>
</navigation-case>

The end_url parameter for /adfAuthentication can be any URL that you want to direct the user to after a successful logout. For example, specifying / would take the user to the application's default page.

32.3 Configuring the WebTier

If your environment has a WebTier front-ending your enterprise applications you'll need to configure it for SSO. The WebTier is required for OAM and OSSO solutions, and is used in a SAML SSO solution when Content Server is involved.

  1. Add a mapping for your application in mod_wl_ohs.conf as shown in the example below:

    <Location /customportal>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
    

    where customportal is the context root of your application.

  2. Restart the Oracle HTTP Server.

32.4 Configuring Framework and Portlet Producer Applications for OAM

This section describes how to configure your WebCenter Portal: Framework or WebCenter Portal: Portlet Producer application for OAM 10g and 11g. Prior to following the steps in this section you should already have followed the instructions in Section 31.2, "Configuring Oracle Access Manager (OAM)" to set up SSO for Spaces and related applications. You should also have completed the configurations in Section 32.2, "Single Sign-on Prerequisites."

Note:

Prior to starting, you should already have configured the required OAM Asserter and Authenticator pointing to the identity store LDAP used by OAM in the domain where your Framework application is deployed. If you have not done this, follow the instructions in Section 31.2, "Configuring Oracle Access Manager (OAM)" before starting.

This section includes the following subsections:

32.4.1 Configuring Framework Applications for OAM 10g

This section describes how to configure a Framework application for single sign-on using OAM 10g. Prior to configuring your application you should already have completed the OAM installation and configuration as described in Section 31.2, "Configuring Oracle Access Manager (OAM)."

To configure a Framework application for OAM 10g:

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

    http://host:port/access/oblix

  2. Click Policy Manager.

  3. Locate the policy domain that you created to protect your WebCenter Portal resources.

  4. Open the Resources tab and click Add.

  5. Add the resources. For each resource:

    1. Select HTTP as the Resource Type.

    2. Select the Host Identifier for the WebCenter Portal Web Tier.

    3. Enter the URL Prefix (/<app-context-root>) for the application.

    4. Enter a Description for the resource.

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

  6. Repeat step 5 to add /<app-context-root>/adfAuthentication as a resource.

  7. Go to the Policies tab and locate the public policy.

  8. Open the policy and select the resource created in step 5 (i.e., /<app-context-root>).

  9. Save your changes.

  10. Restart the WebTier and test your changes.

32.4.2 Configuring Portlet Producer Applications for OAM 10g

This section describes how to configure Portlet Producer applications for single sign-on using OAM 10g. Prior to configuring your Portlet Producer application follow the steps in Section 32.4.1, "Configuring Framework Applications for OAM 10g," then complete the steps below.

To configure a Portlet Producer application for OAM 10g:

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

    http://host:port/access/oblix

  2. Click Policy Manager.

  3. Locate the policy domain that you created to protect your WebCenter Portal resources.

  4. Open the Resources tab and click Add.

  5. Select HTTP as the Resource Type.

  6. Select the Host Identifier for the WebCenter Portal WebTier.

  7. Enter the URL Prefix (/<app-context-root/portlets>) for the application.

  8. Enter a Description for the resource.

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

  10. Go to the Policies tab and locate the Exclusion Scheme policy and select the newly created Portlet Producer resource for this policy.

  11. Open the policy and select the resource created in step 5 (i.e., /<app-context-root>/portlets).

  12. Save your changes.

  13. Restart the WebTier and test your changes.

32.4.3 Configuring Framework Applications for OAM 11g

This section describes how to configure a Framework application for single sign-on using OAM 11g. Prior to configuring your application you should already have completed the OAM installation and configuration as described in Section 31.2, "Configuring Oracle Access Manager (OAM)."

To configure a Framework application for OAM 11g:

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

    http://host:port/oamconsole

  2. Go to Policy Configuration > Application Domains.

    The Policy Manager pane displays.

  3. Locate the application domain you created using the name used when registering the WebGate agent.

  4. Open the Resources tab and click New Resource.

  5. Add the resources for the Framework application. For each resource:

    1. Select HTTP as the Resource Type.

    2. Select the Host Identifier created while registering the WebGate agent.

    3. Enter the Resource URL (/<app-context-root>*) for the application.

    4. Enter a Description for the resource.

    5. Set the Protection Level to Unprotected.

    6. Set the Authentication Policy to Public Resource Policy.

    7. Set the Authorization Policy to Protected Resource Policy.

    8. Click Apply.

  6. Repeat step 5 to add /<app-context-root>/.../* as a resource.

  7. Add /<app-context-root>/adfAuthentication* as a resource:

    1. Select HTTP as the Resource Type.

    2. Select the Host Identifier created while registering the WebGate agent.

    3. Enter the Resource URL (/<app-context-root>/adfAuthentication*) for the application.

    4. Enter a Description for the resource.

    5. Set the Protection Level to Protected.

    6. Set the Authentication Policy to Protected Resource Policy.

    7. Set the Authorization Policy to Protected Resource Policy.

    8. Click Apply.

  8. Restart the WebTier and test your changes.

32.4.4 Configuring Portlet Producer Applications for OAM 11g

This section describes how to configure Portlet Producer applications for single sign-on using OAM 11g. Prior to configuring your Portlet Producer application follow the steps in Section 32.4.3, "Configuring Framework Applications for OAM 11g," then complete the steps below.

To configure a Portlet Producer application for OAM 11g:

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

    http://host:port/access/oblix

  2. Click Policy Manager.

  3. Locate the policy domain that you created to protect your WebCenter Portal resources.

  4. Open the Resources tab and click Add.

  5. Select HTTP as the Resource Type.

  6. Select the Host Identifier created while registering the WebGate agent.

  7. Enter the URL Prefix (/<app-contextroot>/portlets/.../*) for the application.

  8. Enter a Description for the resource.

  9. Set the Protection Level to Excluded, and then click Save.

  10. Restart the WebTier and test your changes.

32.5 Configuring Framework Applications for OSSO

This section describes how to configure your WebCenter Portal: Framework application for OSSO. Prior to following the steps in this section you should already have followed the instructions in Section 31.3, "Configuring Oracle Single Sign-On (OSSO)" to set up SSO for Spaces and related applications. You should also have completed the configurations in Section 32.2, "Single Sign-on Prerequisites."

Note:

Prior to starting, you should already have configured the required OSSO Asserter and Authenticator pointing to the identity store (OID) used by OSSO in the domain where your Framework application is deployed. If you have not done this, follow the instructions Section 31.3, "Configuring Oracle Single Sign-On (OSSO)" before starting.

To configure a Framework application for OSSO:

  1. Locate and open the mod_osso.conf file in OHS.

  2. Add the following entry for your Framework application to the other similar entries:

    <Location /<app-context-root>/adfAuthentication>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
    </Location>
    
  3. Restart OHS.

32.6 Configuring Framework Applications for SAML SSO

This section describes how to set up SAML SSO for Framework applications. Note that SAML single sign-on is only recommended for smaller environments (a department, for example) where no enterprise SSO solution is available.

The steps are divided into two scenarios:

  • Scenario 1: A Framework application as a destination application

    This is the default SAML SSO behaviour provided by the WebCenter Portal SAML SSO scripts, where the Spaces application is the source application and all other applications are destination applications (that is, you need to be logged into Spaces for single sign-on with other destination applications to work).

  • Scenario 2: A Framework application as a source application

    This behaviour is not supported by the WebCenter Portal SAML SSO scripts and requires manual configuration. In this instance you want your Framework application to act as the SAML source, and other applications (including Spaces) to act as destination applications (that is, your Framework application is the first point of access and you need to be logged into it for single sign-on with other destination applications to work.

These two approaches to configuring SAML for Framework applications is described in the following subsections:

32.6.1 Configuring SAML SSO for a Destination Framework Application

Prior to following the steps in this section, you should already have completed the prerequisites and steps in Section 31.4, "Configuring SAML-based Single Sign-on" that describe how to set up SSO for Spaces and related applications. The steps in this section supplement that setup with configuration steps for your Framework application.

In this scenario, the Spaces application continues to act as the source application with your new Framework application participating in single sign-on as a destination application (that is, if you are logged into Spaces, when you access one of your Framework application's protected URIs, you are automatically logged in). If you are not already logged into Spaces and you access a protected URI, you will be directed to the Spaces login page and then redirected back to your application's secure page.

The steps below assume that:

  • Your Framework application is deployed in the Spaces domain where the configureSpaces.py script was run. If your Framework application is in a different domain, then you'll need to create a SAMLIdentityAsserterV2 ID Asserter in the WLS Administration console (security realm > providers > authenticator) and restart WLS. You then need to export the certificate used in your SAML SSO setup and register it under the SAML identity asserter you created.

  • The steps and example parameter values below assume you are using the demoidentity certificate. If you are using a different certificate, change the certificate name where appropriate.

  • If a WebTier is part of the configuration, the host and port IDs are those of the WebTier host and WebTier port.

This section includes the following subsections:

32.6.1.1 Enabling the Destination Site

To enable the destination site for your Framework application:

  1. Log onto the WLS Administration Console for the Spaces domain.

  2. Select Servers > [ServerHostingPortalApp] > Configuration > Federation Services > SAML 1.1 Destination Site.

  3. Enter the parameters for the destination site as shown in Table 32-1:

    Table 32-1 Destination Site Parameters

    Parameter Value Description

    Destination Site Enabled

    Selected

    Specifies whether the destination site is enabled.

    ACS Requires SSL

    Unselected

    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

    /<app-context-root>/samlacs/acs

    (add on top, leave the rest as is)

    The Assertion Consumer URIs. In this case, we have chosen for the ACS to reside within the target application so that it uses the same login cookie.

    POST Recepient Check Enabled

    Selected

    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

    Selected

    Specifies whether the POST one-use check is enabled.


  4. Save your changes, leaving the rest as their default values.

  5. Restart the server hosting the Framework application.

32.6.1.2 Configuring a Relying Party

To configure a relying party for your Framework application:

  1. Log onto the WLS Administration Console for the Spaces domain.

  2. Select Security Realms > Providers > Credential Mapping > wcsamlcm > Management > Relying Parties.

  3. Create a new relying party using the the parameters in Table 32-2:

    Table 32-2 Relying Party Parameters

    Parameter Value Description

    Profile

    Browser/POST

    The SAML profile used by this SAML Relying Party.

    Enabled

    Selected

    The state of this SAML Relying Party.

    Description

    Framework application

    A short description of this Relying Party

    Target URL

    http://host:port/<app-context-root>

    The destination site URL for which authentication is requested.

    Assertion Consumer URL

    http://host:port/<app-context-root>/samlacs/acs

    The URL at which an Assertion Consumer Service for this SAML Relying Party can be reached. 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_0000X

    The X points to ID of the asserting party you will create in next step.

    Sign Assertions

    Selected

    Specifies whether generated assertions for this SAML Relying Party are signed.

    Include KeyInfo

    Selected

    Indicates whether a <ds:keyinfo> element containing the signing certificate should be included when signing assertions. Default value is true. This value is ignored if Sign Assertions is false.


  4. Save your changes, leaving the rest as their default values.

32.6.1.3 Configuring an Asserting Party

To configure an asserting party for your Framework application:

  1. Log onto the WLS Administration Console for the Spaces domain.

  2. Select Security Realms > Providers > Authentication > wcsamlia > Management > Asserting Parties.

  3. Create a new asserting party using the the parameters in Table 32-3:

    Table 32-3 Asserting Party Parameters

    Parameter Value Description

    Profile

    Browser/POST

    The SAML profile used with this partner.

    Enabled

    Selected

    Specifies whether this Asserting Party can be used to obtain SAML assertions

    Description

    Spaces

    A short description of this Asserting Party

    Target URL

    http://host:port/webcenter

    The target URL of this SAML asserting party.

    POST Signing Certificate alias

    demoidentity

    The alias of the certificate trusted for verifying signatures on SAML protocol elements from this asserting party. Must be set for Browser/POST profile.

    Source Site Redirect URIs

    /<app-context-root>/adfAuthentication

    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: Due to this setting, when you access the destination site first, you are redirected to the ITS url configured which in this case is within the source app, your session is established source app and then redirected to the destination site.

    Source Site ITS URL

    http://host:port/webcenter/samlits/its

    The Intersite Transfer Service (ITS) URL of the SAML Source Site for this asserting party.Use this with SSO profiles only, to support the destination site as the first access point scenario, whereby a user trying to access a destination site URL prior to being authenticated 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, then you need to change Source Site ITS URL to use HTTPS and the server's SSL port.

    Source Site ITS parameters

    RPID=rp_0000X

    Replace the X with the ID of the relying party you created previously.

    Issuer URI

    http://www.oracle.com/webcenter

    The issuer URI of the SAML Authority issuing assertions for this SAML asserting party.

    Signature Required

    Selected

    If true, assertions must be signed. If false, signature elements are not required, but will be verified if present.

    Assertion Signing Certificate alias

    demoidentity

     

  4. Save your changes, leaving the rest as their default values.

  5. Continue by testing that single sign-on works as expected.

32.6.2 Configuring SAML SSO for a Source Framework Application

In this scenario the Framework application acts as the source application and other applications (like Spaces) are the destinations. For configurations that include Content Server, prior to completing the configurations in this section you should have followed the relevant steps in Section 31.4.2.1.1, "Configuring Oracle Content Server for SAML SSO."

The steps below are based on the following assumptions:

  • The WebCenter Portal SAML SSO scripts have not been run. The scripts configure Spaces to act as the source application, so these steps should be done manually.

  • You are using the default demoidentity certificate and you have already exported the certificate from the domain hosting your Framework application into demoidentity.der.

  • Your Framework application is /customportal.

  • For configurations that include Content Server and if a WebTier is part of the configuration, the host and port IDs are those of the WebTier host and WebTier port.

This section contains the following subsections:

32.6.2.1 Protecting SAML ITS

In the web.xml file of your Framework application, add the following entry after the entry for protecting /adfAuthentication:

<security-constraint>
    <web-resource-collection>
      <web-resource-name>samlits</web-resource-name>
      <url-pattern>/samlits/its</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>valid-users</role-name>
    </auth-constraint>
  </security-constraint>

32.6.2.2 Setting the Cookie Path for JSESSIONID

For SSO setups, Oracle recommends that you set a cookie path to the context root of your application. You can do this in WLS by editing the weblogic.xml file and adding the following entry:

<session-descriptor>
    <cookie-path>/customportal</cookie-path>
  </session-descriptor>

where customportal is the context root of your application.

32.6.2.3 Setting the SSO Property to True

Since the Spaces application now acts as a destination application, you need to hide the login area on the Spaces landing page. To do this, set the following property in your setDomainEnv file and restart the WC_Spaces server for the changes to take effect.

EXTRA_JAVA_PROPERTIES="-Doracle.webcenter.spaces.osso=true ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES

32.6.2.4 Configuring the SAML Credential Mapping Provider

In the security realm of the domain hosting your Framework application, create a SAML Credential Provider V2 (SAMLCredentialMapperV2) instance. Note that the SAML Credential Mapping provider is not part of the default security realm. Configure the SAML Credential Mapping provider as a SAML authority, using the Issuer URI, Name Qualifier, and other attributes as shown in Table 32-4:

Table 32-4 SAML Credential Mapping Provider Parameters

Parameter Value Description

Issuer URI

http://www.oracle.com/webcenter

The Issuer URI (name) of this SAML Authority. This unique URI tells the destination site (owc_wiki) the origin of the SAML message and allows it to match it with the key. Typically, the URL is used to guarantee uniqueness.

Name Qualifier

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

Signing Key Alias

demoidentity

The alias used to retrieve from the keystore the key that is used to sign assertions.

Signing Key Passphrase

DemoIdentityPassPhrase

The credential (password) used to retrieve from the keystore the keys used to sign assertions.


Save your changes, accepting the defaults for the rest of the parameters, and restart all of WLS.

32.6.2.5 Configuring a Relying Party

You'll need to configure relying parties for each of the destination applications. The steps below show you how to do using Spaces as an example. For other applications, refer to Table 32-10 in Section 32.6.2.9, "Configuring Other Destination Applications," and modify the highlighted values appropriately using the steps below as a reference.

To configure a relying party for Spaces:

  1. Log onto the WLS Administration Console for the Spaces domain.

  2. Select Security Realms > RealmName > Providers > Credential Mapping > SAMLCredentialMapperName > Management > Relying Parties.

  3. Create a new relying party using the the parameters in Table 32-5:

    Table 32-5 Spaces Parameters for Relying Party

    Parameter Value Description

    Profile

    Browser/POST

    The SAML profile used by this SAML Relying Party.

    Enabled

    Selected

    The state of this SAML Relying Party.

    Description

    Spaces

    A short description of this Relying Party

    Target URL

    http://host:port/webcenter

    The destination site URL for which authentication is requested.

    Assertion Consumer URL

    http://host:port/webcenter/samlacs/acs

    The URL at which an Assertion Consumer Service for this SAML Relying Party can be reached. 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_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.

    For a POST profile, these parameters will be included as form variables when using the default POST form. In this case, ap_00001 indicates the ID of the asserting party for your Framework application (customportal), which we will configure later in the SAML Identity Asserter of the domain hosting the Framework application, and which provides the source site and ITS details.

    Sign Assertions

    Selected

    Specifies whether generated assertions for this SAML Relying Party are signed.

    Include KeyInfo

    Selected

    Indicates whether a <ds:keyinfo> element containing the signing certificate should be included when signing assertions. Default value is true. This value is ignored if Sign Assertions is false.


  4. Save your changes, leaving the rest as their default values.

32.6.2.6 Configuring the Source Site Federation Services

To configure the source site Federation:

  1. Log onto the WLS Administration Console for the Spaces domain.

  2. Select Environment > Servers > ServerHostingCustomPortal > Configuration > Federation Services >SAML 1.1 Source Site.

  3. Configure the SAML source site attributes as shown in Table 32-6.

    Table 32-6 Source Site Federation Services Parameters

    Parameter Value Description

    Source Site Enabled

    Selected

    Allow the WebLogic server instance to serve as a SAML source site by setting Source Site Enabled to true.

    Source Site URL

    http://host:port/customportal

    Set the URL for the SAML source site. This is the URL that hosts the Intersite Transfer Service and Assertion Retrieval Service. The source site URL is encoded as a source ID in hex and Base64.

    Signing Key Alias

    demoidentity

    The SAML source site requires a trusted certificate with which to sign assertions. Add this certificate to the keystore and enter the credentials (alias and passphrase) to be used to access the certificate. The server's SSL identity key/certificates will be used by default if a signing alias and passphrase are not supplied.

    Signing Key Passphrase

    DemoIdentityPassPhrase

    The SAML source site requires a trusted certificate with which to sign assertions. Add this certificate to the keystore and enter the credentials (alias and passphrase) to be used to access the certificate. The server's SSL identity key/certificates will be used by default if a signing alias and passphrase are not supplied.

    Intersite Transfer URIs

    /customportal/samlits/its

    (Add on top, leave the rest as is.)

    Specify the URIs for the Intersite Transfer Service and (to support Browser/Artifact profile) the Assertion Retrieval Service. These URIs are also specified in the configuration of an Asserting Party.

    Assertion Retrieval URIs

    /customportal/samars/ars

    (Add on top, leave the rest as is.)

    Applicable only when Artifact profile is used for REST.

    ITS Requires SSL

    Deselected

    If you select this, then you need to change the Source Site ITS URL specified in the SAML Asserting party configuration in SAML Identity provider as HTTPS and the server's SSL port.

    ARS Requires SSL

    Deselected

    Applicable only when Artifact profile is used


  4. Save your changes, leaving the rest at their default values.

  5. Restart the server hosting the Framework application.

32.6.2.7 Configuring the SAML Identity Assertion Provider

To configure the SAML identity assertion provider:

  1. Log onto the WLS Administration Console for the Spaces domain.

  2. Create a SAML Identity Assertion Provider V2 instance as described in Section 32.6.1.3, "Configuring an Asserting Party," restarting all of WLS after saving your changes.

  3. Log back onto the WLS Administration Console and go to Security Realms > RealmName > Providers > Authentication > SAMLIdentityAsserterName > Management > Certificates.

  4. Configure a certificate for the SAML identity asserter:

  5. Configure a certificate for the SAML identity asserter using the values shown in Table 32-7.

    Table 32-7 Identity Asserter Certificate Parameters

    Parameter Value Description

    alias

    demoidentity

    Name you would you like to assign to your new certificate.

    Path

    WEBLOGIC_HOME/server/lib/demoidentity.der

    Specify the path name of a .pem or .der file containing the X509 certificate you wish to import.


  6. Go to Security Realms > RealmName > Providers > Authentication > SAMLIdentityAsserterName > Management > Asserting Parties.

  7. Create a new asserting party using the the parameters in Table 32-8. Use the same profile you chose for the corresponding relying party in Section 32.6.2.5, "Configuring a Relying Party."

    Table 32-8 Asserting Parties Parameters

    Parameter Value Description

    Profile

    Browser/POST

    The SAML profile used with this partner.

    Enabled

    Selected

    Specifies whether this Asserting Party can be used to obtain SAML assertions

    Description

    Framework application for Spaces

    A short description of this Asserting Party

    Target URL

    http://host:port/customportal

    The target URL of this SAML asserting party.

    POST Signing Certificate alias

    demoidentity

    The alias of the certificate trusted for verifying signatures on SAML protocol elements from this asserting party. Must be set for Browser/POST profile.

    Source Site Redirect URIs

    /webcenter/adfAuthentication

    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: This setting, when you access the destination site first, redirects you to the ITS URL configured (which in this case is within the source application), your session is established for the source application, and you are then redirected to the destination site.

    Source Site ITS URL

    http://host:port/customportal/samlits/its T

    The Intersite Transfer Service (ITS) URL of the SAML Source Site for this asserting party.Use this with SSO profiles only, to support the destination site as the first access point scenario, whereby a user trying to access a destination site URL prior to being authenticated 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, then you need to change 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 Spaces as specified in the SAML Credential Mapping provider of the WLS domain for the Framework application that provides the destination site details.

    Issuer URI

    http://www.oracle.com/webcenter

    The issuer URI of the SAML Authority issuing assertions for this SAML asserting party.

    Signature Required

    Selected

    If true, assertions must be signed. If false, signature elements are not required, but will be verified if present.

    Assertion Signing Certificate alias

    demoidentity

    The alias of the certificate trusted for verifying signatures on assertions from this Asserting Party. This must be set if Signature Required is true. The certificate must also be registered in the SAML Identity Asserter's certificate registry.


  8. Save your changes, leaving the rest at their default values.

32.6.2.8 Configuring the Destination Site Federation Services

To configure the destination site federation services:

  1. From the WLS Administration Console, go to WC Domain > WC_Spaces > Configuration > Federation Services > SAML 1.1 Destination Site [Spaces]

  2. Configure the SAML destination site attributes using the values in Table 32-9.

    Table 32-9 Destination Site Parameters

    Parameter Value Description

    Destination Site Enabled

    Selected

    Specifies whether the Destination Site is enabled.

    ACS Requires SSL

    Deselected

    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 the target server's SSL port.

    Assertion Consumer URIs

    /webcenter/samlacs/acs

    /rss/samlacs/acs

    /rest/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 application so that it uses the same login cookie.

    POST Recepient Check Enabled

    Selected

    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

    Selected

    Specifies whether the POST one-use check is enabled.


  3. Save your changes, leaving the rest at their default values.

  4. Restart the Spaces server.

32.6.2.9 Configuring Other Destination Applications

If you want applications other than Spaces to act as destination applications for your Framework application, then perform the following steps:

  1. Ensure you have the SAML ID asserter and certificate registered in each domain that hosts destination applications (refer to steps 1 - 5 of section Section 32.6.2.7, "Configuring the SAML Identity Assertion Provider").

  2. Create a relying party for your destination application in the WLS domain hosting your Framework application as you did for Spaces in Section 32.6.2.5, "Configuring a Relying Party." See Table 32-10 for appropriate values for each application.

  3. In your destination application's WLS domain, create a corresponding asserting party similar to what you did for Spaces. Use the steps for creating an asserting party in Section 32.6.2.7, "Configuring the SAML Identity Assertion Provider." Be sure to set the source redirect URI appropriately to the secure URI for your destination application. See Table 32-10 for appropriate values for each application.

  4. Ensure your asserting and relying parties are enabled and point to each other appropriately. That is, the Source Site ITS parameters in the asserting party and the Assertion Consumer Properties in the relying party point to each other appropriately.

  5. Ensure you have enabled destination site federation services for the server hosting your destination application, and have added entries for /yourdestinationapp/samlacs/acs similar to what you did for the WC_Spaces server in as you did in Section 32.6.2.8, "Configuring the Destination Site Federation Services." See Table 32-10 for appropriate values for each application.

    Table 32-10 Settings for Destination Applications Other than Spaces

    Destination Application Target URL (Relying Party) ACS URL (Relying Party) ACS URI (DestinationSiteFederationServices) Source Redirect URI (Asserting Party)

    RSS

    http://host:port/rss

    http://host:port/rss/samlacs/acs

    /rss/samlacs/acs

    /rss/rssservlet

    REST

    http://host:port/rest

    http://host:port/rest/samlacs/acs

    /rest/samlacs/acs

    /rest/api/resourceIndex

    Discussions

    http://host:port/owc_discussions

    http://host:port/owc_discussions/samlacs/acs

    /owc_discussions/samlacs/acs

    /owc_discussions/admin/forum-main.jsp

    /owc_discussions/admin/content-main.jsp

    /owc_discussions/login!withRedirect.jspa

    /owc_discussions/login!default.jspa

    /owc_discussions/login.jspa

    ActivityGraph Engines

    http://host:port/activitygraph-engines

    http://host:port/activitygraph-engines/samlacs/acs

    /activitygraph-engines/samlacs/acs

    /activitygraph-engines/index.jsp

    Content Server

    http://host:port

    http://host:port/samlacs/acs

    /samlacs/acs

    /adfAuthentication

    Worklist Detail

    http://host:port/workflow/WebCenterWorklistDetail

    http://host:port/workflow/WebCenterWorklistDetail/samlacs/acs

    /WebCenterWorklistDetail/samlacs/acs

    /workflow/WebCenterWorklistDetail/faces/adf.task-flow

    Worklist SDP

    http://host:port/workflow/sdpmessagingsca-ui-worklist

    http://host:port/workflow/sdpmessagingsca-ui-worklist/samlacs/acs

    /sdpmessagingsca-ui-worklist/samlacs/acs

    /workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow

    Worklist Integration

    http://host:port/integration/worklistapp

    http://host:port/integration/worklistapp/samlacs/acs

    /worklistapp/samlacs/acs

    /integration/worklistapp/ssologin

    /integration/worklistapp/faces/home.jspx