6 Integrating with Oracle Access Manager

This chapter describes using Oracle Access Manager to manage user authentication and authorization when a user logs in to Oracle Identity Manager.

This chapter covers the following topics:

• About the Integration with Oracle Identity Manager

• Integration Architecture

• Preparing Your Environment

• Setting Up Oracle Access Manager Single Sign-On for Oracle Identity Manager

• Setting Up Oracle Identity Manager for Single Sign-On with Oracle Access Manager

• Configuring Apache as a Proxy for JBoss

Note:

While this chapter focuses on using JBoss as the application server in the integration, the same configuration steps apply to instances where Oracle Identity Manager is deployed on WebSphere, WebLogic or any other J2EE application server that is supported by Oracle Identity Manager.

About the Integration with Oracle Identity Manager

The integration of Oracle Access Manager with Oracle Identity Manager provides a secure Web-based infrastructure for identity management for all customer applications and processes. Oracle Access Manager integrates identity and access management across Oracle Identity Manager, enterprise resources, and other domains deployed on eBusiness networks. Oracle Access Manager provides the foundation for managing the identities of customers, partners, and employees across Internet applications. These user identities are combined with security policies for protected Web interaction.

This integration adds the following features to Oracle Identity Manager implementations:

• Oracle Access Manager authentication, authorization, and auditing services for Oracle Identity Manager.

• Oracle Access Manager single sign-on for Oracle Identity Manager and other Oracle Access Manager-protected resources within a single domain or across multiple domains.

• Oracle Access Manager authentication schemes, the following schemes provide single sign-on for Oracle Identity Manager:

  • Basic: Users must enter a user name and password in a window supplied by the Web server.

    This method can be redirected to SSL.'

  • Form: This method is similar to the basic challenge method, but users enter information in the custom HTML form.

    You can choose the information users must provide in the form that you create.

  • X509 Certificates: X.509 digital certificates over SSL.

    A user's browser must supply a certificate.

  • Integrated Windows Authentication (IWA): Users will not notice a difference between an Oracle Access Manager authentication and IWA when they log on to the desktop, open an Internet Explorer (IE) browser, request a Oracle Access Manager-protected Web resource, and complete single sign-on.

  • Custom: Additional forms of authentication can be incorporated through use of the Oracle Access Manager Authentication Plug-in API.

• Session timeout: Oracle Access Manager enables you to set the length of time that a user session is valid.

• Ability to use the Oracle Access Manager Identity System: This system provides identity management features such as user self-service for registration and updating user profiles, portal inserts, delegated administration, and workflows. You can send Identity System data to back-end applications using a custom data template and a workflow.

Integration Architecture

Oracle Identity Manager has two authentication mechanisms:

• Default mode, where Oracle Identity Manager manages the credential validation and session maintenance.

• Single sign-on mode, where Oracle Identity Manager looks for an HTTP header variable that is passed to it.

  The header variable should contain the user ID of the Oracle Identity Manager user.

Oracle Access Manager single sign-on with Oracle Identity Manager is achieved as follows:

• Deploy an HTTP Server in front of the J2EE Application server.

• Deploy the HTTP Server as a reverse proxy.

• Deploy a WebGate on the HTTP Server.

• Populate a header variable with an attribute value that is stored in the LDAP directory used by Oracle Access Manager.

• Configure IOracle Identity Manager to use the single sign-on mode of authentication.

Figure 6-1 shows the architecture for single sign-on between Oracle Identity Manager and Oracle Access Manager.

The user accesses the Administrative and User Console with a Web browser. The WebGate intercepts the user's HTTP request and checks for the presence of an obSSOCookie. If the cookie does not exist or it has expired, the user is challenged for credentials. Oracle Access Manager verfies the credentials, and if the user is authenticated, the WebGate redirects the user to the requested resource and passes the required header variable to Oracle Identity Manager. Oracle Identity Manager, which has been configured to read a HTTP Header variable instead of its authentication, reads the HTTP Header and uses the value stored in the variable as the logged in user.

Figure 6-1 Integration with Oracle Identity Manager

Process overview: Single sign-on with Oracle Identity Manager

1. A user attemps to access the Administrative and User Console.

2. A WebGate that is deployed on the HTTP server intercepts the request.

3. The WebGate checks the Access Server to determine if the resource (the Oracle Identity Manager URL) is protected.

   The security policy in the Access System contains an authentication scheme, authorization rules, and allowed operations based on authentication and authorization success or failure.

4. If a valid session does not exist, and the resource is protected, WebGate prompts the user for credentials.

5. If the credentials are validated, Oracle Access Manager performs the actions that are defined in the security policy for the resource and sets an HTTP header variable that maps to the Oracle Identity Manager user ID.

6. If a vali session cookie exists, and if the user is authorized to access the resource, WebGate redirects the user to the requested Oracle Identity Manager resource.

7. The Administrative and User Console reads the HTTP header variable and sets the value as the logged-in user.

8. The Administrative and User Console generates the applications pages, pending any further authorization checks performed in Oracle Identity Manager.

Preparing Your Environment

Complete the following to prepare your environment for the integration.

Task overview: Preparing your environment for the integration

1. Install a supported directory server according to vendor instructions.

2. Install and configure Oracle Access Manager using the directory server as the LDAP repository.

3. Ensure that the Oracle Identity Manager J2EE application server is proxied by an HTTP server.

4. Configure the Web browser to allow cookies, according to vendor instructions.

5. Set up Oracle Access Manager for Oracle Identity Manager.

   See "Setting Up Oracle Access Manager Single Sign-On for Oracle Identity Manager" for details.

Setting Up Oracle Access Manager Single Sign-On for Oracle Identity Manager

The following procedures describes setting up WebGate on an HTTP server and configuring Oracle Access Manager for single sign-on with Oracle Identity Manager.

Note that you can configure form-based authentication for logins that use either ASCII or non-ASCII characters. Due to browser limitations, Basic authentication schemes only accept ASCII login credentials.

See also:

For more information about configuring authentication and authorization in Oracle Access Manager, see the Oracle Access Manager Access Administration Guide.

To set up a WebGate on an HTTP server

1. Install and configure Oracle Access Manager on a supported platform, using a supported LDAP server.

   See the Oracle Access Manager Installation Guide for details.

2. Install a WebGate on the Oracle Identity Manager HTTP server.

   Do not install the WebGate against an application server that supports HTTP services, for example, BEA Weblogic. If your application server is JBoss, IBM WebSphere, or BEA Weblogic, install an HTTP server such as Apache, iPlanet, or Oracle HTTP Server.

3. Configure the HTTP server to forward user requests to the J2EE application server and forward responses from the Oracle Identity Manager back to the user.

To configure single sign-on in Oracle Access Manager

1. In the landing page for the Access System, click the link for the Policy Manager, and click Create Policy Domain.

2. Create a policy domain and policies to restrict access to the Oracle Identity Manager URLs.

3. In the Access System Console, define host identifiers for Oracle Identity Manager.

4. Click the link for the Policy Manager, click the link for the Oracle Identity Manager policy domain, click the Resources tab, and define resources for Oracle Access Manager to protect.

5. Click the Authorization Rules tab and define an authorization rule to determine which authenticated users can access the Oracle Identity Manager URLs.

6. Click the Default Rules tab.

   The Authentication Rule sub-tab is selected.

7. Define an authentication rule, for example, Basic Over LDAP.

8. Click the Actions sub-tab and define an authorization action that sets a custom HTTP header variable upon successful authorization.

   The header variable should contain a value that maps to the Oracle Identity Manager user ID.

9. Click the Policies tab, click Add, and define an access policy in the Oracle Identity Manager policy domain and add the Oracle Identity Manager URL resources to this policy.

Setting Up Oracle Identity Manager for Single Sign-On with Oracle Access Manager

The following procedure describes how to set up Oracle Identity Manager for integration with Oracle Access Manager.

To configure single sign-on for Oracle Identity Manager

1. Stop the application server gracefully.

2. Launch a plain-text editor and open the following file:

   <XL_HOME>\xellerate\config\xlconfig.xml

3. Locate the following Single Sign-On configuration (the following are the default settings without Single Sign-On):

   <web-client>
   <Authentication>Default</Authentication>
   <AuthHeader>REMOTE_USER</AuthHeader>
   </web-client>
   
   

4. Edit the single sign-on configuration as follows.

   Replace <SSO_HEADER_NAME> with the appropriate header configured in your single sign-on system:

   <web-client>
   <Authentication>SSO</Authentication>
   <AuthHeader><SSO_HEADER_NAME></AuthHeader>
   </web-client>
   
   

   To enable single sign-on with non-ASCII character logins you must include a decoding class name to decode the non-ASCII header value. Add the decoding class name and edit the single sign-on configuration as follows:

   <web-client>
   <Authentication>SSO</Authentication>
   <AuthHeader><SSO_HEADER_NAME></AuthHeader>
   <AuthHeaderDecoder>com.thortech.xl.security.auth.CoreIDSSOAuthHeaderDecoder</AuthHeaderDecoder>
   </web-client>
   
   

   Replace <SSO_HEADER_NAME> with the appropriate header configured in your single sign-on system

5. Change your application server and web server configuration to enable single sign-on.

   Refer to your application and web server vendor documentation for details.

6. Restart the application server.

Configuring Apache as a Proxy for JBoss

TheAdministrative and User Console runs in a J2EE application server, for example, JBoss, BEA Weblogic, and IBM WebSphere. You cannot install an AccessGate directly against these application servers. You can deploy a Web servre, for example, Apache, Oracle HTTP Server, and iPlanet in front of these application servers. You can deploy the AccessGate on the Web server, and configure the Web server to route requests to the Oracle Identity Manager application and forward responsees back to the user.

For application servers such as JBoss, you must deploy an additional plug-in, referred to as the mod_jk plug-in or the JBoss plug-in, on the Web server. You can obtain the mod_jk plug-in from the Apache Tomcat Web site, under the Tomcat connectors section. As of the time of publication, the URL as follows:

http://tomcat.apache.org/download-connectors.cgi

To configure the Apache HTTP server as a proxy for JBoss

1. Download and install a version of the Apache HTTP Server that is supported by Oracle Access Manager.

2. Download the latest stable version of the Jakarta (also known as Tomcat) mod_jk plug-in from the following URL:

   http://tomcat.apache.org/download-connectors.cgi

3. Extract the file and rename it to mod_jk.so.

4. Copy this file to the following directory:

   Apache_install_dir\modules

5. Create the following text files in the directory Apache_install_dir\conf:

   • mod-jk.conf

   • workers.properties

   • uriworkermap.properties

   Oracle recommends that you do not rename uriworkermap.properties and workers.properties. If you do, your configuration may stop working. The locations of these files are defined under two registry keys: worker_file and worker_mount_file. These files are in HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\version_number.

6. Copy the following configuration into the mod-jk.conf file:

   # Load mod_jk module
   # Specify the file name of the mod_jk lib
   LoadModule jk_module modules/mod_jk.so
    
   # Where to find workers.properties
   JkWorkersFile conf/workers.properties
    
   # Where to put jk logs
   JkLogFile logs/mod_jk.log
    
   # Set the jk log level [debug/error/info]
   JkLogLevel info
    
   # Select the log format
   JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
    
   # JkOptions indicates to send SSK KEY SIZE
   JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
    
   # JkRequestLogFormat
   JkRequestLogFormat "%w %V %T"
    
   # Mount  your  applications
   JkMount /application/* loadbalancer
    
   # You can use external file for mount points.
   # It will be checkded for updates each 60 seconds.
   # The format of the file is: /url=worker
   # /examples/*=loadbalancer
   JkMountFile conf/uriworkermap.properties
    
   # Add shared memory.
   # This directive is present with 1.2.10 and 
   # later versions of mod_jk, and is needed for
   # for load balancing to work properly
   JkShmFile logs/jk.shm
    
   # Add jkstatus for managing runtime data
   <Location /jkstatus/>
           JkMount status
           Order deny,allow
           Deny from all
           Allow from 127.0.0.1
   </Location>
   
   

7. Copy the following into the workers.properties file:

   # Define the list of workers that will be used
   # for mapping requests
   worker.list=loadbalancer
    
   # Define node1
   worker.node1.port=8009
   worker.node1.host=<Put your Identity Manager App Server FQDN name here>
   worker.node1.type=ajp13
   worker.node1.lbfactor=1
   worker.node1.local_worker=1 (1)
   worker.node1.cachesize=10
   #Load-balancing behaviour
   worker.loadbalancer.type=lb
   worker.loadbalancer.balance_workers=node1
   worker.loadbalancer.sticky_session=1
   worker.loadbalancer.local_worker_only=1
   
   

8. Copy the following into the uriworkermap.properties file.

   Configure the mapping according to the worker.list entry defined in the workers.properties file. This is not always loadbalancer, although this is shown in the following example:

   # Simple worker configuration file
   # Mount the servlet context to the ajp13 worker
   /jmx-console=loadbalancer
   /jmx-console/*=loadbalancer
   /web-console=loadbalancer
   /web-console/*=loadbalancer
   /xlWebApp=loadbalancer
   /xlWebApp/*=loadbalancer
   /Nexaweb=loadbalancer
   /Nexaweb/*=loadbalancer