| Oracle® Access Manager Integration Guide 10g (10.1.4.3) Part Number E12492-01 |
|
|
View PDF |
| Oracle® Access Manager Integration Guide 10g (10.1.4.3) Part Number E12492-01 |
|
|
View PDF |
This chapter describes integrating OracleAS Web Cache and Oracle Access Manager to provide post-data restoration and cookieless support. in Oracle Access Manager.
This chapter covers the following topics:
OracleAS Web Cache is a reverse proxy cache and compression engine that optimizes application performance and more efficiently utilizes low-cost existing hardware resources. OracleAS Web Cache provides whole-page caching for static and dynamic content based on caching rules. OracleAS Web Cache supports invalidation as a mechanism to keep the cache consistent with the content on the application Web servers (in this case in Oracle Access Manager). For more information about OracleAS Web Cache, see the Oracle Application Server Web Cache Administrator's Guide.
When integrated with Oracle Access Manager, OracleAS Web Cache also enables the following functions:
POST Data Restoration: WebGate uses Web Cache to provide POST data restoration after the POST request is interrupted for re-authentication due to timeout. performance. For more information, see "POST Data Restoration Scenario".
Cookieless Session Support: Oracle Access Manager uses Web Cache for cookieless session management. For more information, see "Cookieless Session Support Scenario".
For general information about this integration, see "Integration Scenarios and Architecture".
This section describes the integration architecture and flow of information after integrating Oracle Access Manager with OracleAS Web Cache for the following scenarios.
OracleAS Web Cache topology support for integration with Oracle Access Manager provides for a single Web Cache configured with Web Servers hosting resources in a 1:N mapping. The supported topology is shown in Figure 4-1.
Figure 4-1 Supported OracleAS Web Cache Topology
The following conditions apply to integration between Oracle Access Manager and OracleAS Web Cache:
OracleAS Web Cache cache clustering, failover, and load balancing are not supported with this integration scenario.
OracleAS Web Cache Authorization and Access Enforcement requires the mod_access module through the Oracle HTTP Server available in the OracleAS Web Cache Suite.
Oracle Application Server Single Sign-On Partner Applications (mod_osso) is not in part of the integration with Oracle Access Manager, which provides only Post Data Restoration and cookieless session support.
OracleAS Web Cache can be managed using the Oracle Enterprise Manager 10g Application Server Control Console: Port numbers 18100 and 9400 host the OracleAS Administration Console and OracleAS Web Cache Administration console, respectively.
Note:
All OracleAS Web Cache administration tasks are handled through the OracleAS Web Cache Administration console. However, you can use Oracle Process Manager and Notification (OPMN) as described in the Oracle Application Server Web Cache Administrator's Guide.Integration with OracleAS Web Cache adds a layer between the end-user browser and Oracle Access Manager components. Diagnosing connectivity issues requires investigation of both Web Cache logs and Oracle Access Manager component logs. Audit events can be captured between the browser and OracleAS Web Cache. These events can be correlated with the audit events captured between OracleAS Web Cache and WebGate. For more information about auditing Oracle Access Manager events, see the Oracle Access Manager Identity and Common Administration Guide.
With the integration of OracleAS Web Cache and Oracle Access Manager, POST data is retained and WebGate can retrieve it after the user re-authenticates. WebGate processes a POST data request after re-authentication only if WebGate gets the credential of the user who initiated the POST request.
Note:
Without this integration with OracleAS Web Cache, WebGate does not store POST data if the POST request is interrupted by an authentication event (for example, a secure session timeout).As a reverse proxy, OracleAS Web Cache acts a gateway to the back-end servers. Figure 4-2 illustrates the components and flow of information involved in POST-data restoration when Oracle Access Manager is integrated with OracleAS Web Cache.
Figure 4-2 POST Data Restoration Between OracleAS Web Cache and Oracle Access Manager
Process overview: POST data restoration with OracleAS Web Cache and Oracle Access Manager
User requests an Oracle Access Manager protected-resource from OracleAS Web Cache, which takes the request and generates a:
Private key (a unique identifier generated by OracleAS Web Cache for each request).
Cache ID (the id number for the owner cache). The cache ID is 0 by default because there is no cluster in OracleAS Web Cache.
Oracle Web Cache public cookie ORA_WX_SESSION. This is generated by the session binding mechanism, mostly when there are more than two Origin Servers. Therefore, it might be absent. It is not barred and sent to the browser during the cookieless transaction.
OracleAS Web Cache passes the request to WebGate, which forwards the request to Access Server, which challenges the user with form-based authentication.
After successful authentication and authorization, the requested page is sent to OracleAS Web Cache.
When the requested content is in the cache, OracleAS Web Cache sends the content to the user.
The user posts some data to the target resource received in Step 3, which is to be posted ahead to the Web server. To post the data, the user clicks the Submit button.
This Submit Button is made available by the Web Application Developer which triggers another HTML page that consumes the posted data. If the session expires or the idle session timeout is reached, the user is challenged for re-authentication with a Form Login Page.
When a POST request is interrupted by re-authentication, WebGate returns a unique identifier (UID) to OracleAS Web Cache to be used as a key for cached post data:
Protected Resource: If the resource was protected and the POST request interrupted by a timeout, the UID includes the user DN and OracleAS Web Cache private key.
Web Cache Not Available: WebGate passes the request to Oracle Access Manager.
After successful re-authentication by the requesting user, the halted POST data request is processed by WebGate and the requested item is sent by OracleAS Web Cache.
Note:
When restored POST data comes to WebGate, WebGate verifies that this request comes from the original user. If it is not from the original user, WebGate rejects posting data.Without this integration, Oracle Access Manager uses cookies to store user identity information for protected resources that require the same level (or a lower level) of authentication. Within Oracle Access Manager, the Access Server creates a session-based encrypted single sign-on cookie (the ObSSOCookie) and sends it to WebGate after successful authentication. WebGate sends the ObSSOCookie to the Web browser.
Note:
The Oracle Access Manager ObSSOCookie is a host cookie, accessible only by the Web site that issued it. The ObSSOCookie cannot be used to track user actions across different Web sites.With the ObSSOCookie, Oracle Access Manager supports following types of single sign-on (SSO):
Single Domain SSO: For the set of URLs within a single domain (for example, company.com).
Multi Domain SSO: For the set of URLs within more than one domain (for example, mycompany.com and yourcompany.com).
Without this integration, the user session expires when the ObSSOCookie expires or goes away for any reason.
Cookieless Sessions: With this integration, cookieless session support is provided for SSO with OracleAS Web Cache in front of:
One WebGate in a single domain
Multiple WebGates in a single domain
Multiple WebGates in multiple domains
Cookieless sessions are supported in several situations. For example:
Disabled Cookies on a Web Browser: The end user can explicitly turn off cookie support. A browser with cookies disabled must still be able to access a resource that is protected by Oracle Access Manager. In this case, the ObSSOCookie generated by Oracle Access Manager is stored in the OracleAS Web Cache server cache and can be retrieved by WebGate.
Mobile Device (or Devices that Cannot Process a Large Cookie): Electronic devices like mobile phones, PDAs, and other wireless devices have limited bandwidth. These devices might not be able to handle the ObSSOCookie due to the large amount of data in the cookie. This is similar to a cookie-disabled browser. However, in this case, the devices are mobile.
Privacy: A user can disable or disallow all cookies to protect their own privacy. Certain government agencies mandate that cookies on certain government Web sites must not contain any personal identity data, even if the cookie is encrypted. The cookies are only allowed to contain session identifiers.
Cookies can be used to track user movement among sites, which can be a sensitive issue in some countries and government agencies. The Oracle Access Manager ObSSOCookie is a host cookie, accessible only by the Web site that issued it. The ObSSOCookie cannot be used to track user actions across different Web sites.
Figure 4-3 illustrates processing during a cookieless session. Additional details follow the figure.
Figure 4-3 Cookieless Support When Oracle Access Manager is Integrated with OracleAS Web Cache
The Oracle Access Manager ObSSOCookie is passed by WebGate to OracleAS Web Cache
Process overview: In a cookieless session
User requests an Oracle Access Manager protected-resource from OracleAS Web Cache.
OracleAS Web Cache intercepts the request and:
If resource is not cached, OracleAS Web Cache sends a request to the Application Web server.
If the resource is protected by an Oracle Access Manager policy, the user is authenticated.
On successful authentication, an encrypted single sign-on cookie (ObSSOCookie) is generated and sent to the WebGate hosted by the Application Web server.
The ObSSOCookie is generated by the Access Server when a user authenticates successfully. This session-based cookie stores user identity information. For more information, see theOracle Access Manager Access Administration Guide.
OracleAS Web Cache:
Intercepts the ObSSOCookie sent by WebGate to the browser, along with the requested resource
Stores the ObSSOCookie and responds to the client by the sending the requested page
Utilizes the stored cookie for authenticating the user on subsequent requests until the cookie expires
Sends its own public cookie ORA_WX_SESSION to the user's Web browser.
Note:
OracleAS Web Cache cookie (ORA_WX_SESSION) expiration is not governed by Oracle Access Manager. For details about the OracleAS Web Cache cookie, see the Oracle Application Server Web Cache Administrator's Guide. However, ObSSOCookie expiration is governed by Oracle Access Manager as described in the Oracle Access Manager Access Administration Guide.For the latest Oracle Access Manager certification information, see the following procedure.
See Also:
"Integration Requirements"To locate the latest certification details
Go to Oracle Technology Network:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Locate Oracle Identity and Access Management, and then click the link for the latest Oracle Access Manager certification spreadsheet. For example:
System Requirements and Supported Platforms for Oracle Access Manager 10gR3 (xls)
http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls
You must install and configure OracleAS Web Cache release 10.1.2.2.1 (or greater) as a reverse proxy in-front of a WebGate Web server. This routes all requests to the Web server through OracleAS Web Cache. This integration requires the OracleAS 10.1.2.3 patch.
The following task overview outlines the tasks that you must perform to implement the integration scenarios in this chapter.
Task overview: Install and integrate components
Install and configure OracleAS Web Cache based on your intended usage, as described in "Installing Components for the Integration".
Configuration without SSL enabled can be used only for POST data restoration.
Configuration with SSL enabled can be used for cookieless session support (or POST data restoration).
Install and set up Oracle Access Manager, as described in "Installing Components for the Integration".
POST-Data Restoration: Perform tasks in "Configuring OracleAS Web Cache for Post Data Restoration".
Cookieless Sessions: Perform tasks in "Configuring OracleAS Web Cache for Cookieless Session Support".
Protect resources using Oracle Access Manager, as described in "Protecting Resources with Oracle Access Manager".
Testing: Perform tasks in "Validating and Testing the Integration".
This section introduces the tasks that must be performed to install components for the integration scenarios in this chapter.
You must install and configure OracleAS Web Cache release 10.1.2.2.1 (or greater) as a reverse proxy in-front of a WebGate Web server. This routes all requests to the Web server through OracleAS Web Cache.
Based on your intended usage the following conditions apply for installation and setup:
Without SSL Enabled: Use this for POST data restoration only.
Note:
Cookieless session support requires that you configure Web Cache and Oracle Access Manager with SSL communication enabled.SSL-Enabled: Use this for cookieless session support (or POST data restoration).
Note:
For Post Data Restoration, you can integrate Web Cache and Oracle Access Manager in either an SSL-enabled or non-SSL enabled deployments.The following task overview points to general steps provided in other books, and also to specific procedures that are included in this section. In the following procedure, a Windows example is featured.
Note:
Oracle Universal Installer lays down ORACLE_HOME in which OracleAS Web Cache is installed.Task overview: Install integration components
Install and set up Oracle Access Manager for the desired integration scenario, using information in the Oracle Access Manager Installation Guide.
See Also:
"Protecting Resources with Oracle Access Manager" for details about the policy base, policy domain root, and creating a Master Access Administrator.Install and set up OracleAS Web Cache as follows using instructions in the Oracle Application Server Web Cache Administrator's Guide:
Locate OracleAS Web Cache as either "J2EE and Web Cache"or "Web Cache Standalone" on the Oracle Technology Network at:
http://www.oracle.com/technology/software/products/ias/htdocs/101202.html
Install OracleAS Web Cache in-front of an Oracle Access Manager WebGate Web server. For example: as_windows_x86_j2ee_webcache_101202.zip.
Apply OracleAS patch 10.1.2.3 patch, as follows:
Apply patch 5983622 to install OracleAS Web Cache 10.1.2.3. For example: patch p5983622_10123_WINNT_webcache.zip.
Apply bundle patch 7438911, which includes Oracle Access Manager cookieless support. For example: p7438911_10123_WINNT.zip.
Apply patch 8255470.
See Also:
The My Oracle Support (formerly MetaLink) Web site at this URL for patches:
https://metalink.oracle.com.Configure OracleAS Web Cache as a reverse proxy.
Proceed as follows to complete the initial configuration:
Without SSL Enabled: Use this for POST data restoration only. See "Configuring OracleAS Web Cache Without SSL Enabled".
SSL-Enabled: Use this for cookieless session support (or POST data restoration). See "Configuring OracleAS Web Cache With SSL Enabled".
Following these steps for initial installation and setup, proceed as follows to meet your requirements:
This topic describes how to configure Web Cache when SSL is not enabled in the deployment.
For Post Data Restoration, you can integrate Web Cache and Oracle Access Manager in either an SSL-enabled or non-SSL enabled deployments. However, cookieless session support requires that you configure Web Cache and Oracle Access Manager with SSL communication enabled.
When you finish the following steps, resources hosted on the Web server configured as the origin server can be accessed using the Web Cache site computer:port URL. Any caching rules specified in the Site definition are applied to the accessed resources.
To configure OracleAS Web Cache for integration without SSL
Install OracleAS Web Cache and apply 10.1.2.3.0 patch set., as described in "Installing Components for the Integration".
Install Oracle Access Manager in Open mode on a non-SSL-enabled Web server, as explained in the Oracle Access Manager Installation Guide.
Access a OracleAS Web Cache administrative console. For example:
http://webcache_host.company.com:18100
In this example, webcache_host.company.com:18100 refers to the Oracle Application Server Administration site where the Oracle Application Server components, including OracleAS Web Cache, can be managed.
OR
http://webcache_host.company.com:9400
In this example, webcache_host.company.com:9400 refers to a dedicated OracleAS Web Cache Administration site where Web Cache processes and configurations can be managed (as in the Oracle Application Server Administration site). Port 9400 can be configured in the Oracle Application Server Administration site.
From the System Components of installed Oracle Application Server on the Administrative console, click Web Cache.
The following tabs are available: Home, Performance, Administration.
Click the Administration tab to view links for Web Cache configuration.
Under Properties, click the Ports link.
In the list of Listening ports, add a row to create a port for a Web Cache instance that can be used to access resources hosted on the configured back-end origin servers. For example:
IP Address: Enter * or the specific IP address of the computer hosting the Web Cache instance.
Port: Enter the unique port number for the Web Cache site used to access the resources hosted on the configured back-end origin server.
Protocol: Enter HTTP for a non-SSL site or HTTPS for an SSL-enabled site.
Client-side Certificate for HTTPS: Not Required.
Wallet for HTTPS: Leave blank.
Click OK and restart Web Cache.
Click the Administration tab.
Under Properties, click the Origin Server link.
Create a new entry for the origin server to be mapped with the Web Cache site.
Origin Server holds the computer:port of the Web server on which protected resources are hosted. This origin server entry when mapped with a Web Cache site makes us available with the resources hosted on the Web server using the Web Cache Site URL created in Step 7.
Click Create and add an entry for Origin Server,. For example:
Host: Name of the computer hosting the resource Web Server
Port: Number of the Web server listening port
Protocol: HTTP
Retain default values for other details on the Origin Server configuration page.
Click OK and restart Web Cache.
Click the Administration tab.
Under Properties, click Sites.
In the Named Sites Definition, click Create, and enter the following details under the General tab:
Host: Enter the name of the computer hosting Web Cache
Port: Enter the unique port number for the Web Cache site used to access the resources hosted on the configured back-end origin server (as specified in Step 7).
Prefix: Leave blank (optionally, enter as /*).
In the Origin Server details for the Site, move the computer:port entry of the origin server created in Step 11, as follows:
From: Available Origin Server List
To: Selected Origin Server List
Note:
More than one origin server entry can be moved to a selected origin server list. The moved entries are then used based on the load balancing concept.Click OK and restart Web Cache.
Proceed as needed:
This topic describes how to configure OracleAS Web Cache when SSL is enabled. Cookieless session support requires that you configure Web Cache and Oracle Access Manager with SSL communication enabled.
Note:
All normal listen ports (new and existing ones) must have SSL enabled because the cookie cache setting is global and cannot be turned on or off based on sites or ports. The cache does not work if some ports are SSL enabled while others are not. The only exceptions are the administration, invalidation, and statistics ports, which are not required to be SSL-enabled.For Post Data Restoration, you can integrate Web Cache and Oracle Access Manager in either an SSL-enabled or non-SSL enabled deployment.
Following topics provide the steps you must perform:
This topic provides the steps to create a wallet for OracleAS Web Cache SSL communication.
To create a wallet for OracleAS Web Cache SSL-enabled communication
Install OracleAS Web Cache and apply 10.1.2.3.0 patch set.
Install Oracle Access Manager in Simple or Cert mode using SSL enabled Web servers. For details, see the Oracle Access Manager Installation Guide.
Open Wallet Manager by clicking Start, Programs, Orahome, Integrated Management Tools, Wallet Manager.
From the Wallet Console:
Create a new wallet: Under the Wallet menu, click New.
Enter and confirm the wallet password.
Wallet Type: Standard.
Request to create a certificate request. Click Yes to create the certificate request for Web Cache and perform the following steps using information for your environment:
Fill in details for the certificate request, including:
Common Name: Enter the fully-qualified domain name of the computer hosting the Web Cache instance.
Organization Unit:
Organization:
Locality:
State:
Country:
Key Size: The default value can be retained.
Click OK.
Submit the certificate request.
Note:
The certificate request can be saved to a file with a .csr extension. To save the request for a .csr file: Right-click the Certificate request node in Wallet Manager, click Export Certificate Request, and save to any desired location with .csr extension. Also: OpenSSL can be used for any non-Oracle HTTP Server environment. OCA can be used for an Oracle HTTP Server-based environment.Get a signed from the Certificate Authority (CA).
Note:
If a trusted CA chain containing the OracleAS Web Cache certificate is imported, the following Step 7 is not required. Step 7 refers to the certificate generated on the creation of a new wallet, which is now signed by the Certificate Authority.Import the CA signed Web Cache certificate into the Wallet.
Note:
If a common CA is used the following Step 8 is not required because it refers to the certificate of the Certificate Authority.Import the certificate of the CA used to sign the certificate of the back-end Web server configured in SSL.
In the Wallet Manager, Wallet menu, check the Auto-Login box so it creates the .sso file of the wallet used during the SSL handshake activity.
Save the wallet to any desired location.
Verify that .sso and .p12 files are created from the above procedure
Proceed with "Configuring OracleAS Web Cache for SSL Communication"
Before you configure OracleAS Web Cache for SSL-enabled communication, you must create a wallet, as described in the previous topic.
When you finish the following steps, resources hosted on the Web server configured as the origin server can be accessed using the SSL-enabled Web Cache site computer:port URL. Any caching rules specified in the Site definition are applied to the accessed resources.
To configure OracleAS Web Cache for SSL-enabled communication
Install OracleAS Web Cache and apply 10.1.2.3.0 patch set.
Install Oracle Access Manager in Simple or Cert mode using SSL enabled Web servers. For details, see the Oracle Access Manager Installation Guide.
Access a Web Cache administrative console. For example:
http://webcache_host.company.com:18100
In this example, webcache_host.company.com:18100 refers to the Oracle Application Server Administration site where the Oracle Application Server components, including OracleAS Web Cache, can be managed.
OR
http://webcache_host.company.com:9400
In this example, webcache_host.company.com:9400 refers to a dedicated OracleAS Web Cache Administration site where Web Cache processes and configurations can be managed (as in the Oracle Application Server Administration site). Port 9400 can be configured in the Oracle Application Server Administration site.
From the System Components of installed Oracle Application Server on the Administrative console, click Web Cache.
The following tabs are available: Home, Performance, Administration.
Click the Administration tab to view links for Web Cache configuration.
Under Properties, click the Ports link.
In the list of Listening ports, add a row to create a port for a Web Cache instance that can be used to access resources hosted on the configured back-end origin servers. For example:
IP Address: Enter * or the specific IP address of the computer hosting the Web Cache instance.
Port: Enter the unique port number for the Web Cache site used to access the resources hosted on the configured back-end origin server.
Protocol: Enter HTTP for a non-SSL site or HTTPS for an SSL-enabled site.
Client-side Certificate for HTTPS: Not Required.
Wallet for HTTPS: Provide the exact location of the Wallet created in "Creating a Wallet for OracleAS Web Cache SSL Communication".
Click OK and restart Web Cache.
Click the Administration tab.
Under Properties, click the Origin Server link.
Create a new entry for the origin server to be mapped with the Web Cache site.
Origin Server holds the computer:port of the Web server on which protected resources are hosted. This origin server entry when mapped with a Web Cache site makes us available with the resources hosted on the Web server using the Web Cache Site URL created in Step 7.
Click Create and add an entry for Origin Server,. For example:
Host: Name of the computer hosting the resource Web Server
Port: Number of the Web server listening port
Protocol: HTTPS
Retain default values for other details on the Origin Server configuration page.
Click OK and restart Web Cache.
Click the Administration tab.
Under Properties, click Sites.
In the Named Sites Definition, click Create, and enter the following details under the General tab:
Host: Enter the name of the computer hosting Web Cache.
Port: Enter the unique port number for the Web Cache site used to access the resources hosted on the configured back-end origin server (as specified in Step 7).
Prefix: Leave blank (optionally, enter as /*).
In the Origin Server details for the Site, move the computer:port entry of the origin server created in Step 11, as follows:
From: Available Origin Server List
To: Selected Origin Server List
Note:
More than one origin server entry can be moved to a selected origin server list. The moved entries are then used based on the load balancing concept.Click OK and restart Web Cache.
Proceed as needed:
To configure OracleAS Web Cache for POST Data restoration, you must modify the webcache.xml file.
For POST Data restoration, you must add the POSTBODYCACHE element under the <GENERAL> node, after the <ACCESSLOG> nodes (and the SITES node, if any), and before the <SITE> nodes.
Other attributes for the POSTBODYCACHE elements include:
MAXAGE: The time, in seconds, that POST content can stay in the cache. The default is 120 seconds.
MAXCACHEABLESIZE: The maximum size, in bytes, of POST request content that is considered cacheable. The default is 8152 bytes.
Note:
Take care when editing webcache.xml. Improper editing can result in errors.To configure OracleAS Web Cache for POST data restoration
Locate webcache.xml in the following path:
$ORACLE_HOME/webcache/config/webcache.xml
Add the POSTBODYCACHE element under the <GENERAL> node and before the <SITE> nodes, as shown in the following example:
<GENERAL> ...
<ACCESSLOG> ...
<POSTBODYCACHE> ...
<POSTBODYCACHE ENABLED="YES" MAXAGE="120" MAXCACHEABLESIZE="8152" />
<SITE> ...
Restart the Web Cache server.
Proceed to "Protecting Resources with Oracle Access Manager".
To configure OracleAS Web Cache for cookieless session support, you modify webcache.xml to include the COOKIECACHE element under the <GENERAL> node, after the <ACCESSLOG> nodes and before the <SITE> element.
Other attributes for the COOKIECACHE elements include
COOKIENAME: 0 or more sub-elements can be defined as follows:
<COOKIENAME="cookiename"/>
Here cookiename represents the actual name of the cookie that Web Cache is to cache.
Note:
If no COOKIE elements are specified, then all cookies are cached.REDIRECTURL: The SSO redirect URL for sign on that is used for domain cookie association.
PASSNOCACHECOOKIES: For cookies that do not match the list of names specified in COOKIE elements you can determine if Web Cache passes them on or strip them of all responses. Values are:
YES: The default specifies that Web Cache passes cookies on to browser clients.
NO: Cookies are stripped from all responses.
The following procedure describes how to configure Web Cache for cookieless session support.
Note:
Take care when editing webcache.xml. Improper editing can result in errors. Also, cookieless session support requires that you configure Web Cache and Oracle Access Manager with SSL communication enabled. For details, see "Configuring OracleAS Web Cache With SSL Enabled"To configure OracleAS Web Cache for cookieless session support
Locate webcache.xml in the following path:
$ORACLE_HOME/webcache/config/webcache.xml
Add the COOKIECACHE element under the <GENERAL> node and before the <SITE> nodes, as shown in the following example:
<GENERAL> ... <ACCESSLOG> ... <POSTBODYCACHE> ... <SITE> ... <COOKIECACHE ENABLED="YES" COOKIENAME="OBSSOCOOKIE"/> REDIRECTURL="http://www.oracle.com" /> PASSNOCACHECOOKIES=No/>
Restart the Web Cache server.
Proceed to "Protecting Resources with Oracle Access Manager".
For the integration scenarios in this chapter to operate properly, Web server resources must be protected by an Oracle Access Manager policy domain and access policies. Before you protect resources, you must perform the following prerequisite tasks.
Prerequisites for the Master Administrator
Define the policy base during Policy Manager setup.
To review the policy base from the Access System Console, click System Configuration, Server settings. On the View Server Settings page, locate the Policy Data Configuration section to obtain the computer name, port, root DN, directory server security, and policy base, as described in the Oracle Access Manager Access Administration Guide.
Define the policy domain root during Policy Manager setup.
During Policy Manager setup, the Master Administrator specifies a policy domain root. This is a URL prefix under which all resources are protected. The default policy domain root must be broad to encompass all of your resources. The default root is /. For more information, see the Oracle Access Manager Access Administration Guide.
Create a Master Access Administrator to create policy domains, resource types, and access control schemes, and to assign the role of Delegated Administrator of a policy domain to other people.
Only a Master Administrator can create Master Access Administrators. A Master Access Administrator can perform any function in the Access System (except creating other Master Access Administrators), and can delegate administrative functions. Topics on configuring Master Access Administrators and delegating policy domain administration in the Oracle Access Manager Access Administration Guide.
A Master Access Administrator (or a Master Administrator) must create the first policy domain after the policy domain root is defined. He or she can then create policy domains for URLs beneath the first one and delegate administration of those policy domains to other administrators. Tasks in the following overview outline activities needed to create a policy domain the first policy domain to protect Web resources.
See Also:
The Oracle Access Manager Access Administration Guide for more information about each of the following tasks.Task overview: Creating a policy domain
First Domain: If this is the first policy domain, the following tasks must be performed before the policy domain is created.
Configure the resource types for any resources to be included in the domain (if the types are not already defined by default). You need these in task 2c.
From the Access System Console, click the Access System Configuration tab, click the Common Information Configuration link in the left pane, then click the Resource Type Definitions sub-tab.
Create the Master Audit Rule. This is needed in task 2f. The Access System does not log any audit information to the audit log file until the Master Administrator or Master Access Administrator creates a Master Audit Rule.
The Master Audit Rule can be configured by a Master Access Administrator. Delegated Access Administrators can use the Master Audit Rule to create their own audit rules for policy domains and policies.
From the Access System Console, click the Access System Configuration tab, click Common Information Configuration in the left pane, then click the Master Audit Rule sub-tab.
Create an authentication scheme to use in the policy domain. A policy domain must have at least one authentication rule and therefore one authentication scheme. You need this scheme during task 2e.
An authentication scheme includes the method used to challenge the user for credentials. It also includes one or more steps, each of which can include one or more plug-ins that perform part of the authentication process. A single-step scheme, or a chained scheme, requires an authentication flow.
From the Access System Console, click the Access System Configuration tab, then click the Authentication Management link in the left pane.
Create the authorization scheme to use in the policy domain. This is needed if if custom authorization schemes are to be utilized using authorization plug-ins. Otherwise, the policy domain enables you to create specific authorization rules that make up an authorization expression.
You need an authorization scheme (also known as an authorization plug-in) for every authorization rule that you define. You can use the default authorization scheme, or provide a custom one. A policy domain requires an authorization expression containing at least one authorization rule. Once a scheme is defined, Delegated Access Administrators for different policy domains can use the same scheme in rules for their domains or in rules for policies within their domains.
From the Access System Console, click Access System Configuration, click Authorization Management in the left pane. You may want to view the contents and definition of existing authorization schemes before you create new ones.
Create the policy domain, as outlined here and described in the Oracle Access Manager Access Administration Guide:
Create Policy Domain and specify general information:
From the Policy Manager, click Create Policy Domain in the left pane.
General: Click this tab and then enter general information about this policy domain (Name and optional Description).
Resources: Click the Resources tab, click Add, select the Resource type (see Step 1, above), Host Identifier, URL prefix, enter a description, and click Save.
The URL prefix is the starting point for resources in a policy domain. A URL prefix defines the beginning boundary of a policy domain (its first resource). A URL prefix maps to a directory on the file system of one of your application servers or Web servers.
Authorization Rules: Specify general information, timing conditions, actions, and access (Allow or Deny) conditions.These fields are optional and if not specified use default values. However, most policy domains specify the access (Allow or Deny) conditions.
Click the Authorization Rules tab, click Add, and enter general information about the rule, then Save.
Timing Conditions: Click Timing Conditions. If none are defined, the rule is valid at all times. Add timing conditions as needed.
Actions: Click Actions and specify an associated set of actions to occur in response to authorization success or failure when a user requests access to a protected resource.
Allow Access: If no conditions are specified, no one is allowed access. Click Allow Access and add appropriate information.
Deny Access: If no conditions are specified, no one is denied access. Click Deny Access and add appropriate details.
Enable the Rule: If you do not enable this rule, it is not be available when you create an authorization expression. Click the Authorization Rules tab, click the box beside the rule, and click Enable.
Default Rules: This is where you add the authentication rule and authorization expression.
Authentication Rule: Click the Default Rules tab to display the General and Actions tabs for this rule. Click Add, and enter details for the rule, including an authentication scheme (see task 3 above) that specifies how to verify a user's identity. Click Actions, click Add, and specify the optional actions for authentication failure, authentication success, or both.
Note:
A policy domain must have one—and only one— authorization expression. The Authorization Expression is created from the available and defined authorization rules. If a custom authorization scheme is defined (Step 1d), you can select it from the list provided for the Authorization rule (Step 2d) in the policy domain. The other option in the list is the Oracle authorization scheme.Authorization Expression: Click the Authorization Expressions tab, click Add, and create the expression. Duplicate Actions: If no policy is defined, the Access System level default policy for duplicate action headers is used. From the Duplicate Actions sub-tab, you can change this. Actions: From this sub-tab you can specify an associated set of actions in response to authorization success or failure or inconclusive results.
Audit Rule: If there is no Master Audit Rule defined, you are instructed to contact your Access System Administrator.
Policies: Before setting up a policy, decide the level of access control that is needed for the URL that you want to protect. For each policy you create, you can assign a specific authentication rule, authorization expression, and auditing rule. If no rules are defined, the default rules for the policy domain remain in effect (defined in task 2e).
Click the Policies tab, and fill in general information for this policy.
Click the name of the policy to display the sub-tabs for this policy.
Authentication Rule: Click this sub-tab and then click Add (or click View Default). Create (or edit) as authentication rule for this policy. The guidelines for this rule are the same as for the policy domain
Authorization Expressions: Click this sub-tab and then click Add (or click View Default). Create (or edit) an authorization expression for this policy. The guidelines for this expression are the same as for the policy domain.
Audit Rule: Click this sub-tab. If there is no Master Audit Rule defined and you want to add an auditing rule to this policy, you are instructed to contact your Access System Administrator.
Delegated Admins: Only Delegated Access Administrators who have rights to a specific domain—or the Master Access Administrator—can view a policy domain. Click the Delegated Admins tab.
When you are ready, enable the policy domain.
Test the policy domain, as described in the Oracle Access Manager Access Administration Guide.
For more information about setting up an Oracle Access Manager policy domain, authentication scheme, and access policies, see the Oracle Access Manager Access Administration Guide.
Here are some details for testing the integrations:
You can perform the following functions to test your POST data restoration configuration.
POST data restoration provides a function that prevents the WebGate from losing posted data if the POST request is interrupted by an authentication event. To test this, you can use any simple form-type resource containing fields where a user can enter data to be posted (for example, username and password fields to authenticate the user). The form resource used to post data, directs the posted data to a target resource page that collects the posted data. The authentication scheme used to protect this resource must use the Form challenge method.
During this test, you attempt to access the form resource and provide valid credentials. When the form appears, enter the data to be posted in the text fields provided and then wait for a period greater than idle session timeout to force re-authentication. This tests whether posted data can be restored after a re-authentication event. After the session timeout, submit the data and then provide user credentials when asked. You should be re-authenticated. Once re-authenticated, if the posted data is restored in the target resource page, POST data restoration is verified.
To test POST data restoration functionality
In a browser window, enter the Web Cache host and port as you access an Oracle Access Manager protected resource.
Login with appropriate user credentials to obtain the resource protected by Oracle Access Manager.
Enter values in the text fields: (i.e. user name and department name). For example:
user name and department name
Here "user name" and "department name" are not used to authenticate the user, but are used to illustrate the data that might be posted by the user.
Remain idle; do not make any modifications for a period longer than the idle session timeout.
In Step 4 you are on the page containing text fields where the user enters the data to be posted. Remain idle for a period longer than the idle session timeout to force a re-authentication. During this period, do not perform any operation or modification on this page. This allows idle session time to expire.
Enter the remaining fields and click "Submit" or "Next" which ever applies.
Entering data into remaining text fields is an optional step. The required action to be performed here is submitting the data to be posted after the idle session timeout occurs.
After the idle session timeout occurs, you are asked to re-authenticate.
Provide user credentials when asked to obtain the resource protected by Oracle Access Manager.
After successful re-authentication, you are directed to the requested page. The page should be able to populate the Posted data from Web Cache.
You can perform the following functions with Oracle Access Manager to test cookieless session support.
To accomplish this task you must have added the XML tag COOKIECACHE into the webcache.xml file. For details, see "Configuring OracleAS Web Cache for Cookieless Session Support".
To test cookieless session support
In a browser window, enter the Web Cache host and port as you access an Oracle Access Manager protected resource.
Login with appropriate user credentials to obtain the resource protected by Oracle Access Manager.
Access to the resource should be granted.
Check for headers received by the Web browser using tools like HTTPheaders.
Oracle does not provide tools to check for headers received by the Web browser.
An OracleAS Web Cache-generated public cookie (ORA_WX_SESSION) should be seen as received by the Web browser. The Oracle Access Manager ObSSOCookie should not be sent to the Web browser.
Restart the Web Cache server.
The Oracle Access Manager auditing feature collects and presents data pertaining to policy and profile settings, system events, and usage patterns. You can record all dynamic audit reports and some static audit reports to disk file, to a relational database, or both. Some static reports can also be displayed in limited form through the graphical user interface.
In addition to auditing, an Oracle Access Manager component instance can write information about its processes and states to a log file. The logs can be configured to provide information at various levels of granularity. For example, you can record errors, errors plus state information, or errors, states, and other information to the level of a debug trace. You can also eliminate sensitive information from the logs.
For more information about auditing and logging with Oracle Access Manager, see the Oracle Access Manager Identity and Common Administration Guide.
With Oracle Enterprise Manager 10g Application Server Control Console or OracleAS Web Cache Manager, you can view a list of the most popular requests and a list of the contents of the cache.
OracleAS Web Cache events and errors are stored in an event log. The event log can help you determine which objects have been inserted into the cache. It can also identify listening port conflicts or startup and shutdown issues. OracleAS Web Cache generates an access log that contains information about the HTTP requests sent to OracleAS Web Cache.
For more information about using diagnostic tools with Oracle Web Cache, see the Oracle Application Server Web Cache Administrator's Guide.
This section provides tips to help you troubleshoot any issues.
Non-SSL Oracle Access Manager with SSL OracleAS Web Cache and Cookieless Session
Target HTML Files Available with No Authentication on Subsequent Access Attempts
Problem
When Post Data Restoration is enabled, double authentication might occur on login with a user other than the one who logged in to the original session. The target resource is made available to the end user based on the authorization set for the protected resource. If a user attempts access with the credentials of a user who cannot be authenticated, the login form appears until the maximum login tries limit is exceeded.
Cause
This is expected behavior. On a re-authentication event, the user can log in with the same credentials or those of another known user. However, in the second case, the login form appears twice.
Solution
A user must authenticate twice if they are using the same browser on which another user already tried to log in.
Problem
Whenever Web Cache is configured in front of Oracle Access Manager for post-data restoration and cookieless support, enabling a challenge redirect for authentication to a separate WebGate does not function properly if the WebGate host port are directly provided in the authentication scheme definition. The redirection occurs but the features may not serve their purpose. In the case of SSL transactions, session restoration issues might occur.
Cause
If the host port of the authenticating WebGate is directly provided in the Oracle Access Manager authentication scheme definition, redirections to the authenticating WebGate during authentication do not take Web Cache into account.
Solution
When enabling a challenge redirect for Oracle Access Manager wherein a separate authenticating WebGate is to be used for authentication, then you must configure a Web Cache site that corresponds to the authenticating WebGate host port.
To solve the redirection or session restoration issue
Ensure that a Web Cache site has been defined for the corresponding authenticating WebGate.
Confirm that the Web Cache site's host port is mentioned in the challenge redirect field of the authentication scheme to redirect authentication to the specified back-end WebGate.
Problem
The https session is converted into a http session, which leads to an inaccessible site. The issue is mainly observed on accessing folder structure-based resources.
Cause
Cookieless sessions demand SSL communication between the OracleAS Web Cache site and the Oracle Access Manager originating server. As a result, a non-SSL-enabled Oracle Access Manager originating server. can lead to an error.
Solution
You must add information in the Oracle HTTP Server (OHS or OHS2) httpd.conf file to configure a non- SSL hosted Oracle Access Manager with an SSL-enabled OracleAS Web Cache site and a cookieless session.
Note:
This solution is not yet supported for other Web server types.To support a cookieless session with a non- SSL hosted Oracle Access Manager and an SSL-enabled OracleAS Web Cache site
Locate and open the OHS or OHS2 http.conf file in a text editor. For example:
OHS_install_dir/conf/httpd.conf
OHS: Add the following information to the end of the httpd.conf file.
LoadModule certheaders_module libexec/mod_certheaders.so AddCertHeader HTTPS SimulateHttps On
OHS2:
LoadModule certheaders_module modules/mod_certheaders.so AddCertHeader HTTPS SimulateHttps On
Save the file.
Problem
Accessing Oracle Access Manager-protected HTML files using Web Cache site URLs might cause the sessions to get copied if the HTML caching rule is enabled for Web Cache. This results in authentication only in the first access attempt to access the HTML file. On subsequent access attempts, the file might be available to the user without authentication. Also, the HTML caching rule might cause the cookies generated on the first successful access attempt to be utilized for further access to the same HTML file.
Cause
The Web Cache HTML caching rule causes the entire HTML file and its contents to be cached for future rapid access.
Solution
If a HTML caching rule is enabled for the Web Cache, then it may cause session copies for protected HTML files. It may cause to have the target HTML files available without authentication.
Disable the HTML caching rule from the Web Cache Administration Console.
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|