Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Portal
11g Release 1 (11.1.1.7.0)

Part Number E12405-19
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

32 Configuring Single Sign-on

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

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 Introduction to Single Sign-on

Single sign-on can be implemented for WebCenter Portal applications (Spaces and Framework applications) using several solutions. This section describes their benefits and recommended application.

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 Spaces and Framework applications. OAM (in particular, OAM 11g) is the recommended single sign-on solution for Oracle WebCenter Portal 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 Portal 11g can also be configured to use OSSO for single sign-on.

For non-production, development environments 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 Spaces and its associated Web applications like Discussions, and Worklist, you can configure a SAML-based SSO solution. If you need to provide single sign-on for other enterprise applications as well, 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.

32.2 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 Spaces and Framework applications for OAM single sign-on authentication, including how to configure the WebLogic server side and the WebCenter Portal application as the partner application participating in SSO. Note that for Framework applications some additional configurations are required, as described in Section 33.4, "Configuring Framework and Portlet Producer Applications for OAM."

The installation and configuration steps for OAM 11g and 10g are presented in the following subsections:

32.2.1 OAM Components and Topology

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

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

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

OAM Single Sign-on Process Flow

Figure 32-2 shows the single sign-on process flow for OAM.

Figure 32-2 OAM Single Sign-on Process Flow

Description of Figure 32-2 follows
Description of "Figure 32-2 OAM Single Sign-on Process Flow"

SSO Log-in Processing with OAM Agents

  1. The user requests a resource.

  2. The WebGate forwards the request to OAM for policy evaluation.

  3. OAM:

    • Checks for the existence of an SSO cookie.

    • Checks policies to determine if the resource protected and if so, how?

  4. The OAM server logs and returns decisions.

  5. WebGate responds as follows:

    • Unprotected resource: resource is served to the user.

    • Protected resource:

      • Request is redirected to the credential collector

      • The login form is served based on the authentication policy

      • Authentication processing begins

  6. User sends credentials.

  7. OAM verifies credentials.

  8. OAM starts the session and creates the following host-based cookies:

    • One per partner: OAMAuthnCookie set by 11g WebGates (ObSSOCookie set by 10g WebGate) using the authentication token received from the OAM server after successful authentication.

      Note: A valid cookie is required for a session.

    • One for OAM Server: OAM_ID

  9. OAM logs Success or Failure.

  10. OAM Credential collector redirects to WebGate and authorization processing begins.

  11. WebGate prompts OAM to look up policies, compare them to the user's identity, and determine the user's level of authorization.

  12. OAM logs policy decision and checks the session cookie.

  13. OAM Server evaluates authorization policies and cache the result.

  14. OAM Server logs and returns decisions

  15. WebGate responds as follows:

    • If the authorization policy allows access, the request get redirected to mod_wl which in turn redirects the request to the WLS server where the Spaces application is running, and from where desired content or applications are served to the user, as shown below:

      WebGate -> mod_wl -> Spaces [, Discussion, .. etc] --> Content is server to the authenticated user

    • If the authorization policy denies access, the user is redirected to another URL determined by the administrator.

32.2.2 Roadmap to Configuring OAM

The flow chart (Figure 32-3) and table (Table 32-1) in this section provide an overview of the prerequisites and tasks required to configure single sign-on for WebCenter Portal using OAM.

Figure 32-3 Configuring Single Sign-on for WebCenter Portal Using OAM

Description of Figure 32-3 follows Step 1 - Install and configure OAM Step 2 - Install and configure OAM Step 1a - Configure the OID authenticator Step 1b - Configure the OAM Identity Asserter Step 1c - Configure the default authenticator and provider order Step 1d - Add an OAM SSO provider Step 2 - Install and configure OHS Step 3 - Perform additional relevant configuration Step 3a - Configure WebCenter Spaces for SSO Step 3b - Configure the discussions server for SSO Step 3c - Configure the Worklist service for SSO Step 3d - Configure OAM for RSS feeds using external readers Step 3e - Configure the WLS Admin Console and Enterprise Manager for OAM Step 3f - Configure Oracle Content Server or OAM Step 3g - Restrict access using connection filters Step 4 - Test your OAM installation
Description of "Figure 32-3 Configuring Single Sign-on for WebCenter Portal Using OAM"

Table 32-1 shows the tasks and sub-tasks for configuring single sign-on for WebCenter Portal using OAM.

32.2.3 Installing and Configuring OAM

This section describes how to install and configure either OAM 11g or OAM 10g, the recommended single sign-on solutions for WebCenter Portal installations.

Note:

Installing OAM should be performed only after you've installed Oracle WebCenter Portal (described in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter Portal) and any other components required for your environment. You should also have configured and tested any required connections.

This section includes the following subsections:

32.2.3.1 Installing and Configuring OAM 11g R1

This section describes how to install and configure OAM 11g, and includes the following subsections:

32.2.3.1.1 Installing and Configuring OAM 11g

Install Oracle Access Manager (OAM) as described in "Installing and Configuring Oracle Identity Management (11.1.1.7.0)" in the Oracle Fusion Middleware Quick Installation Guide for Oracle Identity Management. Ideally, OAM and all the applications that participate in single sign-on should share the same identity store. By default, OAM uses the embedded LDAP identity store.

To configure OAM to use an external identity store, such as OID, see "Registering a New User Identity Store" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service. This section has pointers to setting the external identity store configured as the default or system store and configuring one or more authentication modules to point to this store. By default, the WebCenter policy configured in OAM uses the default authentication scheme (typically, the form-based authentication scheme LDAPScheme) specified in OAM,. If you intend to use the default scheme, the authentication module used by the scheme must point to the same identity store as your WebCenter installation. Optionally, you can choose to configure a different authentication scheme rather than the default, in which case you must also ensure that it points to the identity store used by WebCenter. Continue by configuring Oracle Access Manager in a WebLogic administration domain as described in "Configuring Oracle Access Manager" in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

32.2.3.1.2 Installing and Configuring the Oracle HTTP Server

If you don't already have Oracle HTTP Server (OHS) installed, install OHS (11.1.1.4.0) as described in Section 32.2.5, "Installing and Configuring the Oracle HTTP Server."

If you do have an existing installation, you will need to apply a patch to bring it up to OHS (11.1.1.4.0) as described in "Applying the Latest Oracle Fusion Middleware Patch Set" in the Oracle Fusion Middleware Patching Guide.

After installing or patching OHS, continue by installing the WebGate as described in Section 32.2.3.1.3, "Installing the WebGate on the WebTier."

32.2.3.1.3 Installing the WebGate on the WebTier

This section describes how to install and configure the OHS WebGate.

Note:

Ensure that your Oracle HTTP server is down while installing OHS WebGate, and restart it only after you register the WebGate agent as described in Section 32.2.3.1.4, "Registering the WebGate Agent."

  1. Install the WebGate as described in the section on "Installing and Configuring Oracle HTTP Server 11g WebGate for Oracle Access Manager" in the Oracle Fusion Middleware Installing Webgates for Oracle Access Manager. Use the same Middleware home that was specified during OHS install.

  2. After installing Oracle HTTP Server 11g WebGate for Oracle Access Manager, move to the following directory under your Oracle Home for Webgate:

    For Unix operating systems:

    <Webgate_Home>/webgate/ohs/tools/deployWebGate
    

    For Windows operating systems:

    <Webgate_Home>\webgate\ohs\tools\deployWebGate
    
  3. From the command line, run the following command to copy the required bits of the agent from the Webgate_Home directory to the WebGate instance location:

    For Unix operating systems:

    ./deployWebGateInstance.sh -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home>
    

    For Windows operating systems:

    deployWebGateInstance.bat -w <Webgate_Instance_Directory> -oh <Webgate_Oracle_Home>
    

    Where <Webgate_Oracle_Home> is the directory where you have installed Oracle HTTP Server WebGate and defined it as the Oracle Home for WebGate, as in the following example:

    <MW_HOME>/Oracle_OAMWebGate1
    

    The <Webgate_Instance_Directory> is the location of the Webgate Instance Home (which should be the same as the Instance Home of Oracle HTTP Server), as in the following example:

    <MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1
    

    Note that an Instance Home for Oracle HTTP Server is created after you configure the Oracle HTTP Server. This configuration should be performed after installing or patching to Oracle HTTP Server 11.1.1.4.0.

  4. Run the following command to ensure that the LD_LIBRARY_PATH variable contains <Oracle_Home_for_Oracle_HTTP_Server>/lib:

    For Unix operating systems (depending on the shell):

    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<Oracle_Home_for_Oracle_HTTP_Server>/lib
    

    For Windows operating systems:

    Add the <Webgate_Installation_Directory>\webgate\ohs\lib and <Oracle_Home_for_Oracle_HTTP_Server>\bin locations to the PATH environment variable. Add a semicolon (;) followed by this path at the end of the entry for the PATH environment variable.

  5. From your current working directory, move to:

    For Unix operating systems:

    <Webgate_Home>/webgate/ohs/tools/setup/InstallTools
    

    For Windows operating systems:

    <Webgate_Home>\webgate\ohs\tools\EditHttpConf
    
  6. From the command line, run the following command to copy the apache_webgate.template from the Webgate_Home directory to the WebGate Instance location (renaming it to webgate.conf) and update the httpd.conf file to add one line to include the name of webgate.conf file:

    For Unix operating systems:

    ./EditHttpConf -w <Webgate_Instance_Directory> [-oh <Webgate_Oracle_Home>] [-o <output_file>]
    

    For Windows operating systems:

    EditHttpConf.exe -w <Webgate_Instance_Directory> [-oh <Webgate_Oracle_Home>] [-o <output_file>]
    

    Note:

    The -oh <WebGate_Oracle_Home> and -o <output_file> parameters are optional.

    Where <Webgate_Oracle_Home> is the directory where you have installed Oracle HTTP Server WebGate and defined it as the Oracle Home for WebGate, as in the following example:

    <MW_HOME>/Oracle_OAMWebGate1
    

    The <Webgate_Instance_Directory> is the location of the Web Gate instance home (which should be the same as the instance home of OHS), as in the following example:

    <MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1
    
32.2.3.1.4 Registering the WebGate Agent

After installing the WebGate on the WebTier, you also need to register the WebGate agent. The steps below will automatically create a protected policy that uses the default Authentication Scheme that is configured in your OAM installation (typically, the form-based authentication scheme LDAPScheme). If you want to customize WebCenter Portal's single sign-on login page, or want WebCenter Portal resources to be protected by some other authentication scheme, then change it using the OAM Console (see "Managing Authentication Schemes" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for more information).

Note:

If you are using WebCenter Portal in conjunction with other applications in your environment, and you require single sign-on for these applications, you must ensure that the authentication schemes used by these applications are either the same or at least at the same level and point to the same identity store.

For more information about registering the WebGate agent, see also "Getting Started with a New Oracle HTTP Server 11g WebGate" in the Oracle Fusion Middleware Installing Webgates for Oracle Access Manager.

Follow the steps below to register the WebGate agent on the machine where OAM is installed using the oamreg tool in inband mode:

  1. Change directories to <RREG_Home>/input (where <RREG_Home> is the directory to where you extracted the contents of RREG.tar.gz/rreg).

  2. Copy over $WEBCENTER_HOME/webcenter/scripts/webcenter.oam.conf from the WebCenter Portal installation here.

    The default location for WEBCENTER_HOME is $ORACLE_HOME/Oracle_WC1.

  3. Copy over $SOA_HOME/soa/prov/soa.oam.conf and $WC_CONTENT_ORACLE_HOME/common/security/oam.conf from the SOA and Content Server installations respectively.

    The default location for SOA_HOME is $ORACLE_HOME/Oracle_SOA1 and the default location for WC_CONTENT_ORACLE_HOME is $ORACLE_HOME/Oracle_ECM1.

  4. Create a new file named WebCenterOAM11gRequest.xml to serve as a parameter file to the oamreg tool.

    In the example below, replace the contents within $$webtier..$$ with your WebTier host and port IDs, and $$oam...$$ with the OAM host and administration server port.

    <?xml version="1.0" encoding="UTF-8"?>
    
    <!--
     Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
    
       NAME: OAM11GRequest_short.xml - Template for OAM 11G Agent Registration Request file
             (Shorter version - Only mandatory values - Default values will be used for all other fields)
       DESCRIPTION: Modify with specific values and pass file as input to the tool.
    -->
    <OAM11GRegRequest>
        <serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
        <hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier>
        <agentName>$$webtierhost$$_webcenter</agentName>
        <logOutUrls>
            <url>/oamsso/logout.html</url>
        </logOutUrls>
    </OAM11GRegRequest>
    
  5. Change directories to <RREG_Home>.

  6. Run the following command:

    <RREG_Home>/bin/oamreg.sh inband input/WebCenterOAM11gRequest.xml
    
    • When prompted for agent credentials enter your OAM administrator credentials.

    • Enter your WebGate password.

    • Enter yes when asked whether you want to import a URIs file. Specify the full path to the <RREG_HOME>/input/webcenter.oam.conf file you copied there earlier.

      You should see output like that below indicating that registration has been successful:

      ----------------------------------------
      Request summary:
      OAM11G Agent Name:example_webcenter
      URL String:example_webcenter
      Registering in Mode:inband
      Your registration request is being been sent to the Admin server at: http://example.com:7001
      ----------------------------------------
      Inband registration process completed successfully! Output artifacts are created in the output folder.
      
  7. Copy the generated files and artifacts (ObAccessClient.xml and cwallet.sso) from <RREG_Home>/output/$$webtierhost$$_webcenter to your WebGate instance configuration directory (<Webgate_Instance_Directory>/webgate/config). Note that <Webgate_Instance_Directory> should match the instance home of OHS, as in the following example:

    <MW_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config
    
  8. Change directories to <RREG_Home>/input.

  9. If you have SOA or WebCenter Content Server installed

    1. Create a policy update file called WebCenterOAM11gPolicyUpdate.xml as shown in the example below, replacing the contents within $$webtier..$$ with your WebTier host and port IDs, and $$oam...$$ with the OAM host and administration server port as you did earlier:

      <?xml version="1.0" encoding="UTF-8"?>
      
      <!--
       Copyright (c) 2009, 2011, Oracle and/or its affiliates. All rights reserved.
      
         NAME: UpdatePolicyRequest.xml - Template for updating application domain and/or policies without changes to any agent profile
         DESCRIPTION: Modify with specific values and pass file as input to the tool
      -->
      <PolicyRegRequest>
      
          <serverAddress>http://$$oamhost$$:$$oamadminserverport$$</serverAddress>
          <hostIdentifier>$$webtierhost$$_webcenter</hostIdentifier>
          <applicationDomainName>$$webtierhost$$_webcenter</applicationDomainName>
      
      </PolicyRegRequest>
      
    2. Run the following command:

      <RREG_Home>/bin/oamreg.sh policyUpdate input/WebCenterOAM11gPolicyUpdate.xml
      

      Enter your OAM credentials when prompted. Enter yes when asked whether you want to import a URIs file, and specify <RREG_HOME>/input/soa.oam.conf.

      Your policy will be updated with SOA resources.

    3. Run the policyUpdate command again, this time specifying <RREG_HOME>/input/oam.conf to update the policy with Content Server resources. Your policy now contains WebCenter Portal, SOA and Content Server artifacts.

  10. From the OAM Console, you should now be able to see the following artifacts:

    • 11g WebGate agent named $$webtierhost$$_webcenter

    • 11g host identifier by the same name

    • an application domain with the same name containing authentication and authorization policies which in turn contain protected and public policies

  11. Go to Application Domain> $$webtierhost$$_webcenter > Authentication Policies. You should be able to see the following policies:

    • Exclusion Scheme

    • Protected Resource Policy

    • Public Resource Policy

    • WebCenter REST Policy

  12. Open the WebCenter REST Policy and make sure that the Authentication Scheme is set to BasicSessionlessScheme or BasicScheme.

  13. Open the Resources tab and search for resources with their Authentication Policy set to Exclusion Scheme. You should see the following resources:

    • /rsscrawl*

    • /rsscrawl/.../*

    • /sesUserAuth*

    • /sesUserAuth/.../*

    • /services-producer/portlets*

    • /services-producer/portlets/.../*

    • /wsrp-tools/portlets

    • /wsrp-tools/portlets/.../*

  14. Select the /rsscrawl* resource in the search results and click Edit.

  15. Change the Protection Level from Protected to Excluded and click Apply. Note that the resource's authentication policy and authorization policy is removed.

  16. Close the Resources tab and repeat the steps for the remaining Exclusion Scheme resources.

    When you now search for resources with their Authentication Policy set to Exclusion Scheme you should see no results.

  17. Restart OHS.

  18. After installing and configuring the WebTier and associated components, continue by configuring the Policy Manager as described in Section 32.2.4, "Configuring the WebLogic Domain for OAM," and performing any additional service and component configurations that apply as described in Section 32.2.6, "Additional Single Sign-on Configurations."

32.2.3.2 Installing and Configuring OAM 11g R2

Installing and configuring OAM 11g R2 requires some additional steps to those described in Section 32.2.3.1, "Installing and Configuring OAM 11g R1." Note that OAM 11g R2 only supports OHS 11.1.1.5.0 and 11.1.1.6.0.

  1. Install OAM 11g R2 as described in "Installing and Configuring Oracle Identity and Access Management (11.1.2)" in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

  2. Run the configureSecurityStore.py script to configure the Database Security Store as described in the section on "Configuring Database Security Store for an Oracle Identity and Access Management Domain" in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

  3. Install OHS 11.1.1.5.0 or 11.1.1.6.0 as described in "Installing and Configuring Oracle HTTP Server 11g Webgate for Oracle Access Manager" in the Oracle Fusion Middleware Installing Webgates for Oracle Access Manager.

32.2.3.3 Installing and Configuring OAM 10g

This section describes how to install and configure OAM 10g, and includes the following subsections:

32.2.3.3.1 Installing and Configuring OAM 10g

If you don't already have Oracle Access Manager (OAM) 10g installed, install OAM 10g as described in the Oracle Access Manager Installation Guide.

32.2.3.3.2 Installing and Configuring the Oracle HTTP Server

If you don't already have Oracle HTTP Server (OHS) installed, install OHS (11.1.1.4.0) as described in Section 32.2.5, "Installing and Configuring the Oracle HTTP Server."

If you do have an existing installation, you will need to apply a patch to bring it up to OHS (11.1.1.4.0) as described in "Applying the Latest Oracle Fusion Middleware Patch Set" in the Oracle Fusion Middleware Patching Guide.

After installing or patching OHS, continue by installing the WebGate as described in Section 32.2.3.3.3, "Configuring the WebCenter Portal Policy Domain."

32.2.3.3.3 Configuring the WebCenter Portal Policy Domain

These steps assume that you've installed Oracle WebCenter (see WebCenter Portal). By default, an Oracle WebCenter Portal installation creates a WebLogic Server domain, including an Administration Server and four managed servers: WC_Spaces, WC_Collaboration, WC_Utilities, and WC_Portlet.

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

  2. Check that OraDefaultExclusionAuthNScheme is available in your OAM 10g installation. If it does not exist, create the OraDefaultExclusionAuthNScheme as shown below:

    1. Open the OAM Access System Console.

    2. Click Authentication Management.

    3. Click Add.

    4. Specify OraDefaultExclusionAuthNScheme in the Name field.

    5. Enter To exclude resources from being protected by OAM in the Description field.

    6. Enter 0 in the Level field.

    7. Specify None in the Challenge Method field.

    8. Add unprotected:true to the Challenge Parameter field.

    9. Click Save.

    10. Open the Plugins tab for this authentication scheme and click Modify.

    11. Select credential_mapping from the drop down list.

    12. Specify a value as:

      obMappingBase="dc=us,dc=oracle,dc=com",obMappingFilter="(uid=OblixAnonymous)"

      Make sure that this value matches the corresponding field for the OraDefaultAnonAuthNScheme.

    13. Click Save.

    14. Open the General tab again and click Modify.

    15. Check Yes for Enabled.

    16. Click Save.

  3. Run the following command.

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

    java -jar ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
    mode=CREATE app_domain=<your_domain_name>
    uris_file=WEBCENTER_HOME/webcenter/scripts/webcenter.oam.conf"
    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.

  4. If your instance also contains a SOA installation, then run oamcfgtool again to protect the SOA URIs in the policy domain you created in the previous step. Use the same parameters as the ones used in the previous step so that the existing policy domain is updated with URIs in the soa.oam.conf file.

    java -jar ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
    mode=CREATE app_domain=<your_domain_name>
    uris_file="SOA_HOME/soa/prov/soa.oam.conf"
    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>
    
  5. If your installation includes Content Server, then you also need to protect these URIs. Use the same parameters as the ones used in the previous steps so that the existing policy domain is updated with the URIs in the Content Server's oam.conf file.

    java -jar ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
    mode=CREATE app_domain=<your_domain_name>
    uris_file="WC_CONTENT_ORACLE_HOME/common/security/oam.conf"
    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>
    
  6. 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 that were specified as part of the webcenter.oam.conf script file. You should also see the URIs from the SOA and Content Server OAM configuration files if you have run the oamcfgtool from SOA and Content Server domains.

    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.

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

  8. Locate the policy domain that you created and verified in the previous steps and open the Policies tab.

    You should see four policies already created:

    • WebCenter REST Policy

    • Exclusion Scheme

    • Protected_JSessionId_Policy

    • Default Public Policy

  9. Select WebCenter REST Policy, then select Authentication Rule and click Modify.

  10. Change the AuthenticationScheme to OraDefaultBasicAuthNScheme (from OraDefaultFormAuthNScheme)

  11. Go to Exclusion Scheme policy > Authentication Rule and check that it uses OraDefaultExclusionAuthNScheme (created in the previous steps) as the AuthenticationScheme.

  12. Click Save.

  13. Open the Policies tab and make sure that the polices are in the order shown below:

    Protected_JSessionId_Policy
    WebCenter REST Policy
    Exclusion Scheme
    Default Public Policy
    
  14. Continue with the steps for installing the WebGate as described in Section 32.2.3.3.4, "Installing the WebGate 10g on the WebTier."

32.2.3.3.4 Installing the WebGate 10g 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. For more information, refer to the chapter on "Installing the WebGate" in the Oracle Access Manager Installation Guide.

  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.

  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.

  5. After installing and configuring the WebGate 10g, continue by configuring the Weblogic domain as described in Section 32.2.4, "Configuring the WebLogic Domain for OAM," and performing any additional service and component configurations that apply as described in Section 32.2.6, "Additional Single Sign-on Configurations."

32.2.4 Configuring the WebLogic Domain for OAM

If your environment spans multiple domains (for example, a domain for Spaces, a separate domain for SOA, and a separate domain for Content Server), repeat the steps in this section for each domain.

This section includes the following subsections:

32.2.4.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.13.2, "Oracle WebLogic Server Administration Console."

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

    The Summary of Security Realms pane displays.

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

    The Settings pane for the realm displays.

  4. Open the Providers tab.

    The Provider Settings display.

  5. Click New to create a provider.

    The Create a New Authentication Provider pane displays.

  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.

  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.

  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 should be the same as for the 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

    Use Retrieved User Name as Principal

    Checked

    User login IDs are usually case insensitive. This flag is required so that the subject established contains the user name as stored in the OID.


  11. Click Save.

32.2.4.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.13.2, "Oracle WebLogic Server Administration Console."

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

    The Summary of Security Realms pane displays.

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

    The Settings pane for the realm displays.

  4. Open the Providers tab.

    The Provider Settings display.

  5. Click New to create a provider.

    The Create a New Authentication Provider pane displays.

  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.

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

  9. Click Save to save you settings.

32.2.4.3 Configuring the Default Authenticator and 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.

  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

  5. Continue by configuring Spaces for single sign-on mode as described in Section 32.2.6.1, "Configuring WebCenter Portal: Spaces for SSO." Also be sure to perform any further service and component configurations that apply to your environment as described in Section 32.2.6, "Additional Single Sign-on Configurations."

32.2.4.4 Adding an OAM Single Sign-on Provider

After checking that the default authenticator's control flag is set correctly, and that the order of the providers is correct, add an OAM SSO provider and restart all servers as described below.

Note:

This is required for OAM 11g, but is only required for OAM 10g if the logout URI has been explicitly configured.

  1. Connect to the WebLogic domain using WLST and run the following command:

    addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", logouturi="/oamsso/logout.html")
    
  2. Restart all servers.

32.2.5 Installing and Configuring the Oracle HTTP Server

This step is common to both OAM 10g and OAM 11g, and should be performed after installing and configuring OAM, and before configuring the WebLogic domain.

To install and configure the Oracle HTTP server (OHS).

  1. If you do not have already have an OHS install you'd like to use, install the Oracle HTTP Server (11.1.1.4.0) using the instructions in the section on "Installing and Configuring Oracle Web Tier" in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier. If you do have an existing installation, you will need to apply a patch to bring it up to OHS (11.1.1.4.0) as described in "Applying the Latest Oracle Fusion Middleware Patch Set" in the Oracle Fusion Middleware Patching Guide.

  2. Configure WebTier OHS so that it forwards requests to the Oracle WebLogic Server for WebCenter Portal using the following example in mod_wl_ohs.conf. Make sure that the WebLogic port numbers match your configuration. For more information, see "Installing and Configuring Oracle HTTP Server 11g Webgate for OAM" in Oracle Fusion Middleware Installing Webgates for Oracle Access Manager.

    Note:

    This example assumes that WebCenter Portal is a non-cluster based installation. For a clustered environment change the WebLogicHost and WebLogicPort to WeblogicCluster as required for your environment. See the section on "Installing and Configuring Oracle HTTP Server 11g Webgate for OAM" in Oracle Fusion Middleware Installing Webgates for Oracle Access Manager for details.

    # NOTE : This is a template to configure mod_weblogic. 
     
    LoadModule weblogic_module   "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"
     
    # This empty block is needed to save mod_wl related configuration from EM to this file when changes are made at the Base Virtual Host Level
    <IfModule weblogic_module>
    #      WebLogicHost <WEBLOGIC_HOST>
    #      WebLogicPort <WEBLOGIC_PORT>
    #      Debug ON
    #      WLLogFile /tmp/weblogic.log
    #      MatchExpression *.jsp
     
    <Location /webcenter>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /webcenterhelp>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /rss>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /rest>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /rsscrawl>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
    
    <Location /sesUserAuth>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
    
    <Location /owc_discussions>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8890
    </Location>
     
    <Location /activitygraph-engines>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8891
    </Location>
     
    <Location /wcps>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8891
    </Location>
     
    <Location /workflow>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /integration/worklistapp>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /integration/services>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /soa-infra>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /sdpmessaging/userprefs-ui>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /DefaultToDoTaskFlow>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /cs>
          SetHandler weblogic-handler
          WebLogicHost ucm.example.com
          WebLogicPort 16200
    </Location>
     
    <Location /adfAuthentication>
          SetHandler weblogic-handler
          WebLogicHost ucm.example.com
          WebLogicPort 16200
    </Location>
    
    <Location /pagelets>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8889
    </Location>
    
    <Location /services-producer>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8889
    </Location>
     
    <Location /wsrp-tools>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8889
    </Location>
     
    </IfModule>
     
    # <Location /weblogic>
    #      SetHandler weblogic-handler
    #      PathTrim /weblogic
    #      ErrorPage  http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
    #  </Location>
    

    Note:

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

32.2.6 Additional Single Sign-on Configurations

The configurations described in the following sections may be necessary or helpful in providing additional security for your site. After completing these configurations, continue by testing your OAM installation as described in Section 32.2.7, "Testing Your OAM Installation."

32.2.6.1 Configuring WebCenter Portal: Spaces for SSO

Configure the Spaces application for SSO by adding a setting to EXTRA_JAVA_PROPERTIES.

There is a system property that tells WebCenter Portal 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 Portal 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, and add an entry like the following:

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

After making this change, restart the WC_Spaces server.

32.2.6.2 Configuring the Discussions Server for SSO

This section describes how to configure Oracle WebCenter Portal's Discussion Server 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 Spaces, as described in Section 30.1, "Reassociating the Identity Store with an External LDAP Server." If you've chosen not to move the default administrator account to an external LDAP, be sure to also follow the instructions in Section 30.4.1, "Migrating WebCenter Portal's Discussions Server to Use an External LDAP."

Note:

Direct login to the discussions server is not supported after SSO is configured. Log in must be done through the Oracle HTTP Server URL.

To set up the discussions server for SSO:

  1. Log in to the Oracle WebCenter Portal's Discussion Server Server Admin Console at:

    http://host:port/owc_discussions/admin
    

    Where host and port are the host ID and port number of the WC_Collaboration 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 WebTier. For example:

    jiveURL = webtier.example.com:7777/owc_discussions
    

    The jiveURL property is used when constructing links to forums in emails.

    Note:

    The discussion server connection that is registered for the Spaces application should point to the Oracle HTTP Server URL.

32.2.6.2.1 Creating a Discussions Server Connection for Spaces

This section describes how to update the discussions server connection for Spaces so that it uses the WebTier's host and port values. Note that the steps below assume that the Discussions service has already been installed and configured in the WebCenter Portal domain.

  1. Using Fusion Middleware Control or WLST, change the discussion server's URL host and port settings from the WC_Spaces Managed Server's settings, to the WebTier's host and port settings. For information about how to change these settings, see Section 14.5, "Modifying Discussions Server Connection Details."

  2. Restart the WC_Spaces Managed Server.

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

32.2.6.3 Configuring the Worklist Service for SSO

Assuming that you've already set up a Worklist connection, modify the URL to use the WebTier host and port instead of the SOA server host and port. You can do this using Fusion Middleware Control or using WLST commands as described in Section 23.4, "Setting Up Worklist Connections."

After modifying the URL and completing the setup required for OAM SSO, run the following command on the WebCenter Portal Administration server so that the Worklist service changes take effect:

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

32.2.6.4 Configuring OAM for RSS Feeds Using External Readers

By default, WebCenter Portal RSS feeds are protected by SSO. However, they will not work well with external readers if left protected. If access using external readers is important, Oracle recommends that the WebCenter Portal RSS resource be excluded from the OAM policy so that the authentication for the RSS Servlet is handled by WebLogic Server's BASIC authentication that external readers can handle.

This section contains the following subsections:

32.2.6.4.1 Unprotecting RSS Feeds in OAM 11g

Follow the steps below to unprotect RSS feed for OAM 11g:

  1. Open the OAM Admin Console.

  2. Open the Policy Configuration tab and select Application Domain > <your application domain>.

  3. Open the Resources tab and search for /rss*.

    Among the results, you should see:

    /rss*

    /rss/.../*

    /rss/rssservlet*

    /rss/rssservlet/.../*

  4. For each resource, select the resource and click Edit.

  5. Change each resource's Protection Level from Protected to Excluded and click Apply.

    Note that the resource's authentication policy and authorization policy are removed.

  6. Close the tab and restart OHS.

32.2.6.4.2 Unprotecting RSS Feeds in OAM 10g

Follow the steps below to unprotect RSS feed for OAM 10g:

  1. Open the OAM Admin Console.

  2. Select Access System Console > Policy Manager and open the applicable policy domain.

  3. Open the Policies tab, select the Exclusion Scheme policy, and click Modify.

  4. Select the following resources for exclusion:

    /rss

    /rss/rssservlet

  5. Click Save.

  6. Select Default Public Policy and click Modify.

  7. Uncheck the /rss resource and click Save.

  8. Restart OHS.

32.2.6.5 Configuring the WebLogic Server Administration Console and Enterprise Manager for OAM 10g

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 OAM 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 32-4).

    Figure 32-4 Policy Manager Pane

    Description of Figure 32-4 follows
    Description of "Figure 32-4 Policy Manager Pane"

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

  4. Open the Resources tab and click Add.

    The Resource page displays (see Figure 32-5).

    Figure 32-5 Policy Domain Resource Page

    Description of Figure 32-5 follows
    Description of "Figure 32-5 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 Portal WebTier.

    3. Enter the URL Prefix for the WebLogic Server Administration Console (/console) or Enterprise Manager (/em).

    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, by adding two additional Location entries using the actual host ID for the WebCenter Portal Administration Server for WebLogicHost.

    <Location /console>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 7001
    </Location>
     
    <Location /em>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 7001
    </Location>
    
  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.

32.2.6.6 Configuring the WebLogic Server Administration Console and Enterprise Manager for OAM 11g

This section describes how to optionally set up OAM 11g 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 11g SSO for the WebLogic Server Administration Console and Enterprise Manager:

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

    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 while registering webgate agent.

  4. Expand the Resources node and click Create.

    The Resource page displays.

  5. Add the resources that must be secured. 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 for the WebLogic Server Administration Console (/console) or Enterprise Manager (/em).

    4. Enter a Description for the resource and click Apply.

  6. Go to Authentication Policies > Protected Resource Policy and add the newly created resource.

  7. Do the same under Authorization Policies > Protected Resource Policy>

  8. 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, by adding two additional Location entries using the actual host ID for the WebCenter Portal Administration Server for WebLogicHost.

    <Location /console>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 7001
    </Location>
     
    <Location /em>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 7001
    </Location>
    
  9. 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.

32.2.6.7 Configuring Secure Enterprise Search for SSO

The crawl sources that are defined to crawl WebCenter Portal data and repositories used by WebCenter Portal and the corresponding authentication end points defined in SES must be routed through the WebTier OHS ports so that they can be properly authenticated (the authentication method continues to be BASIC and realm jazn.com). For information about configuring SES connections, see Section 22.4, "Setting Up Oracle SES Connections."

32.2.6.8 Configuring Content Server for SSO

After you've completed your SSO setup, and after setting up a connection for Content Server, specify the web context root in the JCRContentServerConnection using Fusion Middleware Control, or as shown in the following WLST example:

setJCRContentServerConnection(appName, name, webContextRoot='/cs')

Setting the web context root tells the Document Library code that SSO has been set up. Note that this setting should not be set until after SSO has been completely set up.

32.2.6.9 Restricting Access with Connection Filters

Follow the steps below to only allow users to access WebCenter Portal 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.13.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.

  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 Portal through the OHS port:

    http://host:OHS_port/webcenter
    

32.2.6.10 Configuring Portlet Producers and Additional Components

If you have set up your Portlet Producer applications to route through OHS, be sure to use the OHS host and port when specifying producer URLs for registration. This applies to out of-the-box producers like wsrp-tools, services-producer, pagelet producers and any other producer you have explicitly configured.

32.2.7 Testing Your OAM Installation

After installing and configuring either OAM 10g or 11g, check that you can access all of the configured applications below (as they apply to your environment), and that the global login and logout is giving you access to all of your configured applications without prompting you to sign in again. Also test global logout where available and make sure you are logged out of all other related applications.

  • Spaces: Access any protected Spaces URL (a protected space, for example), and make sure that you see the SSO login challenge. If you are already logged into another related application that uses the same SSO, you should automatically be shown content.

  • REST: Access http://ohshost:ohsport/rest/api/resourceIndex. You should see the BASIC authentication challenge. If you are already logged into another related application that uses the same SSO, you should automatically be shown content.

  • REST: Access http://ohshost:ohsport/rest/api/cmis/.... (retrieve this from resourceIndex access output in the previous step). You should not see a login challenge and should be able to see public content. When you access this after you've logged in, then you should see all content to which you have access rights.

  • ActivityGraph Engines: Access http://host:port/activitygraph-engines. You should see an SSO login challenge. Once logged in, you should be able to see content.

  • Content Server: Go to the profile UI and check that you can see Content Server screens embedded in iFrames without challenging you to log in. You should also be able to access Site Studio content in Content Presenter templates without logging in as you are already logged into Spaces application.

  • SOA: Access links in a workflow task flow and make sure that you are not challenged to log in.

  • Discussion Forums: Access the Discussions application at http://host:port/owc_discussions and log in. Check that the login is the SSO login challenge. Similarly, the Administration login to the Discussions server at http://host:port/owc_discussions/admin should also go through the SSO login challenge.

32.3 Configuring Oracle Single Sign-On (OSSO)

In a default installation, WebCenter Portal uses the HTTP ports in the Managed Server created for WebCenter Portal. To configure WebCenter Portal applications with Oracle Single Sign-On, WebCenter Portal needs Oracle HTTP Server and the associated Module mod_osso to integrate with Oracle Single Sign-On (OSSO). Note that for Framework applications some additional configurations are required, as described in Section 33.5, "Configuring Framework Applications for OSSO."

Note:

The BPEL Console does not support SSO integration. When WebCenter Portal 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

32.3.1 Roadmap to Configuring OSSO

The flow chart (Figure 32-6) and table (Table 32-2) in this section provide an overview of the prerequisites and tasks required to configure single sign-on for WebCenter Portal using OSSO.

Figure 32-6 Configuring Single Sign-on for WebCenter Portal Using OSSO

Description of Figure 32-6 follows Step 1 - Configure the Oracle HTTP Server and associated modules Step 1a - Install the Web Tier Step 1b - Configure the module mod_wl in OHS Step 2 - Configure the OSSOIdentityAsserter Step 3 - Register OHS with Oracle SSO Step 4 - Perform additional configuration Step 4a - Configure WebCenter Spaces for SSO Step 4b - Restrict access to WebCenter and services Step 4c - Configure the discussions server for SSO
Description of "Figure 32-6 Configuring Single Sign-on for WebCenter Portal Using OSSO"

Table 32-2 shows the tasks and sub-tasks for configuring single sign-on for WebCenter Portal using OSSO.

32.3.2 OSSO Components and Topology

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

Figure 32-7 OSSO Components and Topology

Description of Figure 32-7 follows
Description of "Figure 32-7 OSSO Components and Topology"

32.3.3 Configuring the Oracle HTTP Server and Associated Modules

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

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

  1. Install the Oracle WebTier software, 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 Portal, replacing the host and port values with those for you local environment.

    Uncomment the lines at ${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so. This file is included by the httpd.conf file and looks like the following:

    # NOTE : This is a template to configure mod_weblogic. 
     
    LoadModule weblogic_module   "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"
     
    # This empty block is needed to save mod_wl related configuration from EM to this file when changes are made at the Base Virtual Host Level
    <IfModule weblogic_module>
    #      WebLogicHost <WEBLOGIC_HOST>
    #      WebLogicPort <WEBLOGIC_PORT>
    #      Debug ON
    #      WLLogFile /tmp/weblogic.log
    #      MatchExpression *.jsp
     
    <Location /webcenter>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /webcenterhelp>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /rss>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /rest>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /rsscrawl>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /sesUserAuth>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
    </Location>
     
    <Location /services-producer>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8889
    </Location> 
    
    <Location /wsrp-tools>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8889
    </Location> 
    
    <Location /owc_discussions>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8890
    </Location>
     
    <Location /activitygraph-engines>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8891
    </Location>
     
    <Location /wcps>
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8891
    </Location>
     
    <Location /workflow>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /integration/worklistapp>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /integration/services>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /soa-infra>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /sdpmessaging/userprefs-ui>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /DefaultToDoTaskFlow>
          SetHandler weblogic-handler
          WebLogicHost soa.example.com
          WebLogicPort 8001
    </Location>
     
    <Location /cs>
          SetHandler weblogic-handler
          WebLogicHost ucm.example.com
          WebLogicPort 16200
    </Location>
     
    <Location /adfAuthentication>
          SetHandler weblogic-handler
          WebLogicHost ucm.example.com
          WebLogicPort 16200
    </Location>
     
    </IfModule>
     
    
    # <Location /weblogic>
    #      SetHandler weblogic-handler
    #      PathTrim /weblogic
    #      ErrorPage  http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
    #  </Location>
    

32.3.4 Configuring the OSSOIdentityAsserter

Include the OSSO Identity Assertion Provider (IAP) provider in the Oracle WebLogic domain for WebCenter Portal. Use the WebLogic Server Administration Console to add the OSSO IAP to your domain as shown in the steps below. If your environment spans multiple domains (for example, a domain for Spaces, separate domain for SOA, and a separate domain for Content Server), repeat the steps in this section for each domain.

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.13.2, "Oracle WebLogic Server Administration Console."

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

    The Summary of Security Realms pane displays.

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

    The Settings pane for the realm displays.

  4. Click the Providers tab.

    The Provider Settings display.

  5. Click New to create a provider.

    The Create a New Authentication Provider pane displays.

  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 30, "Configuring the Identity Store."

    For OID, the provider list should appear as follows:

    • OSSOIdentityAsserter (OPTIONAL)

    • OracleInternetDirectoryAuthenticator (SUFFICIENT)

    • DefaultAuthenticator (SUFFICIENT)

    • DefaultIdentityAsserter (OPTIONAL)

32.3.5 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 FTP it in binary mode to the WebTier host (WT_ORACLE_HOME).

    The following example shows how you would register a remote partner application on a SSO Server. Check that the ORACLE_HOME environment variable is set (ORACLE_HOME here is the ORACLE_HOME of the OSSO installation on the SSO server) before running ssoreg.sh.

    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:80 -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. Copy the webtier.example.com.osso.conf file generated by ssoreg in step 1 to a location accessible in the WebTier other than the moduleconf directory (for example, WT_ORACLE_HOME).

    Note:

    If using FTP, be sure to transfer the file using binary mode.

  4. Add rules to the mod_osso.conf file to protect the /webcenter and related application resources URLs with Oracle SSO.

    The mod_osso.conf file should look similar to this:

    LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
    
    <IfModule osso_module>
        OssoIpCheck off
        OssoIdleTimeout off
        OssoSecureCookies Off
    
    #Point to proper osso.conf file. 
       OssoConfigFile /example.com.osso.conf
    #
    # Insert Protected Resources: (see Notes below for
    # how to protect resources)
    #
    #______-
    #
    # Notes
    #
    #______-
    #
    # 1. Here's what you need to add to protect a resource,
    #    e.g. <ApacheServerRoot>/htdocs/private:
    #
    #      <Location /private>
    #      require valid-user
    #      AuthType Osso
    #      </Location>
    
        <Location /webcenter/adfAuthentication*>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /services-producer/adfAuthentication*>
           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 /integration/worklistapp>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /sdpmessaging/userprefs-ui>
          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/api/resourceIndex>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/spaces>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/discussions>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/tags>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/taggeditems>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/activities>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/activitygraph>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/feedback>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/people>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/messageBoards>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /rest/api/searchresults>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /pagelets/admin>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /pagelets/authenticateWithApplicationServer*>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /activitygraph-engines>
          OssoSendCacheHeaders off
          require activity-graph-admins
          AuthType Osso
        </Location>
        <Location /wcps/api>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
        <Location /cs/groups>
           OssoSendCacheHeaders off
           require valid-user
           AuthType Osso
        </Location>
        <Location /cs/idcplg>
           OssoSendCacheHeaders off
           require valid-user
           AuthType Osso
        </Location>
       <Location /adfAuthentication>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
       </Location>
    </IfModule>
    
    #
    # To have short hostnames redirected to fully qualified
    # hostnames for clients that need authentication via
    # mod_osso to be able to enter short hostnames into their
    # browsers use a mod_rewrite configuration such as the following.
    #
    # e.g
    #RewriteEngine On
    #RewriteCond %{HTTP_HOST} !www.example.com
    #RewriteRule ^.*$
    http://%{SERVER_NAME}%{REQUEST_URI}
    [R]
    #where www.example.com is the fully qualified domain name. 
    

    Be sure to change the OssoConfigFile parameter to point to the location (and filename if you've changed it) where you copied your osso.conf file in the previous step. If your environment is non-SSL, then also be sure to turn off OSSO secure cookies (on by default):

    OssoSecureCookies Off

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

32.3.6 Additional Configurations

The configurations described in the following sections may be necessary or helpful in providing additional security for your site. For Framework applications the additional configurations described in Section 33.5, "Configuring Framework Applications for OSSO" are also required.

32.3.6.1 Configuring WebCenter Portal: Spaces for SSO

Complete the configuration for Oracle Single Sign-on (OSSO) for Spaces by adding a setting to EXTRA_JAVA_PROPERTIES and rebooting as described in Section 32.2.6.1, "Configuring WebCenter Portal: Spaces for SSO."

32.3.6.2 Restricting Access Using the WebTier OHS Ports

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

32.3.6.3 Configuring the Discussions Server for SSO

This section describes how to configure Oracle WebCenter Portal's Discussion Server 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 Spaces, as described in Section 30.4.1, "Migrating WebCenter Portal's Discussions Server to Use an External LDAP."

To set up the discussions server for SSO:

  1. Log in to the Oracle WebCenter Portal's Discussion Server Server Admin Console at:

    http://host:port/owc_discussions/admin
    

    Where host and port are the host ID and port number of the WC_Collaboration 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. Update the jiveURL property to point to the base URL of the WebTier.

32.3.6.4 Configuring the Worklist Service for SSO

After registering OHS with Oracle SSO, as shown in Section 32.3.5, "Registering OHS with Oracle SSO," run the following command on the WebCenter Portal Administration server so that the Worklist service changes to take effect:

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

32.3.6.5 Configuring Oracle Content Server for SSO

Since it's possible to access the Content Server repository directly from Spaces, you may also want to include it in the single sign-on configuration. Assuming that you've already set up a connection for the Content Server, specify the web context root in the JCRContentServerConnection using Fusion Middleware Control or using WLST as shown in the following example:

setJCRContentServerConnection(appName, name, webContextRoot='/cs')

For more information on how to configure the Content Server, see "Configuring Content Server to Use Single Sign-On" in the Oracle WebCenter Content System Administrator's Guide for Content Server.

32.3.6.6 Configuring OSSO for RSS Feeds Using External Readers

By default, WebCenter Portal RSS feeds are protected by SSO. However, they will not work well with external readers if left protected. If access using external readers is important, Oracle recommends that the WebCenter Portal RSS resource be unprotected so that the authentication for the RSS Servlet is handled by WebLogic Server's BASIC authentication that external readers can handle.

Follow the steps below to unprotect the RSS feeds:

  1. Remove the following entry from mod_osso.conf.

    <Location /rss/rssservlet>
          OssoSendCacheHeaders off
          require valid-user
          AuthType Osso
        </Location>
    
  2. Restart OHS.

32.3.6.7 Configuring SES Crawl for SSO

If you have SES configured for your instance, you can optionally update the WebCenter Portal Crawl and authentication end points to use the WebTier URL. See Chapter 22, "Managing Oracle Secure Enterprise Search in WebCenter Portal" for more information.

32.4 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 for all WebCenter Portal applications other than Pagelet Producer applications. 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 that since Pagelet Producer applications do not participate in SAML SSO, users are required to log in explicitly if they accesses the Pagelet Producer application. Note also that for Framework applications, some additional configurations are required as described in Section 33.6, "Configuring Framework Applications for SAML SSO."

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 if you set up SAML-based single sign-on with Spaces as the source application and Discussions as the destination application, administrators can access the Discussions administration pages from Spaces Administration (Configuration > Services) and Space Settings (Services page). However, since Discussions administration pages do not participate in SSO, if you access administration pages directly, you are required to log in to the Discussions server again.

Finally, SAML-based single sign-on is not available for the sdpmessaging userprefs-ui application. As an application administrator, if you click Manage Configuration in the Preferences > Messaging dialog in Spaces, you will need to log in again.

This SSO mechanism can be used for departmental WebCenter Portal installations for which there is no existing Oracle SSO or Oracle Access Manager single sign-on infrastructure, but single sign-on between only 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 WebCenter Portal: Spaces and the Worklist service running on different managed servers within the same domain.

This section includes the following subsections:

32.4.1 SAML Components and Topology

Figure 32-9 shows the components and their interaction in a SAML-based single sign-on configuration that includes Spaces and the Discussions 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 32-8 shows the components and flow for a POST-configured SAML SSO configuration that includes both a WebCenter Portal and SOA domain. The flow is similar for other destination applications participating in single sign-on such as Worklist applications and Discussions.

Figure 32-8 Detailed SAML Single Sign-on Components and Topology (POST Profile Configured)

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

Figure 32-9 shows a simplified version of the components and flow for a POST-configured SAML SSO configuration, including the SAML SSO flow between Spaces and the Discussions application.

Figure 32-9 SAML Single Sign-on Components and Topology (POST Profile Configured)

Description of Figure 32-9 follows
Description of "Figure 32-9 SAML Single Sign-on Components and Topology (POST Profile Configured)"

The steps in the flow are:

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

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

  3. If authentication is successful, the authenticated session is established, and the 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 Discussions service (destination site), hosted on a different WebLogic Server (WC_Collaboration) 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 Spaces application on the WC_Spaces Managed Server) that shares the same JSESSIONID cookie as Spaces.

  5. The ITS servlet calls the SAML Credential Mapper configured in the WebCenter Portal 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 Discussions 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 Discussions 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 Discussions service).

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

32.4.2 Configuring SAML-based Single Sign-on

This section describes how to configure Spaces and services for SAML-based single sign-on using a set of automated scripts.

This section includes the following subsections:

32.4.2.1 SAML Single Sign-on Prerequisites

This section describes a set of steps that should be carried out prior to configuring SAML-based single sign-on. Note that these steps assume that Spaces and associated components are already installed and the relevant connections have been configured and tested.

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

32.4.2.1.1 Configuring Oracle Content Server for SAML SSO

If your instance uses a Documents connection that requires the use of OHS to surface the Content Server user interface in WebCenter Portal, you need to configure WebCenter Portal and related applications with a WebTier.

When configuring SAML SSO for a configuration that includes Content Server, all HTTP URLs should point to the WebTier host and port. Additionally, when Content Server is front-ended with OHS, the following entries must appear in mod_wl_ohs.conf, apart from the usual configuration for WebCenter Portal:

<Location /cs>
      SetHandler weblogic-handler
      WebLogicHost ucm.example.com
      WebLogicPort 16200
</Location>
 
<Location /adfAuthentication>
      SetHandler weblogic-handler
      WebLogicHost ucm.example.com
      WebLogicPort 16200
</Location>
 
<Location /samlacs/acs>
      SetHandler weblogic-handler
      WebLogicHost ucm.example.com
      WebLogicPort 16200
</Location> 

See Section 32.2.5, "Installing and Configuring the Oracle HTTP Server" for more information about installing OHS and editing mod_wl_ohs.conf.

Additionally, when a custom login page is used for Spaces the following HTML comment must be added to the head section of the HTML page generated for Content Server for Site Studio Designer to work:

<!--IdcClientLoginForm=1-->

This HTML comment appears in the out-of-the-box log in pages in Spaces, but if you configure a new page to be the login page in a SAML SSO setup, then the comment must be added by hand, or in generated HTML as shown in the following example for a JSF page:

<af:document id="d1">
      <f:facet name="metaContainer">
          <f:verbatim>
            ${cb.commentText}
          </f:verbatim>
      </f:facet>
      .........

where cb is a managed bean containing the method:

public String getCommentText(){
      return "<!--IdcClientLoginForm=1-->";
    }

After checking that the comment text is added verbatim in the metaContainer facet of af:document, check the generated HTML page using View Source and confirm that <!--IdcClientLoginForm=1--> is in the <head> section of the HTML page.

32.4.2.1.2 Configuring the Discussions Server for SAML SSO

By default, the .EAR file that is deployed for the Oracle WebCenter Portal's Discussion Server Server supports form-based Oracle SSO or Oracle Access Manager SSO. Therefore, before you can configure the Oracle WebCenter Portal's Discussion Server Server for SAML-based single sign-on, you must also first 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 Spaces, as described in Section 30.1, "Reassociating the Identity Store with an External LDAP Server." If you've chosen not to move the default administrator account to an external LDAP, be sure to also follow the instructions in Section 30.4.1, "Migrating WebCenter Portal's Discussions Server to Use an External LDAP."

To deploy and configure the SAML SSO version of the Oracle WebCenter Portal's Discussion Server Server:

  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.13.2, "Oracle WebLogic Server Administration Console."

  2. In the Domain Structure pane, click Deployments.

    The Deployments Summary pane displays.

  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 32.2.6.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 its value to true.

  11. Restart the WC_Collaboration Managed Server (where the discussions server is deployed).

32.4.2.1.3 Configuring and Exporting the 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. Configure the necessary keystore for the WC_Spaces and Administration servers in the WebCenter Portal domain. This keystore should contain the certificate you intend to use for securing the SAML assertions.

    If you only want to test the configuration, you can either create a "demoidentity" certificate that is packaged in the DemoIdentity keystore that is configured by default, or you can use keytool to generate a new certificate in the DemoIdentity keystore. For more information about configuring a custom identity keystore, see Section 34.1.2, "Configuring the Custom Identity and Java Trust Keystores."

  2. Using keytool, export the certificate you have chosen to use to encrypt SAML assertions. Be sure to run the export command on the keystore that is configured for WC_Spaces and the Administration server for the Spaces domain.

    keytool -export -keystore <keystore_name> -storepass <keystore_password> -alias <certificate_alias> -keypass <certificate_password> -file <certificate.der>
    

    where:

    • keystore_name is the name of the keystore that is configured for WC_Spaces and the Administration server for the Spaces domain

    • keystore_password is the password of the keystore that is configured for WC_Spaces and the Administration server for the Spaces domain

    • certificate_alias is the alias name (for example, demoidentity)

    • certificate_password is the password for the certificate

    • certificate.der is the name of the certificate file

    Note that the keytool -export command should be run from the Spaces machine and should export the certificate being used in the SAML SSO setup residing in the keystore configured for the Spaces server.

  3. Copy or transfer the file into the destination domains (such as SOA, Content Server, and Collaboration) and configure the certPath value in the wcsamlsso.properties file when you are ready to run the SAML SSO script as described in Section 32.4.2.2.1, "The Single Sign-on Script."

32.4.2.1.4 Setting Up SSL

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

32.4.2.2 Configuring SAML-based SSO

After installing 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

This section includes the following subsections:

32.4.2.2.1 The Single Sign-on Script

The single sign-on script to configure SAML 1.1 SSO for Spaces and related applications is located in the $WC_ORACLE_HOME/webcenter/scripts/samlsso folder. The following files are relevant for SAML configuration:

wcsamlsso.properties

This properties file ($WC_ORACLE_HOME/common/bin/wcsamlsso.properties) 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, Spaces server and URL, and so forth, of the WebCenter Portal 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 Portal domain

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

  • adminURL - WebLogic Admin URL to connect to WLST

  • usesSSL - Indicates whether Spaces is configured to use SSL

  • url - WebCenter Portal URL. If usesSSL is "true", then change "http" to "https". If Spaces is front-ended with WebTier, then specify the WebTier host and port here.

  • serverName - Server where Spaces is deployed, typically WC_Collaboration

  • certAlias - Alias of certificate to sign SAML assertions

  • certPassword - Encrypted password of certificate to sign SAML assertions

collab_config

This section captures the login information, admin URL, certificate file path, and so forth, of the Collaboration domain required for the Identity Asserter and Destination Site Federation Services configuration. Only complete this section if your setup has 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 Discussions service is configured to use SSL

  • serverName - Server where Discussions is deployed (typically the WC_Collaboration Managed Server)

  • certAlias - Alias of certificate to verify SAML assertions

  • certPath - Path to exported certificate to verify SAML assertions. Note that the certificate path should be a valid path on the machine that hosts the domain (i.e., the one specified in adminURL)

utilities_config

This section captures the login information, admin URL, and certificate file path of the Utilities domain required for the Identity Asserter and Destination Site Federation Services configuration. Complete this section out only if your setup is configured with the Activity Graph application.

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

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

  • adminURL - WebLogic Admin URL to connect to WLST

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

  • serverName - Server where Utilities applications are deployed (typically the WC_Utilities Managed Server)

  • certAlias - Alias of certificate to verify SAML assertions

  • certPath - Path to exported certificate to verify SAML assertions. Note that the certificate path should be a valid path on the machine that hosts the domain (i.e., the one specified in adminURL)

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. Note that the certificate path should be a valid path on the machine that hosts the domain (i.e., the one specified in adminURL)

ucm_config

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

  • configFile - Config file containing the weblogic user name and password for the Content Server (UCM) domain

  • usesSSL - Indicates whether Content Server applications are configured to use SSL

  • keyFile - Key File to decrypt the weblogic user account and password for the Content Server (UCM) domain

  • adminURL - WebLogic Administration URL to connect to WLST

  • serverName - Server where Content Server applications are deployed (typically UCM_server1)

  • certPath - Path to exported certificate to verify SAML assertions. Note that the certificate path should be a valid path on the machine that hosts the domain (i.e., the one specified in adminURL)

rss_config

This is mandatory

  • url - RSS URL. If usesSSL in spaces_config is "true", then change "http" to "https". If RSS is front-ended with WebTier, then specify the WebTier host and port here.

rest_config

This section must be completed.

  • url - REST URL. If usesSSL in spaces_config is "true", then change "http" to "https". If REST is front-ended with WebTier, then specify the WebTier host and port here.

forum_config

Complete this section if your configuration has Discussions installed.

  • url - OWC Discussions URL. If usesSSL in collab_config is "true", then change "http" to "https". IF Discussions is front-ended with WebTier, then specify the WebTier host and port here.

worklist_config

Complete this section of SOA is installed and Worklist is configured for Spaces.

  • worklist_detail - Worklist Detail application URL. If usesSSL in soa_config is "true", then change "http" to "https". If Worklist Detail application is front-ended with WebTier, then specify the WebTier host and port here.

  • worklist_sdp - Worklist SDP application URL. If usesSSL in soa_config is "true", then change "http" to "https". If Worklist Detail application is front-ended with WebTier, then specify the WebTier host and port here.

  • worklist_integration - Worklist Integration application URL. If usesSSL in soa_config is "true", then change "http" to "https". If Worklist Detail application is front-ended with WebTier, then specify the WebTier host and port here.

activitygraph_config

Complete this section if your configuration has the Utilities server installed.

  • url - ActivityGraphEngines URL. If usesSSL in spaces_config is "true", then change "http" to "https". If the Activity Graph application is front-ended with WebTier, then specify the WebTier host and port here.

cs_config

Complete this section if your configuration has Content Server installed and you have a Documents service connection configured for the Spaces application.

  • url - Content Server URL. If usesSSL in spaces_config is "true", then change "http" to "https". If Content Server is front-ended with WebTier, then specify the WebTier host and port here. Note that if both Spaces and Content Server are configured for your environment, then they must both be accessed using the same WebTier.

wcsamlsso.py

Script file ($WC_ORACLE_HOME/common/wlst/wcsamlsso.py) that contains utility functions invoked by rest of the configuration scripts

configureSpaces.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureSpaces.py) to configure SAML 1.1 Credential Mapper, SAML 1.1 Identity Asserter and Source and Destination site federation services on the WebCenter Portal domain

configureCollab.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureCollab.py) to configure SAML 1.1 Identity Asserter and Destination site federation services on the Collaboration domain

configureUtilities.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureUtilities.py) to configure SAML 1.1 Identity Asserter and Destination site federation services on the Utilities domain

configureSOA.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureSOA.py) to configure SAML 1.1 Identity Asserter and Destination site federation services on the SOA domain

configureUCM.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureUCM.py) to configure SAML 1.1 Identity Asserter and Destination site federation services on the Content Server domain

configureREST.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureREST.py) to configure asserting and relying parties for the REST application

configureRSS.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureRSS.py) to configure asserting and relying parties for RSSapplication

configureForum.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureForum.py) to configure asserting and relying parties for the Discussions application

configureActivityGraphEngine.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureActivityGraphEngine.py) to configure asserting and relying parties for the Activity Graph Engine application

configureWorklistIntegration.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistIntegration.py) to configure asserting and relying parties for the Worklist Integration application

configureWorklistDetail.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistDetail.py) to configure asserting and relying parties for the Worklist Community Detail application

configureWorklistSDP.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureWorklistSDP.py) to configure asserting and relying parties for the Worklist SDP application

configureCS.py

Executable script ($WC_ORACLE_HOME/webcenter/scripts/samlsso/configureCS.py) to configure asserting and relying parties for the Content Server application.

32.4.2.2.2 Using the Scripts

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

Note:

If you encounter errors when running the scripts due to configuration errors, the SAML SSO configuration may be left in an incomplete state. The config scripts provided are not rerunnable; you must clean up the SAML SSO artifacts before you retry the configuration as described in Section 32.4.2.6, "Removing Your SAML SSO Configuration."

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

  2. Generate the config and key files containing the connection information for the various domains using the storeUserConfig WLST command from the $WC_ORACLE_HOME/common/bin so that the properties file is picked up. Use the command-line help (help('storeUserConfig')) for usage and syntax details.

    1. Connect using WLST to the WebCenter Portal 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 2a after connecting to the Collaboration domain using the admin username and password. Even if the Utilities server is in the same domain as Spaces (wc_domain), you must connect to the WebCenter Portal domain and run this command:

      storeUserConfig('collabconfig.secure', 'collabkeykey.secure')

    3. Repeat step 2a after connecting to the Utilities domain using the admin username and password. Even if the Utilities server is in the same domain as Spaces (wc_domain), you must connect to the WebCenter Portal domain and run this command:

      storeUserConfig('utilitiesconfig.secure', 'utilitieskey.secure')

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

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

    5. Repeat step 2a after connecting to the Content Server domain using the admin username and password.

      storeUserConfig('ucmconfig.secure', 'ucmkey.secure')

  3. 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 Portal domain, ensure that you run the encryption utility from the WebCenter Portal domain.

  4. Edit $WC_ORACLE_HOME/common/bin/wcsamlsso.properties and complete the sections applicable to your setup. Refer to Section 32.4.2.2.1, "The Single Sign-on Script" for a detailed description of the sections in the properties file.

  5. Launch WLST from $WC_ORACLE_HOME/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('<wc_oracle_home>/webcenter/scripts/samlsso/configureSpaces.py')

      Restart all servers including the Administration server in the WebCenter Portal domain.

    2. If you have a discussions server set up, execute the configureCollab.py script:

      execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureCollab.py')

      If Discussions belongs to the same domain as Spaces, then only restart the WC_Collaboration Managed Server. Otherwise, restart all servers including the Administration server in the Collaboration domain.

    3. If you have a Utilities server set up, execute the configureUtilities.py script:

      execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureUtilities.py')

      If the Utilities server belongs to the same domain as Spaces, then only restart the WC_Utilities server. Otherwise, restart all servers including the Administration server in the Utilities domain.

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

      execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureSOA.py')

      Restart all servers including the Administration server in the SOA domain.

    5. If you have the Documents service configured for Spaces, run the configureUCM.py script as shown below:

      execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureUCM.py')
      

      Restart all servers including the Administration server in the Content Server domain.

  6. Run the individual commands below as required for your environment.

    execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureREST.py') - No restart is required.

    execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureRSS.py') - No restart is required.

    execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureForum.py') - Do this if you have Discussions installed in your setup. No restart is required.

    execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureActivityGraphEngine.py') - Do this if you have Utilities installed in your setup. No restart is required.

    execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureWorklistIntegration.py') - Do this if you have Worklist installed in your setup. No restart is required.

    execfile('wc_oracle_home>/webcenter/scripts/samlsso/configureWorklistDetail.py') - Do this if you have Worklist installed in your setup. No restart is required.

    execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureWorklistSDP.py') - Do this if you have Worklist installed in your setup. No restart is required.

    execfile('<wc_oracle_home>/webcenter/scripts/samlsso/configureCS.py') - Do this if you have Content Server installed in your setup. No restart is required.

  7. Check your installation using the steps provided in Section 32.4.2.4, "Checking Your Configuration."

    IMPORTANT:

    Since the properties file contains sensitive information, delete it from $WC_ORACLE_HOME/common/bin after you have configured and verified the SAML SSO setup. Also delete the config and key files you generated in step 2 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 as described in Section 32.4.2.6, "Removing Your SAML SSO Configuration."

After removing your old SAML SSO configuration, continue by re-running the scripts.

32.4.2.3 Configuring SAML SSO for RSS Using External Readers

By default, WebCenter Portal RSS feeds are protected by SSO. However, they will not work well with external readers if left protected. If access using external readers is important, Oracle recommends that the WebCenter Portal RSS resource be unprotected so that the authentication for the RSS Servlet is handled by WebLogic Server's BASIC authentication that external readers can handle.

Follow the steps below to unprotect the RSS feeds:

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

  2. Open the security realm and select Providers >Credential Mapping > wcsamlcm> Management > Relying Parties.

  3. Disable or delete the relying party for RSS.

  4. Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties.

  5. Disable or delete the asserting party for RSS.

32.4.2.4 Checking Your Configuration

Follow the steps below to check that your single sign-on configuration is working correctly.

To test your single sign-on configuration:

  1. Using a new browser, log in to Spaces and check that you're not challenged for credentials when you click Forum Administration from Space Settings > Services > Discussions (assuming this service is provisioned for the space).

  2. Access the RSS link from Discussions or WorkList task flow, and check that you are not challenged to log in.

  3. For Content Server, go to the Profile user interface and make sure you see Content Server screens embedded in iFrames without being challenged to log in. You should also be able to access Site Studio content in Content Presenter templates without being challenged to log in as you are already logged into Spaces.

  4. Access http://host:port/rest/api/resourceIndex and make sure you see the BASIC authentication challenge. If you are already logged in to another related application that uses the same SSO, you should shown content without being challenged to log in.

  5. To test SOA, access links in the Workflow task flow and make sure you are not challenged to log in.

If while testing SAML SSO you encounter 404 or 403 errors, check the SAML configuration and also turn on debug logging for SAML on the AdminServer. Also turn on logging for the WC_Spaces server and the server hosting your destination site. The logs will be available in $domain.home/servers/<server>/logs/<server>.log. For information on how to turn on logging for WC_Spaces and other application servers, see Section 39.5, "Viewing and Configuring Log Information." Before re-running the scripts, remove your SAML SSO configuration as described in Section 32.4.2.6, "Removing Your SAML SSO Configuration."

32.4.2.5 Disabling Your SAML SSO Configuration

This section describes how to temporarily disable your SAML SSO configuration for testing or other purposes.

To disable your SAML SSO configuration:

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

  2. Open the security realm and select Providers >Credential Mapping > wcsamlcm> Management > Relying Parties and disable all the relying parties shown there.

  3. Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties and disable all the asserting parties shown there.

  4. If there are other WLS domains, such as SOA or Content Server, that have been configured with SAML SSO, remove the SAML SSO configuration from these domains as well:

    1. Log in to the WLS Administration Console for the WLS domain.

    2. Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties and disable all the asserting parties shown there.

  5. Confirm that the SAML SSO configuration has been disable by opening your applications and checking that you are not prompted to sign in.

32.4.2.6 Removing Your SAML SSO Configuration

Since the SAML SSO configuration scripts do not include a cleanup facility, if you have made errors while updating the wcsamlsso.properties file or running the scripts, the configuration could be in an invalid state. At this point, it's better to clean up all the SAML SSO configurations and start over. This section describes the steps to remove the SAML SSO configuration.

Note that if you have fully set up SAML SSO (i.e., the script ran to completion), then all the instructions below will be valid. However, if you encountered errors while running the script, then the configuration may be incomplete and only some of the artifacts below will be present and will need to be removed.

To remove your SAML SSO configuration:

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

  2. Open the security realm and select Providers >Credential Mapping > wcsamlcm> Management > Relying Parties and delete all the relying parties shown there.

  3. Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties and delete all the asserting parties shown there.

  4. Go to Providers > Authentication > wcsamlia > Management > Certificates and delete the certificate there.

  5. Go to Providers > Credential Mapping > wcsamlcm and delete the SAML Credential Mapper.

  6. Go to Providers > Authentication > wcsamlia and delete the SAML Identity Asserter.

  7. Restart the entire Spaces WLS domain.

  8. If there are other WLS domains, such as SOA or Content Server, that have been configured with SAML SSO, remove the SAML SSO configuration from these domains as well:

    1. Log in to the WLS Administration Console for the WLS domain.

    2. Open the security realm and select Providers > Authentication > wcsamlia > Management > Asserting Parties and delete all the asserting parties shown there.

    3. Go to Providers > Authentication > wcsamlia > Management > Certificates and delete the certificate there.

    4. Go to Providers > Authentication > wcsamlia and delete the SAML Identity Asserter.

    5. Restart the entire WLS domain.

  9. Confirm that the SAML SSO configuration has been removed by opening your applications and checking that you are not prompted to sign in. You can now safely use the scripts again to reconfigure SAML SSO.

32.5 Configuring SSO for Microsoft Clients

This section describes how to set up single sign-on (SSO) for 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 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 Spaces) in a WebLogic domain based on the same credentials, and without the need to type in their password again. For more information about using Microsoft Office clients with WebCenter Portal, see Chapter 28, "Managing Microsoft Office Integration."

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 subsections:

32.5.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 32-10 Connecting to a Server Through a Key Distribution Center

Description of Figure 32-10 follows
Description of "Figure 32-10 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 32-11 SPNEGO-based Authentication

Description of Figure 32-11 follows
Description of "Figure 32-11 SPNEGO-based Authentication"

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

32.5.3 Configuring Microsoft Clients

Configuring SSO with Microsoft clients requires configuring the Microsoft Active Directory, the Microsoft client, and the WebLogic Server domain shown in Figure 32-12. For detailed configuration steps and troubleshooting, see Chapter 28, "Managing Microsoft Office Integration". Also see "Configuring Single Sign-On with Microsoft Clients" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

Figure 32-12 Configuring SSO with Microsoft Clients

Description of Figure 32-12 follows
Description of "Figure 32-12 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 (see "Configuring Single Sign-On with Microsoft Clients" in the Oracle Fusion Middleware Securing Oracle WebLogic Server).

  3. Choose a browser client (Internet Explorer or Mozilla Firefox) and configure it to use Windows Integrated authentication see ("Configuring Microsoft Clients to Use Windows Integrated Authentication" in the Oracle Fusion Middleware Securing Oracle WebLogic Server.)

  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 (see "Creating a JAAS Login File" in Oracle Fusion Middleware Securing Oracle WebLogic Server).

    2. Configure a Negotiate Identity Assertion provider in the WebLogic Server security realm (see Section 32.5.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 32.5.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. Add the following system properties to the JAVA_OPTIONS in setDomainEnv.sh for each WebCenter Portal machine, changing the values below for the values of the particular host (on one line):

    -Dnon_sso_protocol=http
    -Dnon_sso_host=example.com
    -Dnon_sso_port=8888
    -Dsso_base_url=http://example.com:7777
    

    The non_sso values are the value on the machine for protocol, host, and port. The sso values are the value that the user would see when directed through OHS.

  6. For WebCenter Portal: Spaces, configure the WebTier OHS so that it forwards requests to the Oracle WebLogic Server for WebCenter Portal, as described in Section 32.6, "Configuring SSO with Virtual Hosts."

  7. Restart the WebLogic Servers (Administration Server and managed servers) using the startup arguments specified in step 5. Repeat steps 4, 5, and 6 for the SOA domain to enable single sign-on for SOA applications.

  8. Restart the OHS for the changes to take effect.

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

32.5.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.13.2, "Oracle WebLogic Server Administration Console."

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

    The Summary of Security Realms pane displays.

  3. Click your security realm.

    The Settings page for the security realm displays.

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

    The Authentication Settings pane displays.

  5. Click New.

    The Create a New Authentication Provider pane displays.

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

  7. Click OK.

32.5.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.13.2, "Oracle WebLogic Server Administration Console."

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

    The Summary of Security Realms pane displays.

  3. Click your security realm.

    The Settings page for the security realm displays.

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

    The Authentication Settings pane displays.

  5. Click New.

    The Create a New Authentication Provider pane displays.

  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.

  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.

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

    Table 32-3 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...

32.5.3.3 Configuring WebCenter Portal: 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 Spaces. There are two options for doing this:

  • Turn off public access, by logging in to 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 Spaces only using Internet Explorer, and are confined to the domain where WNA is set up.

  • If you must retain public access to Spaces, then the recommendation is to use the oracle.webcenter.spaces.osso=true flag when starting the WC_Spaces server. This flag tells 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 Spaces within the Windows network configured for WNA, or any browser is used to access Spaces from outside the Windows network domain, users see the login page after clicking the Login link.

32.5.3.4 Configuring the Discussions Server for SSO

This section describes how to configure Oracle WebCenter Portal's Discussion Server 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 Spaces, as described in Section 30.4.1, "Migrating WebCenter Portal's Discussions Server to Use an External LDAP."

To set up the discussions server for SSO:

  1. Log in to the Oracle WebCenter Portal's Discussion Server Server Admin Console at:

    http://host:port/owc_discussions/admin
    

    Where host and port are the host ID and port number of the WC_Collaboration 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.

32.6 Configuring SSO with Virtual Hosts

This section describes the OHS configuration required for an environment containing applications that use "/" as the context root, and the additional configuration required in OHS when single sign-on is involved.

This section contains the following subsections:

32.6.1 Understanding the Need for a Virtual Host

The WebCenter Portal Suite includes a desktop integration application that uses "/" as the context root. If this application is to be used in a single sign-on environment you need to route it through OHS. To do this without a virtual host we could add the following entry to mod_wl_ohs.conf:

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

However, this would affect all context roots not explicitly defined, which brings us to the need for a virtual host.

The term virtual host refers to the practice of running more than one web site (such as www.company1.com and www.company2.com) on a single machine. Virtual hosts can be IP-based, meaning that you have a different IP address for each web site, or name-based, meaning that you have multiple names running on each IP address. The fact that they are running on the same physical server is not apparent to the end user. For more information about virtual hosts, refer to your Apache documentation.

32.6.2 Configuring Virtual Hosts for OSSO

This section describes the steps for configuring virtual hosts when OSSO is configured as the single sign-on solution. Prior to completing these steps you should already have completed the steps in Section 32.3, "Configuring Oracle Single Sign-On (OSSO)."

To use virtual hosts with OSSO you need to register partner applications with the virtual host option. Also, for webtier-spaces.example.com, you need to bypass single sign-on as some applications support only BASIC authentication and do not require single sign-on. These configurations are described in the following steps:

  1. Move the mod_osso.conf file from moduleconf to the same location as httpd.conf. (All files in moduleconf are loaded automatically by default, but we need OSSO disabled for our virtual host.)

  2. Update the virtual host setup in httpd.conf as shown in the following example:

    NameVirtualHost *:7777
     
    <VirtualHost *:7777>
      ServerName webtier.example.com
      include mod_osso.conf
    </VirtualHost>
     
    <VirtualHost *:7777>
      ServerName webtier-spaces.example.com
      <Location  />
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
      </Location>
      <Location /webcenter>
          Deny from all
      </Location>
      <Location /webcenterhelp>
          Deny from all
      </Location>
      <Location /rest>
          Deny from all
      </Location>
    </VirtualHost>  
    

    By including the mod_osso.conf in the default virtual host we provide a single sign-on experience for the default virtual host (webtier.example.com), but not for the Spaces virtual host (webtier-spaces.example.com) as some applications do not support it.

  3. Restart OHS. Also remember to update the DNS with entries for webtier-spaces.example.com.

Note:

In the webtier-spaces.example.com virtual host that bypasses single sign-on, only some applications need to bypass single sign-on. For other applications like Spaces, however, we need single sign-on so we deny access to these applications from this virtual host.

32.6.3 Configuring Virtual Hosts for OAM 10g

To configure OAM 10g for virtual hosts we need to bypass single sign-on for applications that only support BASIC authorization or do not require single sign-on. For more information, see "Associating a WebGate with Particular Virtual Hosts, Directories, or Files" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for 10g.

Prior to completing these steps you should already have completed the steps for configuring OAM 10g in Section 32.2, "Configuring Oracle Access Manager (OAM)."

  1. Locate and comment out the following configuration in httpd.conf:

    #Comment out this and move to VirtualHost configuration
    #<LocationMatch "/*">
    #AuthType Oblix
    #require valid-user
    #</LocationMatch>
    

    This entry causes the WebGate to intercept all requests and process them.

  2. Move this entry into the virtual host configuration where single sign-on is required as shown in the example below:

    NameVirtualHost *:7777
     
    <VirtualHost *:7777>
      ServerName webtier.example.com
      <LocationMatch "/*">
        AuthType Oblix
        require valid-user
      </LocationMatch>
    </VirtualHost>
     
    <VirtualHost *:7777>
      ServerName webtier-spaces.example.com
      <Location  />
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
      </Location>
      <Location /webcenter>
          Deny from all
      </Location>
      <Location /webcenterhelp>
          Deny from all
      </Location>
      <Location /rest>
          Deny from all
      </Location>
    </VirtualHost>
    

    The idea is to provide a single sign-on experience for the default virtual host (webtier.example.com), but not for the Spaces virtual host (webtier-spaces.example.com) as some applications do not support it.

  3. Restart OHS. Also be sure to update the DNS with entries for webtier-spaces.example.com.

    Note:

    In the webtier-spaces.example.com virtual host that bypasses single sign-on, only some applications need to bypass single sign-on. For other applications like Spaces, however, we need single sign-on so we deny access to these applications from this virtual host.

32.6.4 Configuring Virtual Hosts for OAM 11g

To configure OAM 11g for virtual hosts we need to bypass single sign-on for applications that only support BASIC authorization or do not require single sign-on.

Prior to completing these steps you should already have completed the steps for configuring OAM 11g in Section 32.2, "Configuring Oracle Access Manager (OAM)."

Follow the steps below to configure virtual hosts for OAM 11g.

  1. Locate and comment out the following configuration in webgate.conf:

    #Comment out this and move to VirtualHost configuration
    #<LocationMatch "/*">
    #AuthType Oblix
    #require valid-user
    #</LocationMatch>
    

    This entry causes the WebGate to intercept all requests and process it.

  2. Move this entry into the virtual host configuration in httpd.conf where single sign-on is required. as shown in the example below:

    NameVirtualHost *:7777
     
    <VirtualHost *:7777>
      ServerName webtier.example.com
      <LocationMatch "/*">
        AuthType Oblix
        require valid-user
      </LocationMatch>
    </VirtualHost>
     
    <VirtualHost *:7777>
      ServerName webtier-spaces.example.com
      <Location  />
          SetHandler weblogic-handler
          WebLogicHost webcenter.example.com
          WebLogicPort 8888
      </Location>
      <Location /webcenter>
          Deny from all
      </Location>
      <Location /webcenterhelp>
          Deny from all
      </Location>
      <Location /rest>
          Deny from all
      </Location>
    </VirtualHost>
    

    The idea is to provide a single sign-on experience for the default virtual host (webtier.example.com), but not for the Spaces virtual host (webtier-spaces.example.com) as some applications do not support it.

  3. Restart OHS. Also be sure to update the DNS with entries for webtier-spaces.example.com.

Note:

In the webtier-spaces.example.com virtual host that bypasses single sign-on, only some applications need to bypass single sign-on. For other applications like Spaces, however, we need single sign-on so we deny access to these applications from this virtual host.

32.6.5 Configuring WebCenter Portal for Virtual Hosts

This section describes the additional configurations required for applications routed through the virtual host.

Sharepoint

Typically when you use the "Edit with Word" or similar features for MS Office products, the WebCenter Portal Sharepoint application obtains the host name and port name from the current request. However, in this case the Sharepoint application needs to be routed through the virtual host requiring that some system properties be set in setDomainEnv in the WebLogic domain. For a cluster setup, be sure to change these properties on every machine.

-Dnon_sso_host=webtier-spaces.example.com
-Dsso_base_url=http://webtier.example.com:7777

32.6.6 Testing Your Configuration

This section describes how you can test your virtual host and single sign-on configuration.

Sharepoint

  1. Access http://webtier.example.com:7777/webcenter and check that you are challenged by SSO.

  2. Log in and choose an MS Word document and click Edit with Word. Click OK when you see a confirmation dialog. Word should challenge you for BASIC authentication. Enter your credentials and you should be able to see the document

  3. Navigate to Office icon > Server > Document Management Information and click Open Site in Browser. This should open the space to which the document belongs in your default browser.

    Note that you will be prompted with a BASIC authentication challenge as MS Office integration has a restriction where it needs to go to the same URL as the one for the document. You will then be redirected to the space through webtier.example.com and be prompted for to login if not already logged in.