23 Integrating Oracle Access Manager with Oracle WebCenter Sites

Use this chapter to integrate Oracle Access Manager (OAM) with Oracle WebCenter Sites installations.

This chapter contains the following sections:

Section 23.1, "Overview"
Section 23.2, "OAM Integration Prerequisites"
Section 23.3, "Integrating OAM with Oracle WebCenter Sites"
Section 23.4, "Integrating OAM with Oracle WebCenter Sites: Satellite Server"

23.1 Overview

This section contains the following topics:

Section 23.1.1, "Integration Components"
Section 23.1.2, "Flow for Browser Requests"
Section 23.1.3, "REST Service Flow"

23.1.1 Integration Components

Integration with Oracle Access Manager requires replacement of the Single Sign-On (SSO) authentication plug-in classes for the WebCenter Sites application, and the addition of a token authority servlet for REST client authentication. Optionally the WebCenter Sites challenge (login) page can be deployed.

Note:

When integrated with WebCenter Sites systems running in content management (development) mode, Oracle Access Manager, is used for browser and REST authentication. On production systems (running in delivery mode), OAM is used for management authentication, but not for website visitors.

Each component is described more fully in the following:

SSO authentication plug-in classes are delivered in the wem-sso-api-oam-11.1.1.8.0.jar that is included with the WebCenter Sites product. There are three primary classes included in this JAR that must be configured to load with the WebCenter Sites application when it starts.
1. OAMFilter provides recognition of an authenticated user (either by WebLogic Server (WLS) perimeter security or REST credential token) before allowing access to a protected resource.
2. OAMProvider contains the JAVA API which is used by REST client programs to obtain an authenticated credential before requesting a resource from the WebCenter Sites application. It also contains methods used internally to authenticate REST credentials by OAMFilter.
3. OAMListener is a session filter that monitors the creation and termination of HTTP sessions to facilitate cleanup of session related cached information.
The token authority servlet is delivered in the oamtoken.war file. It is an OAM AccessGate that will either authenticate a user against the OAM server or check, upon request, that an OAM authenticated session is still valid.
The WebCenter Sites challenge page is optional and is delivered in the oamlogin.war file. The servlet within oamlogin.war provides a custom branded challenge request when OAM must obtain credentials to authenticate a user. It is included to provide a replacement of the standard WebCenter Sites branded login page that is installed with the Central Authentication Service (CAS). This page is called directly by OAM and must be specifically configured within the OAM Authentication Scheme used to protect WebCenter Sites resources.

Installation of these components and the configuration of the Oracle Access Manager must be done to complete an operational OAM integration with WebCenter Sites.

Much of OAM integration regards the configuration of the elements of OAM itself. OAM configuration is done mainly within the OAM Administrative console, as well as across several WebCenter Sites server configuration files, and the Oracle HTTP Server (OHS) configuration files. The Host Identifiers, URL Resources, Domain policies, and OAM Agents must be properly configured to achieve proper operation. The WebCenter Sites challenge screen is supplied as an independent HTTP Servlet. You have the choice to use the WebCenter Sites challenge screen, the default OAM challenge screen, or a custom challenge screen through the Authentication Scheme attached to the configured policies.Control over all policies for authentication and authorization through the OAM Administrator console provides extensive configuration capabilities.

23.1.2 Flow for Browser Requests

OAM Integration components and process flow for logging in to and out of WebCenter Sites is shown in Figure 23-1. The core integration revolves around the OAMFilter and OAMProvider classes. These classes are injected into the WebCenter Sites Web application by Spring initialization to replace CAS equivalents which are not necessary with OAM. There are no internal changes to the WebCenter Sites application to accommodate this integration.

Figure 23-1 OAM Flowchart

Description of ''Figure 23-1 OAM Flowchart''

23.1.2.1 Login Processing

All browser access is directed through the standard OHS WebGate and uses perimeter security provided by the WLS container. The WebGate functions as a reverse proxy, checking protection policies through Access Manager. It issues the challenge/login form when necessary. A request is never passed directly to the WLS container but always passes through the WebGate to ensure authentication and authorization are satisfied. When a valid request is received from the WebGate, the WLS container presents an identity assertion to the OAM filter. This assertion will identify the authenticated user and cause the information for that user to be fetched from the WebCenter Sites SystemUsers table. User information consists of the user ID, name, and ACL needed to prepare the proper internal assertion for reference within the WebCenter Sites application. The user name in the WebCenter Sites SystemUsers table and in the Oracle Internet Directory (or LDAP directory) must match exactly for authentication to work properly. Although OAM includes authorization protection as well as authentication, WebCenter Sites uses only OAM authentication and does not rely on full OAM authorization.

When the OAMFilter receives control, the request has already been authenticated by the WebGate and an OAM Identity Assertion created by WLS perimeter security. This assertion provides the authenticated user's name which is used to find that user information in the WebCenter Sites SystemUsers table. The information thus obtained is used to create an internal assertion used within the WebCenter Sites application.

After an OAM Identity Assertion has been converted into an internal Assertion, the internal Assertion is added to the HTTP Session object. This allows subsequent requests to access URLs (resources) directly for the lifetime of the application session. However, the WebGate provides overriding protection based upon the OAM security policies in effect. If the OAM user session (different from HTTP session) expires, then the user will be required to re-authenticate.

The creation of OAM Identity Assertions is required by default. However, there is a possibility of an OAM Identity Assertion invoking a performance penalty. By default, the OAMFilter expects to see OAM Assertions to counter the possibility of a browser accessing WebCenter Sites directly from the Internet. This requirement can be avoided by a simple configuration change and the establishment of a trust relationship between the WebLogic Server and the OHS WebGate. This trust relationship is created by defining a connection filter in WebLogic that only accepts requests from a trusted source (the OHS server).

23.1.2.2 SSO and Logoff

The WebGate manages the OAM cookies which govern SSO. This is transparent to the WebCenter Sites OAM Filter and provides a seamless integration with other Oracle applications.

When WebCenter Sites logoff is requested, the standard OAM logoff facility is invoked by the OAM logoff URL which includes an end_URL parameter. The end_URL parameter establishes the next page that must appear after OAM finishes all logoff activities. OAM removes the SSO cookies, terminates the OAM session, and calls the registered logout success URL. The logout success URL is recognized by the OAM Filter to invalidate the HTTP session. After OAM logout has completed all its work it redirects the browser back to the WebCenter Sites welcome URL, specified through the end_URL parameter. This triggers a new challenge for the user to supply login credentials. The Logout URL settings are defined in the OHS WebGate configuration and the end_URL is defined in the SSOConfig.xml file.

23.1.3 REST Service Flow

REST processing follows a slightly different flow. This is also illustrated in Figure 23-1. The REST client uses the OAM Provider API to obtain a service ticket from the Token Authority. This ticket is required as a parameter in the REST request to grant access to a resource on the WebCenter Sites server. The TokenAuthority functions as an OAM Access Gate. It will authenticate the user against the policies defined for the REST endpoint URL. When a proper user name and password has passed authentication, the REST client is issued a service ticket to be used when requesting the resource. The TokenAuthority is an HTTP Servlet and it is recommended it be secured through SSL. The TokenAuthority performs three services:

Request – Takes a user name/password combination and endpoint URL (as the resource) and authenticate through the OAM SDK. The result is an OAM UserSession for the request. The associated session token is extracted from the UserSession and retained in a cache keyed by UUID. The UUID is returned to the requestor to be used as the service request ticket associated with the OAM Session.
Validate – Given a request ticket, the associated session token is retrieved from the cache and the authenticated user name is returned. The OAM UserSession is checked to make sure it remains valid. If the session is no longer valid or indicates that the user associated with the ticket is no longer logged in then a 'not authorized' 403 status is returned.
Invalidate – Given a request ticket, the associated session token is retrieved from the cache, removed, and then converted into an OAM UserSession object which is immediately terminated. This invalidates the OAM session and occurs after a request ticket has been used.

When the OAM Filter receives a REST request it must always be accompanied by a parameter that supplies a request ticket. This ticket is validated through the OAM Provider (the SSO Provider calls the Token Authority) before access to the resource is granted. A normal ticket request is for one time only and its maximum lifetime is dictated by the OAM session timeout. For a valid ticket, the OAM user session is invalidated immediately and access to the resource is allowed only once. A multi-ticket is handled in a similar manner but the ticket is cached locally so it may be reused by the REST client for a finite amount of time.

The published REST API remains the same. REST client programming is not affected by this integration and works exactly as it did with the CAS provider. Internally, the API dynamically instantiates the required classes based on which authentication provider is being used. Remote REST client programs are written in JAVA and require the wem-sso-api-oam-11.1.1.8.0.jar for compilation and execution.

The REST client goes directly to the WebCenter Sites server directly as shown in Figure 23-1. The client has the choice of two possible endpoints. It can go directly to the WebCenter Sites application as shown in the figure or pass through the OHS WebGate. A policy is defined for the latter case which allows this endpoint to be used. The decision of which endpoint to use is a choice dependent upon performance and/or security concerns.

23.2 OAM Integration Prerequisites

Installing OAM Components

Before you set up Oracle Access Manager integration, the Oracle components needed to support the environment must be installed and working properly. If you already have OAM installed and running at the support level specified in the Oracle WebCenter Sites Certification Matrix and in this document then you can disregard this section and skip to Section 23.3, "Integrating OAM with Oracle WebCenter Sites." Otherwise, continue with the steps below.

Note:

Choose the list of system components below that corresponds with the version of OAM that will be installed. Install the system components in the order given. The steps as listed are not comprehensive steps, and should be treated as guidelines.

Ensure that the proper versions are being used. The Oracle installer for each package requires that particular versions of related components are installed on the system. If version requirements are not observed then the installer will not allow a specific installation to continue. Each listed package includes one or more links to additional documentation.

All components listed can be downloaded from the Oracle Software Delivery Cloud site.

OAM 11.1.1.5.0 Components

Oracle Database 11.2.0

See Section 23.2.1, "Oracle Database 11g - Version 11.2.0."
Oracle Fusion Middleware Repository Creation Utility 11.1.1.5.0

See Section 23.2.2, "Oracle Fusion Middleware Repository Creation Utility."
Oracle WebLogic Server 10.3.5 Generic and Coherence

See Section 23.2.3, "Oracle WebLogic Server Generic and Coherence."
Oracle Identity and Access Management 11.1.1.5.0

See Section 23.2.4, "Oracle Identity Management and Access Management."
Oracle Fusion Middleware Web Tier Utilities 11.1.1.2.0

Oracle Fusion Middleware Web Tier Utilities Patch Set 11.1.1.5.0

See Section 23.2.5, "Oracle Fusion Middleware Web Tier Utilities."
Oracle Access Manager OHS WebGates 11.1.1.5.0

See Section 23.2.6, "Oracle Access Manager OHS WebGates."

OAM 11.1.1.7.0 Components

Oracle Database 11.2.0

See Section 23.2.1, "Oracle Database 11g - Version 11.2.0."
Oracle Fusion Middleware Repository Creation Utility 11.1.1.7.0

See Section 23.2.2, "Oracle Fusion Middleware Repository Creation Utility."
Oracle WebLogic Server 10.3.6 Generic and Coherence

See Section 23.2.3, "Oracle WebLogic Server Generic and Coherence."
Oracle Identity and Access Management 11.1.1.7.0

See Section 23.2.4, "Oracle Identity Management and Access Management."
Oracle Fusion Middleware Web Tier Utilities 11.1.1.7.0

See Section 23.2.5, "Oracle Fusion Middleware Web Tier Utilities."
Oracle Access Manager OHS WebGates 11.1.1.7.0

See Section 23.2.6, "Oracle Access Manager OHS WebGates."

OAM 11.1.2.1.0 Components

Oracle Database 11.2.0

See Section 23.2.1, "Oracle Database 11g - Version 11.2.0."
Oracle Fusion Middleware Repository Creation Utility 11.1.2.1.0

See Section 23.2.2, "Oracle Fusion Middleware Repository Creation Utility."
Oracle WebLogic Server 10.3.6 Generic and Coherence

See Section 23.2.3, "Oracle WebLogic Server Generic and Coherence."
Oracle Identity and Access Management 11.1.2.1.0

See Section 23.2.4, "Oracle Identity Management and Access Management."
Oracle Fusion Middleware Web Tier Utilities 11.1.1.6.0

See Section 23.2.5, "Oracle Fusion Middleware Web Tier Utilities."
Oracle Access Manager OHS WebGates 11.1.2.1.0

See Section 23.2.6, "Oracle Access Manager OHS WebGates."

23.2.1 Oracle Database 11g - Version 11.2.0

Install Oracle Database 11g - Version 11.2.0.

http://docs.oracle.com/cd/E11882_01/install.112/e24321/toc.htm
Create and configure an Oracle 11g database. For specific instructions, see Chapter 1, "Creating and Configuring an Oracle 11g Database."
Increase the maximum processes and open cursors allowed for the newly created database by running the following commands in sqlplus and restarting the database:
```
alter system set processes=500 scope=spfile;
alter system set open_cursors=800 scope=both;
```

23.2.2 Oracle Fusion Middleware Repository Creation Utility

Create Schemas using the Repository Creation Utility.

http://docs.oracle.com/cd/E28280_01/doc.1111/e14259/rcu.htm#CHDHHDHE
On the Select Components screen, expand Identity Management and select Oracle Access Manager.
Select all components.

23.2.3 Oracle WebLogic Server Generic and Coherence

Install WebLogic Server.

10.3.5

http://docs.oracle.com/cd/E21764_01/doc.1111/e14142/guimode.htm#BABHJJEG

10.3.6

http://docs.oracle.com/cd/E28280_01/doc.1111/e14142/guimode.htm#BABHJJEG

23.2.4 Oracle Identity Management and Access Management

Install Oracle Identity Management and Access Management
- 11.1.1.5.0: http://docs.oracle.com/cd/E23943_01/install.1111/e12002/common.htm#BABIADBF
- 11.1.1.7.0: http://docs.oracle.com/cd/E28280_01/doc.1111/e36891/install.htm#CIHBBHGG
- 11.1.2.1.0: http://docs.oracle.com/cd/E37115_01/install.1112/e27301/install.htm#BALIADBF
Create a domain.
1. Run <IAM_HOME>/common/bin/config.sh
  
  For example:
  
  /u01/software/Apps/OraMiddleware/Oracle_IDM1/common/bin/config.sh
2. Select Create a new WebLogic domain.
3. Select the following products based on the release:
  
  OAM 11.1.1.5.0:
  - Basic WebLogic Server Domain – 10.3.4.0 [wlserver_10.3]*
  - Oracle Enterprise Manager – 11.1.1.0 [oracle_common]
  - Oracle Access Manager with Database Policy Store – 11.1.1.3.0 [Oracle_IDM2]
  - Oracle JRF – 11.1.1.0 [oracle_common]
  OAM 11.1.1.7.0:
  - Basic WebLogic Server Domain – 10.3.6.0 [wlserver_10.3]*
  - Oracle Identity Manager – 11.1.1.2.0 [Oracle_IDM1]
  - Oracle SOA Suite – 11.1.1.0 [Oracle_SOA1]
  - Oracle Enterprise Manager – 11.1.1.0 [oracle_common]
  - Oracle Access Manager with Database Policy Store – 11.1.1.3.0 [Oracle_IDM2]
  OAM 11.1.2.1.0:
  - Basic WebLogic Server Domain – 10.3.6.0 [wlserver_10.3]*
  - Oracle Identity Manager – 11.1.2.0.0 [Oracle_IDM1]
  - Oracle SOA Suite – 11.1.1.0 [Oracle_SOA1]
  - Oracle Access Management – 11.1.2.0.0 [Oracle_IDM1]
  - Oracle Enterprise Manager – 11.1.1.0 [oracle_common]
    
    Note:
    Before integrating Oracle Access Manager ensure that Oracle SOA Suite is already installed.
4. Configure the JDBC Component Schema:
  - Select all Component Schema
  - Enter the information for the database created in Section 23.2.1, "Oracle Database 11g - Version 11.2.0"
  - Enter a Schema password
5. Optional Configuration:
  - Select Administration Server to configure the port of the AdminServer.
  - Select Managed Server, Clusters and Machines to modify the ports of the Managed Servers and add them to a Node Manager.

Configure the Database Security Store (11.1.2.1.0 Only)

Run the following command:

<MW_HOME>/oracle_common/common/bin/wlst.sh 
<IAM_HOME>/common/tools/configureSecurityStore.py -d <DOMAIN_HOME> -m
create -c IAM -p <OPSS_SCHEMA_PASSWORD> -u <OPSS_SCHEMA_NAME>

For example:

/u01/software/Apps/OraMiddleware/oracle_common/common/bin/wlst.sh
/u01/software/Apps/OraMiddleware/Oracle_IDM1/common/tools/configureSecurityStore.py -d /u01/software/Apps/OraMiddleware/user_projects/domains/OAMDomain -m 
create -c IAM -p test1234 -u DEV_IAS_OPSS

Start the Admin Server and OAM Managed Server

Run the following command to start the Admin Server:

<DOMAIN_HOME>/bin/startWebLogic.sh

For example:

/u01/software/Apps/OraMiddleware/user_projects/domains/OAMDomain/bin/startWebLogic.sh

Run the following command to start the OAM Managed Server:

<DOMAIN_HOME/bin/startManagedWebLogic.sh oam_server1 http://<ADMIN_HOST>:<ADMIN_PORT>

For example:

/u01/software/Apps/OraMiddleware/user_projects/domains/OAMDomain/bin/startManagedWebLogic.sh oam_server1 http://localhost:7001

23.2.5 Oracle Fusion Middleware Web Tier Utilities

Install Oracle Fusion Middleware Web Tier Utilities
- 11.1.1.2.0 (Will install Patch Set also): http://docs.oracle.com/cd/E21764_01/install.1111/e14260/install.htm#WTINS101
- 11.1.1.7.0: http://docs.oracle.com/cd/E28280_01/install.1111/e14260/config.htm#WTINS313
- 11.1.1.6.0: http://docs.oracle.com/cd/E23943_01/install.1111/e14260/config.htm#WTINS313
Select Install Software - Do Not Configure.
Install Oracle Fusion Middleware Web Tier Utilities Patch Set (11.1.1.5.0 Only)

http://docs.oracle.com/cd/E14571_01/doc.1111/e16793/patch_set_installer.htm#PATCH246
Configure Oracle Fusion Middleware Web Tier Utilities

Note:
Repeat the following steps for each Sites environment (for example - management, delivery, and so forth) that will be integrated with OAM.
1. Run <WEB_TIER_HOME>/bin/config.sh
  
  For example:
  
  u01/software/Apps/OraMiddleware/Oracle_WT1/bin/config.sh
2. On the Configure Components screen, select Oracle HTTP Server and Associate Selected Components with WebLogic Domain.
3. On the Specify WebLogic Domain screen, select the domain created in step 2 of Section 23.2.4, "Oracle Identity Management and Access Management."

23.2.6 Oracle Access Manager OHS WebGates

Install Oracle Access Manager OHS WebGates
- 11.1.1.5.0: http://docs.oracle.com/cd/E21764_01/install.1111/e12002/webgate.htm#CACGIGBB
- 11.1.1.7.0: http://docs.oracle.com/cd/E28280_01/doc.1111/e38584/webgate_ohs.htm#CACJIABJ
- 11.1.1.2.1: http://docs.oracle.com/cd/E37115_01/install.1112/e38922/webgate_ohs.htm#CACJIABJ

Complete the post-installation steps.

Note:

Repeat the following steps for each OHS instance you configured in step 3 of Section 23.2.5, "Oracle Fusion Middleware Web Tier Utilities."

Example values for the parameters:

<WEBGATE_HOME>

Example:

/u01/software/Apps/OraMiddleware/Oracle_OAMWebGate1

        <WEBGATE_INSTANCE_DIR>

Example:

        /u01/software/Apps/OraMiddleware/Oracle_WT1/instances/instance1/config/OHS/ohs1

<OHS_ORACLE_HOME>

Example:

/u01/software/Apps/OraMiddleware/Oracle_WT1

Deploy a Webgate instance:

cd <WEBGATE_HOME>/webgate/ohs/tools/deployWebGate
./deployWebgateInstance.sh -w <WEBGATE_INSTANCE_DIR> -oh <WEBGATE_HOME>

Modify the OHS configuration files:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<OHS_ORACLE_HOME>/lib
cd <WEBGATE_HOME>/webgate/ohs/tools/setup/InstallTools
./EditHttpConf -w <WEBGATE_INSTANCE_DIR> -oh <WEBGATE_HOME>

23.3 Integrating OAM with Oracle WebCenter Sites

This section includes the following topics:

Section 23.3.1, "Before You Start"
Section 23.3.2, "Integration Steps"
Section 23.3.3, "Allowing Anonymous Access to External Users"

23.3.1 Before You Start

There are some important considerations regarding the integration of WebCenter Sites with OAM authentication:

Up to this point, this chapter has described the required software and related components needed to integrate OAM with Oracle WebCenter Sites. If you have not reviewed the chapter, and have not ensured that the required components are installed and properly set up, then review the document.
WebCenter Sites must be installed and working properly with the default CAS.

Note:
If you plan on using an LDAP Server to store roles for WebCenter Sites, this configuration should be done before OAM Integration.
You may want to use the same LDAP Server for WebCenter Sites and OAM if user duplication is an issue.
The Oracle Access Manager Administration Console (OAMCONSOLE) application is required to perform a majority of the setup activities. Ensure you have permission to use this facility.

The integration procedure is a set of manual steps to be completed as described in the rest of this chapter.

23.3.2 Integration Steps

For a Sites delivery environment, use a separate OHS instance and perform the steps below, creating and configuring an additional WebGate, host identifier, authentication scheme, and application domain.

To integrate OAM, complete the following:

Define WebCenter Sites users in the OAM User Identity Store.

Note:
OAM is used for authentication only and does not rely on OAM authorization. While Oracle Internet Directory, Oracle Directory Server, and others can be used as user identity stores, Oracle WebLogic Embedded LDAP is the default, and is the user identity store used throughout the rest of this chapter. User names must match the user names located in the WebCenter Sites SystemUsers table.

OAM provides enforcement of authentication and authorization policies. WebCenter Sites uses only the authentication policies to protect resources. WebCenter Sites uses its own authorization policies.

User names in Oracle WebLogic Embedded LDAP must match the user names located in the WebCenter Sites SystemUsers table. The steps for adding users to WebLogic Embedded LDAP are as follows:
1. Log in to WebLogic Admin Console.
2. Click Security Realms.
3. Click myrealm.
4. Select the Users and Groups tab (Figure 23-2).
  
  Figure 23-2 Settings for myrealm - Users and Groups Tab
  
  Description of ''Figure 23-2 Settings for myrealm - Users and Groups Tab''
5. For each user to be added (Figure 23-3), complete the following steps:
  1. Click New.
  2. Enter the user name.
  3. Enter a description for the user.
  4. Select DefaultAuthenticator for Provider.
  5. Enter a password for the user.
  6. Re-enter the password for the user.
  7. Click OK.
    
    Figure 23-3 Create a New User Screen
    
    Description of ''Figure 23-3 Create a New User Screen''
Create an OAM WebGate Agent for deployment on OHS (Figure 23-4).
1. Log in to the OAM Console application.
  
  http://<oam_server_host>:<weblogic_admin_port>/oamconsole
2. Select the System Configuration tab.
3. Under SSO Agents, click New OAM 11g Webgate.
4. For Name, enter a name for the WebGate. This guide will use WCSitesWebGate.
5. For Preferred Host, enter a name for the Host Identifier to be created, and click Apply. The guide will use WCSites.
6. For Logout Callback URL, enter /<sites_context_root>/oam_logout_success and click Apply.
  
  Figure 23-4 WCSitesWebGate
  
  Description of ''Figure 23-4 WCSitesWebGate''
  
  Note:
  With the WCSitesWebGate creation, the WCSites host identifier and the WCSitesWebGate application domain will also be created.
Configure the host identifier for WebCenter Sites.
1. Click the Policy Configuration tab and click the Refresh icon. Under Host Identifiers, you should see WCSites.
2. Double-click WCSites.
3. For Description, enter This is the host identifier for WebCenter Sites.
4. On the operations panel, click the Add (+) icon. For Host Name, enter the OHS server hostname. For Port, enter the OHS server port.
  
  If you are using multiple hosts in a load balancing arrangement, repeat this step for each OHS instance.
5. Click Apply.
Create an authentication scheme that redirects to the WebCenter Sites challenge page.

Note:
This step is optional and can be skipped if using the default OAM login form or another custom login form.
1. Click Authentication Schemes, and then click the Create icon.
  
  The Authentication Schemes form is displayed.
  
  Figure 23-5 Authentication Schemes form
  
  Description of ''Figure 23-5 Authentication Schemes form''
2. For Name, enter a name for the authentication scheme to be created. This guide will use LDAPWemScheme
3. For Description, enter Challenge for WebCenter Sites applications
4. For Authentication Level, enter 2
5. For Challenge Method, select FORM
6. For Challenge Redirect URL, enter /oam/server
7. For Authentication Module, select LDAP
8. For Challenge URL, use the host and port that will be used to access the oamlogin application after it is deployed. Enter http://<oamlogin_server_host>:<oamlogin_port>/oamlogin/oamsso/oamLoginView.jsp
9. For Context Type, select external
10. Click Apply.
In steps 5-6, you will be configuring the WCSitesWebGate application domain created during WebGate creation. The Protected Resource Policy authentication policy forces a challenge for any of its resources that are accessed without authentication. The policy allows all resources to be passed by the WebGate to the WebCenter Sites application so authorization can be handled.

Configure the Protected Resource Policy
1. Open the Protected Resource Policy
  
  For 11.1.1.x.0:
  
  Expand Application Domains.
  
  Expand WCSitesWebGate.
  
  Expand Authentication Policies.
  
  Double-click Protected Resource Policy.
  
  For 11.1.2.1.0:
  
  Click Application Domains and click the Open icon.
  
  Click Search.
  
  Click WCSitesWebGate.
  
  Click the Authentication Policies tab.
  
  Click Protected Resource Policy.
2. For Authentication Scheme, select LDAPWemScheme, the authentication scheme previously created.
3. Click the Responses tab.
4. Select the Identity Assertion checkbox.
  
  When an Authentication policy is satisfied, it can create responses. The responses are required by the WebCenter Sites HTTP filter to recognize LDAP attributes and provide information about the authenticated user. In the following steps, you will create these responses.
5. Click the Add (+) icon.
6. For Name, enter FATGATE_POLICY
7. For Type, select Header
8. For Value, enter protected.
9. Click the Add (+) icon.
10. For Name, enter FATGATE_EMAIL.
11. For Type, select Header
12. For Value, enter $user.attr.mail
13. Click Apply.

Create resource definitions for the WebCenter Sites application domain.

Open Resources

For OAM 11.1.1.x.0, double-click Resources.

For OAM 11.1.2.1.0, click the Resources tab.

This panel will display only the resources that match the search criteria. Each time a new resource is added, the Search button must be clicked for the resource to appear in the Search Results list.

Figure 23-6 Resources - New Resource

Description of ''Figure 23-6 Resources - New Resource''
Click New Resource to open the Create Resource panel.
For Resource Type, select HTTP
For Host Identifier, select WCSites, the host identifier configured in step 3.
Enter a Resource URL.
Select a Protection Level.

If selecting Excluded, skip steps g and h.
For Authentication Policy, if selecting Protected in step f, select Protected Resource Policy
For Authorization Policy, if selecting Protected in step f, select Protected Resource Policy
Click Apply.

Figure 23-7 Resources

Description of ''Figure 23-7 Resources''

Repeat steps b through i using the list of resources in Table 23-1.

Note:

Any resources with a policy are Protected. The remaining resources are Excluded.

Table 23-1 Resources

Resource URL	Protection Level	Authentication	Authorization
`/index.html`	Excluded	NA	NA
`/oamlogin/oamsso/…/*`	Excluded	NA	NA
`/<sites_context_root>` (OAM 11.1.1.x.0 only)	Excluded	NA	NA
`/<sites_context_root>/…/*` (OAM 11.1.1.x.0 only)	Excluded	NA	NA
`/<sites_context_root>/**` (OAM 11.1.2.1.0 only)	Excluded	NA	NA
`/` (OAM 11.1.1.x.0 only)	Protected	Protected	Protected
`/…/*` (OAM 11.1.1.x.0 only)	Protected	Protected	Protected
`/**` (OAM 11.1.2.1.0 only)	Protected	Protected	Protected
`/oamlogin/test`	Protected	Protected	Protected
`/<sites_context_root>/wem/fatwire/…/*`	Protected	Protected	Protected
`/<sites_context_root>/faces/jspx/…/*`	Protected	Protected	Protected
`/<sites_context_root>/Satellite/…/*`	Protected	Protected	Protected
`/<sites_context_root>/ContentServer/…/*`	Protected	Protected	Protected
`/<sites_context_root>/Xcelerate/LoginPage.html`	Protected	Protected	Protected

After all resources are added, compare the list of defined resources with Table 23-1 to ensure all policies are properly defined. Make sure all trailing /…/ contain three periods. Make sure each Resource URL is entered in the exact case. The WebCenter Sites application will not work properly if these policies are not entered correctly.

Modify the mod_wl_ohs.conf OHS plugin configuration file:

Note:

Make sure the OHS server is shutdown.

export ORACLE_INSTANCE=<ohs_oracle_home>

For example:

export ORACLE_INSTANCE=/u01/software/Apps/OraMiddleware/Oracle_WT1

<ohs_oracle_home>/bin/opmnctl stopproc ias-component=ohs1

This file is located in the WebGate instance directory.

For example:

/u01/software/Apps/OraMiddleware/Oracle_WT1/instances/instance1/config/OHS/ohs1/mod_wl_ohs.conf

Consider this template for modification:

# 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
</IfModule>

<IfModule weblogic_module>
   <Location /oamlogin>
      SetHandler weblogic-handler
      WebLogicHost {oamlogin_server_host}
      WebLogicPort {oamlogin_port}
   </Location>
</IfModule>

<IfModule weblogic_module>
   <Location /{sites_context_root}>
      SetHandler weblogic-handler
      WebLogicHost {sites_server_host}
      WebLogicPort {sites_port}
   </Location>
</IfModule>

# <Location /weblogic>
#      SetHandler weblogic-handler
#      PathTrim /weblogic
#      ErrorPage  http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
#  </Location>

Note:

Make sure there is an include statement in the http.conf files for the mod_wl_ohs.conf file.

For example:

include "/u01/software/Apps/OraMiddleware/Oracle_WT1/instances/instance1/config/OHS/ohs1/mod_wl_ohs.conf"

Copy the WebGate configuration files (ObAccessClient.xml and cwallet.sso) to the WebGate instance:

cp <oam_domain_home>/output/<webgate_name>/* <webgate_instance_dir>/webgate/config

For example:

cp /u01/software/Apps/OraMiddleware/user_projects/domains/OAMDomain/output/WCSitesWebGate/* /u01/software/Apps/OraMiddleware/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config

Start the OHS server:

export ORACLE_INSTANCE=<ohs_oracle_home>

For example:

export ORACLE_INSTANCE=/u01/software/Apps/OraMiddleware/Oracle_WT1
<ohs_oracle_home>/bin/opmnctl startproc ias-component=ohs1

Deploy the oamtoken.war file:
1. Create a directory where the oamtoken.war file will be deployed from, and explode the oamtoken.war file into the directory from the wem directory of the WebCenter Sites installer.
  
  For example:
```
mkdir /u01/software/Apps/OraMiddleware/user_projects/domains/OAMSitesDomain/applications/oamtoken
cd /u01/software/Apps/OraMiddleware/user_projects/domains/OAMSitesDomain/applications/oamtoken 
jar -xvf /u01/installation_files/Sites/wem/oamtoken.war
```
2. Modify the oamtoken.xml file located in the WEB-INF/classes directory of the exploded oamtoken web application.
  
  For OAM 11.1.1.5.0, set the value of compatibilityMode to 10G.
  
  For OAM 11.1.1.7.0 and 11.1.2.1.0, set the value of compatibilityMode to 11G.
3. Copy the WebGate configuration files (ObAccessClient.xml and cwallet.sso) created in step 2 to the WEB-INF/oblix/lib directory of the exploded oamtoken web application.
  
  Overwrite any existing file.
  
  The WebGate configuration files are located in the <oam_domain_home>/output/<webgate_name> directory on the system where OAM is deployed.
  
  For OAM 11.1.1.5.0, skip steps d through f.
4. Copy the jps-config.xml file from the config directory of the exploded oamtoken web application to <oamtoken_domain_home>/config.
5. Modify the file copied in step d, changing the value of the location parameter to the path of the directory where the cwallet.sso file is located.
  
  For example:
```
../applications/oamtoken/WEB-INF/oblix/lib
```
6. Modify the weblogic.policy file located in the <weblogic_home>/server/lib directory on the host where oamtoken will be deployed.
  
  Add the following lines after the beginning commented section of the file, setting the file value to the path of WEB-INF/lib/* in the exploded oamtoken web application:
```
// grant permission for oamtoken
grant codebase "file:<path_to_exploded_oamtoken_app>/WEB-INF/lib/*" {
    permission
oracle.security.jps.service.credstore.CredentialAccessPermission
    "context=SYSTEM,mapName=OAMAgent,keyName=*", "read";
};
```
7. Deploy the exploded oamtoken web application.
  
  Note:
  On WebLogic, make the deployment accessible from the current location.
  The servlet contained in the oamtoken web application may be called with visible username and password credentials. It is recommended to deploy the application as a secured web application user SSL.
Deploy the oamlogin.war file. This web application contains the WebCenter Sites challenge page.

Note:
This step is optional and can be skipped if using the default OAM login form or another custom login form
1. Create a directory where the oamlogin.war file will be deployed from, and explode the oamlogin.war file into the directory from the wem directory of the WebCenter Sites installer.
  
  For example:
```
mkdir /u01/software/Apps/OraMiddleware/user_projects/domains/OAMSitesDomain/applications/oamlogin
cd /u01/software/Apps/OraMiddleware/user_projects/domains/OAMSitesDomain/applications/oamlogin
jar -xvf /u01/installation_files/Sites/wem/oamlogin.war
```
2. Create a file named wemsites_settings.properties in the WEB-INF/classes directory of the exploded oamlogin web application, using the code below. Replace the variables with the correct values for your environment:
```
oamredirect=http://<oam_server_host>:<oam_port>/oam/server/auth_cred_submit
oamlogout=http://<oam_server_host>:<oam_port>/oam/server/logout
forgotpassword=<email_account>@<email_domain>
```
  If the oamredirect property is not configured correctly, the username and password will fail to authenticate.
3. Deploy the exploded oamlogin web application. On WebLogic, make the deployment accessible from the current location.

Modify the SSOConfig.xml file of the WebCenter Sites deployment. This file controls which authentication classes are loaded and the properties that are required by those classes.

Shutdown the Sites server.
Back up the SSOConfig.xml file, located in the WEB-INF/classes directory of the deployed WebCenter Sites application.

For example:
```
/u01/software/Apps/OraMiddleware/user_projects/domains/OAMSitesDomain/applications/Sites/WEB-INF/classes/SSOConfig.xml
```
Modify SSOConfig.xml to look like the following:
Note:
In the file below, you will set the following properties: serviceUrl, ticketUrl, signoutURL, dbUsername, dbPassword, and trustConfigured.
The signoutUrl property specifies the URL to be used when invoking WebCenter Sites logout. It includes the encoded URL where the browser will return after all logout processing has been completed by OAM.

For Sites management, use the following value for end_url:
```
http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome
```
For Sites delivery, use the following value for end_url:
```
http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2FXcelerate%2FLoginPage.html
```
For the dbUsername and dbPassword properties, you can enter the credentials of the WebCenter Sites general administrator (by default, fwadmin / xceladmin). The values for these properties will be encrypted on startup of the WebCenter Sites application.

If a trust relationship is established between the WebLogic Server and the OHS WebGate, you can set the ssofilter bean's trustConfigured property to true to eliminate the requirement for an OAM Identity Assertion with every request.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">

  <!-- Single Sign On provider -->
  <bean id="ssoprovider" class="com.fatwire.wem.sso.oam.OAMProvider">
    <property name="config" ref="ssoconfig" />
  </bean>
  <!-- OAM IdentityResolver bean -->
  <bean id="oamIdentity" class="com.fatwire.auth.identity.LocalUsernameResolver" />

  <!-- Single Sign On filter -->
  <bean id="ssofilter" class="com.fatwire.wem.sso.oam.filter.OAMFilter">
    <property name="config" ref="ssoconfig" />
    <property name="provider" ref="ssoprovider" />
    <property name="identityResolver" ref="oamIdentity" />
    <property name="trustConfigured" value="false" />
  </bean>

  <!-- Single Sign On listener -->
  <bean id="ssolistener" class="com.fatwire.wem.sso.oam.listener.OAMListener">
  </bean>

  <!-- Single Sign On configuration -->
  <bean id="ssoconfig" class="com.fatwire.wem.sso.oam.conf.OAMConfig">
    <!-- URL prefix for REST service endpoint -->
    <property name="serviceUrl" value="http://{ohs_server_host}:{ohs_port}/{sites_context_root}/REST" />
    <!-- URL prefix for Token Service servlet -->
    <property name="ticketUrl" value="http://{oamtoken_server_host}:{oamtoken_port}/oamtoken" />
    <!-- URL to be called when WEM logout is required. -->
    <property name="signoutUrl" value="http://{oam_server_host}:{oam_port}/oam/server/logout?end_url={end_url}" />
    <!-- Do not proxy tickets, tt's the last server in the call chain -->
    <property name="proxyTickets" value="false" />
    <!-- Database Credentials needed by user lookup in OAMFilter -->
    <property name="dbUsername" value="{sites_admin_user} " />
    <property name="dbPassword" value="{sites_admin_password}" />
    <!-- Your application protected resources (relative to applicationUrl) -->
    <property name="protectedMappingIncludes">
      <list>
                <value>wem/fatwire/**</value>
                <value>/faces/jspx/**</value>
<value>/ContentServer?[pagename=OpenMarket/Xcelerate/UIFramework/LoginPage|OpenMarket/Xcelerate/UIFramework/ShowMainFrames|fatwire/getAllUserGroups|fatwire/getAllSecurityConfigs|rest/asset,#]</value>

<value>Satellite?[pagename=fatwire/insitetemplating/request|OpenMarket/Xcelerate/ControlPanel/Request|OpenMarket/Xcelerate/ControlPanel/EditPanel|fatwire/wem/ui/Ping|fatwire/wem/sso/validateMultiticket|OpenMarket/Xcelerate/UIFramework/ShowPreviewFrames,#]</value>

<value>Xcelerate/LoginPage.html</value>
      </list>
    </property>
    <property name="protectedMappingStatelessIncludes">
      <list>
                <value>/REST/**</value>
      </list>
    </property>
    <!-- Your application protected resources excludes (relative to applicationUrl) -->
    <property name="protectedMappingExcludes">
      <list>
                <value>/wem/fatwire/wem/ui/SysLocStrSvc</value>
      </list>
    </property>
  </bean>

</beans>

Configuration is now complete and OAM will authenticate users of the WebCenter Sites content management and development installations.

You may now start the remaining servers.
This step is optional and can be performed only if you have deployed the oamlogin.war file.
1. Enter the following URL on any browser:
```
http(s)://<ohs_server_host>:<ohs_port>/oamlogin/test
```
  If the system is operating properly you should see the WebCenter Sites challenge form (Figure 23-8).
  
  Figure 23-8 Access Manager Secure User Login Form
  
  Description of ''Figure 23-8 Access Manager Secure User Login Form''
2. Enter the user name and password and then click Login. Remember that the password is defined in LDAP and not the WebCenter Sites database.
3. When the system is working properly a test page will appear that displays all the information provided by the WebGate. This includes the Responses specified in the policies you have created. Refresh this page and it will redisplay updated information.
4. Click Logoff on the test form. The standard OAM logoff acknowledgement form opens.
5. Re-enter the URL to display the custom challenge form.
  
  Carefully review the configuration to ensure the expected results.

23.3.3 Allowing Anonymous Access to External Users

An anonymous user is required to provide access to external users to view pages stored on a management system. For example, to access a development site located on an OAM-integrated management server for testing purposes.

Add a user called Anonymous to the WebCenter Sites SystemUsers table.
Modify OAM authentication policy to remove /<context>/Satellite/* resource from that policy.
Recycle Oracle Http Server (OHS) to apply this change.
In the /cs/WEB-INF/classes folder, modify the satellite.properties file to set port= and host= to OHS location. This is necessary as the default localhost:80 causes errors.

23.4 Integrating OAM with Oracle WebCenter Sites: Satellite Server

Configuring a Satellite Server for Oracle Access Manager integration is a simpler procedure than for WebCenter Sites. The procedure outlined in this section is specific to configuring a single Satellite Server, but the process is the same for additional Satellite Servers.

This section includes the following topics:

Section 23.4.1, "Before You Start"
Section 23.4.2, "Integration Steps"

23.4.1 Before You Start

Ensure the following actions are complete before integrating Satellite Server:

Oracle Access Manager is installed and running.
WebCenter Sites has been successfully integrated with OAM.
Satellite Server is installed.

23.4.2 Integration Steps

In these steps, you will modify the SSOConfig.xml file of the WebCenter Sites SatelliteServer deployment. This file controls which authentication classes are loaded and the various properties that are required by those classes.

Shut down the server where SatelliteServer is deployed.
Back up the SSOConfig.xml file, located in the deployed WEB-INF/classes directory of the deployed WebCenter Sites SatelliteServer application.

For example:
```
/u01/software/Apps/OraMiddleware/user_projects/domains/OAMSitesDomain 
    /applications/SatelliteServer/WEB-INF/classes/SSOConfig.xml
```

Modify SSOConfig.xml to look like the file shown below.

Note:

In the file below, you will set the following properties: serviceUrl, ticketUrl, and signoutURL.

The signoutUrl property specifies the URL to be used when invoking WebCenter Sites logout. It includes the encoded URL where the browser will return after all logout processing has been completed by OAM.

If a trust relationship is established between the WebLogic Server and the OHS WebGate, you can set the ssofilter bean's trustConfigured property to true to eliminate the requirement for an OAM Identity Assertion with every request.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">

   <!-- Single Sign On provider -->
   <bean id="ssoprovider" class="com.fatwire.wem.sso.oam.OAMProvider">
   <property name="config" ref="ssoconfig" />
  </bean>

  <!-- OAM IdentityResolver bean -->
  <bean id="oamIdentity" class="com.fatwire.auth.identity.RemoteUsernameResolver id="oamIdentity">
    <property="csServerUrl" value="http://<sites_server_host>:<sites_port>/<sites_context_root>/custom/customCsResolver.jsp
  </bean>

  <!-- Single Sign On filter -->
  <bean id="ssofilter" class="com.fatwire.wem.sso.oam.filter.OAMFilter">
    <property name="config" ref="ssoconfig" />
    <property name="provider" ref="ssoprovider" />
    <property name="identityResolver" ref="oamIdentity" />
    <property name="trustConfigured" value="false" />
  </bean>

  <!-- Single Sign On listener -->
  <bean id="ssolistener" class="com.fatwire.wem.sso.oam.listener.OAMListener">
  </bean>

  <!-- Single Sign On configuration -->
  <bean id="ssoconfig" class="com.fatwire.wem.sso.oam.conf.OAMConfig">
    <!-- URL prefix for REST service endpoint -->
    <property name="serviceUrl" value="http://{ohs_server_host}:{ohs_port}/{sites_context_root}/REST" />
    <!-- URL prefix for Token Service servlet -->
    <property name="ticketUrl" value="http://{oamtoken_server_host}:{oamtoken_port}/oamtoken" />
    <!-- URL to be called when WEM logout is required. -->
    <property name="signoutUrl" value="http://{oam_server_host}:{oam_port}/oam/server/logout?end_url=http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome" />
    <!-- Proxy tickets, tt's the last server in the call chain -->
    <property name="proxyTickets" value="true" />
    <!-- Your application protected resources (relative to applicationUrl) -->
    <property name="protectedMappingIncludes">
      <list>
      </list>
    </property>
    <property name="protectedMappingStatelessIncludes">
      <list>
                <value>/REST/**</value>
      </list>
    </property>
    <!-- Your application protected resources excludes (relative to applicationUrl) -->
    <property name="protectedMappingExcludes">
      <list>
      </list>
    </property>
  </bean>

</beans>

Ensure that the proxyTickets parameter is set to true. This is required so that Satellite Server will pass authenticated tickets allocated by REST client programs to WebCenter Sites.

The location of the REST endpoint (defined by the serviceUrl property) depends on the location of the Satellite Server. When located inside the firewall, it can refer directly to the WebCenter Sites to achieve the highest performance without compromising security. When the Satellite Server is located elsewhere, or exposed directly to the Internet, the endpoint must direct all requests through the OHS to secure and protect WebCenter Sites.

An advanced configuration using OHS in front of Satellite Server is an alternative way of securing the WebCenter Sites configurations. This configuration would access the WebCenter Sites.