| Oracle® Fusion Middleware Application Security Guide 11g Release 1 (11.1.1) Part Number E10043-12 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Application Security Guide 11g Release 1 (11.1.1) Part Number E10043-12 |
|
|
PDF · Mobi · ePub |
The chapter describes how to configure single sign-on using Oracle Access Manager 10g. It includes the following major sections:
Oracle Access Manager Authentication Provider Parameter List
Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g
Configuring Identity Assertion for Oracle Web Services Manager and OAM 10g
Synchronizing the User and SSO Sessions: SSO Synchronization Filter
This section provides the following topics:
Installing and Setting Up Authentication Providers for OAM 10g
Oracle Access Manager Authentication Provider Parameter List
Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates
This topic provides an overview of Oracle Access Manager installation and initial setup and additional information about installing components and files for use when you deploy the Oracle Access Manager Authentication Provider.
Unless explicitly stated, these topics describe requirements for both the Oracle Access Manager Identity Asserter and the Oracle Access Manager Authenticator:
Installing Components and Files for Authentication Providers and OAM 10g
Converting Oracle Access Manager Certificates to Java Keystore Format
This topic provides a brief installation and setup overview if you are new to Oracle Access Manager.
Access Servers: For the Oracle Access Manager Authentication Provider, you need two Access Servers for WebGates or AccessGates: one primary server and one secondary server. Currently, only one secondary Access Server is supported. Installing Access Servers includes:
Adding an Access Server configuration profile in the Access System Console for the primary server. Ensure that the Access Management Service is On (also known as Policy Manager API Support Mode).
Adding a secondary Access Server configuration profile with the Access Management Service On.
Installing the primary Access Server instance.
Installing the secondary Access Server instance.
WebGate/AccessGate: Whether you need a WebGate or an AccessGate depends on your use of the Oracle Access Manager Authentication Provider. For instance, the:
Identity Asserter for Single Sign-On: Requires a separate WebGate and configuration profile for each application to define perimeter authentication. Ensure that the Access Management Service is On.
Authenticator or Oracle Web Services Manager: Requires a separate AccessGate and configuration profile for each application. Ensure that the Access Management Service is On.
About OAM 10g WebGate/AccessGate Profiles and Policy Domains
This topic introduces the WebGate/AccessGate profiles, policy domains, and the methods you can use the create these.
While there are subtle differences between WebGates and AccessGates, these terms are often used interchangeably. In the Access System Console, the configuration profile for WebGates or AccessGates is known as an AccessGate profile. The Policy Manager is where an Oracle Access Manager policy domain is created.
Access System Console Method: Enables users with specific Oracle Access Manager administration rights to enter information and set parameters directly in Oracle Access Manager. This method is required if you are using the Authenticator, or if you have Oracle Web Services Manager policies protecting Web services.
OAMCfgTool Method: Application administrators who are implementing the Identity Asserter for single sign-on, can use OAMCfgTool to create a new WebGate profile for a fresh Web Tier. Required parameters are provisioned using values for your environment specified on the command line. Default values are accepted for non-required parameters; the Access Management Service is set to On. After creating a profile, values can be modified in the Access System Console.
Each AccessGate profile must include the following parameters; those marked with an asterisk, *, are provisioned with OAMCfgTool:
*AccessGate Name—A unique name without spaces. With OAMCfgTool the name is derived from the app_domain value, appended with _AG.
*Hostname—The name of the computer where the WebGate/AccessGate is or will be installed. With OAMCfgTool the app_domain value is used as the host name.
*AccessGate Password—A unique password to verify and identify the component. This prevents unauthorized AccessGates from connecting to Access Servers and obtaining policy information. With OAMCfgTool, this is specified with the app_agent_password parameter. This should differ for each WebGate/AccessGate instance.
Transport Security—The level of transport security between the Access Server and associated WebGates (these must match). The default value is Open. You can specify a different value with OAMCfgTool oam_aaa_mode value.
*Preferred HTTP Host—The host name as it appears in all HTTP requests as users attempt to access the protected Web server. The host name in the HTTP request is translated into the value entered into this field, regardless of the way it was defined in a user's HTTP request. With OAMCfgTool the Preferred HTTP Host is the app_domain value.
The Preferred Host function prevents security holes that can be inadvertently created if a host's identifier is not included in the Host Identifiers list. However, it cannot be used with virtual Web hosting. For virtual hosting, you must use the Host Identifiers feature.
*Primary HTTP Cookie Domain: The Web server domain on which the WebGate is deployed. The cookie domain is required to enable single sign-on among Web servers; each must have the same Primary HTTP Cookie Domain value. Use the cookie_domain parameter with the OAMCfgTool to set this value.
See Also:
"About Administrative Requirements for AccessGate Profiles and Policy Domains"
"Configuring WebGates and Access Servers" in the Oracle Access Manager Access Administration Guide
About Administrative Requirements for AccessGate Profiles and Policy Domains
This topic introduces the administrative rights needed for the methods you can use when creating new WebGate and AccessGate profiles and policy domains for Oracle Access Manager.
An Oracle Access Manager Master Access 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.
Access System Console Method: You must be a Master or Delegated Access Administrator can use the Access System Console to create a new AccessGate profile, associate it with an Access Server, and create an authentication scheme. Master or Delegated Access Administrators can also use the Policy Manager to create a policy domain. The following deployments require this method:
Authenticator
Identity Asserter when Oracle Web Services Manager is protecting Web services
OAMCfgTool Method: You do not need specific Oracle Access Manager administration rights for OAMCfgTool, which automates creating and associating a WebGate profile and creating a new policy domain. However, this method can be used for only Identity Assertion. In a:
Fresh Web Tier: Use OAMCfgTool to streamline creating a new WebGate profile and policy domain for Identity Asserter only.
After creating the profile and policy domain with OAMCfgTool, these can be modified in the Access System Console.
See Also:
Existing Web Tier: When one or more WebGates exist in the Web Tier, no new WebGate is needed. However, you can specify an existing host identifier to make newly established policies enforceable by an existing WebGate.
See Also:
"Installing Components and Files for Authentication Providers and OAM 10g"
"Configuring WebGates and Access Servers" in the Oracle Access Manager Access Administration Guide
The following task overview outlines the components and files that must be installed and where to locate more information.
Note:
If you already have components installed and set up, you do not need to install new ones. Skip any steps that do not apply to your deployment.
Unless specifically stated, all details apply whether you intend to deploy the Identity Asserter for single sign-on, or the Authenticator, or if Oracle Web Services Manager policies are protecting Web services.
Task overview: Installing required components and files for Oracle Access Manager 10g Authentication Provider
An Oracle Internet Directory or Oracle Sun One LDAP directory server configured to be used by the Oracle Access Manager Access Server. Ensure that the directory server is tuned for your deployment.
See Also:
The following Release 11g (11.1.1.1.0) manuals
Install and set up Oracle WebLogic Server 10.3.1+.
See Also:
Item 3 in this list, and the Oracle Fusion Middleware Getting Started With Installation for Oracle WebLogic Server
Optional: Install a Fusion Middleware product (Oracle Identity Manager, Oracle SOA Suite, or Oracle Web Center for example):
Note:
Without a Fusion Middleware application, you must acquire the required JAR and WAR files as described in later procedures.
Confirm the location of required JAR files in the following Fusion Middleware path:
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
Locate the console-extension WAR file in the following path:
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov ider.war
Copy the WAR file to the following path in the WebLogic Server home:
WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
Install OHS 11g for the Oracle Access Manager 10g (10.1.4.3) WebGate, if needed:
Authenticator or Oracle Web Services Manager: No Web server is required for the custom AccessGate. The protected resource is accessed using its URL on the Oracle WebLogic Server.
Oracle Access Manager Identity Asserter: Requires Oracle HTTP Server 11g Web server configured as a reverse proxy in front of Oracle WebLogic Server.
Install Oracle Access Manager 10g (10.1.4.3) components and perform initial setup as follows:
Install an Identity Server; install a WebPass; set up the Identity System.
Install and set up Policy Manager. Ensure that the policy protecting the Policy Manager, /access, is created and enabled, as well as the default authentication schemes.
Install Access Servers (one as a primary server and one as a secondary server for WebGate).
Add an Access Server configuration profile in the Access System Console for the primary server for WebGate. Ensure that the Access Management Service is On (also known as Policy Manager API Support Mode).
Add a secondary Access Server configuration profile with the Access Management Service On.
Install the primary Access Server instance and then install the secondary Access Server instance.
Note:
Only one secondary Access Server is supported
WebGate for Identity Asserter for Single Sign-On: In an existing Web Tier with one or more WebGates, no new WebGates or profiles are needed.
See Also:
In a fresh Web Tier, you must create a profile to define the WebGate for perimeter authentication, as follows:
Create an AccessGate configuration profile to define the WebGate for perimeter authentication. Ensure that the Access Management Service is On. You can use the OAMCfgTool or Access System Console.
Associate the WebGate profile with a primary and a secondary Access Server.
Install a WebGate for Oracle HTTP Server 11g configured as a reverse proxy for every application.
Repeat until you have a profile and a WebGate protecting each application.
AccessGate: For the Authenticator, or when you have Oracle Web Services, Manager you must add a new profile for custom AccessGates in the Access System Console
Add an AccessGate configuration profile in the Access System Console and ensure that the Access Management Service is On.
Associate the AccessGate profile with a primary and a secondary Access Server.
Deploy the custom AccessGate in oamAuthnProvider.jar.
Repeat until you have a profile and a AccessGate protecting each application.
Proceed as follows:
Simple or Cert Mode: "Converting Oracle Access Manager Certificates to Java Keystore Format"
Authenticator or Oracle Web Services Manager: "Creating Resource Types in Oracle Access Manager 10g" must be performed if you use the Oracle Access Manager Authenticator or if you have Oracle Web Services Manager policies protecting Web services.
Identity Asserter for Single Sign-On: Perform tasks in "Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g".
Oracle recommends that all Java components and applications use JKS as the keystore format. This topic provides steps to convert Oracle Access Manager X.509 certificates to Java Keystore (JKS) format. These steps, when followed properly, generate the JKS stores that can be used while the Java NAP client wants to communicate with an Oracle Access Manager Access Server in Simple or Cert (certificate) mode.
When communicating in Simple or Cert mode, the Access Server uses a key, server certificate, and CA chain files:
aaa_key.pem: the random key information generated by the certificate-generating utilities while it sends a request to a Root CA. This is your private key. The certificate request for WebGate generates the certificate-request file aaa_req.pem. You must send this WebGate certificate request to a root CA that is trusted by the Access Server. The root CA returns the WebGate certificates, which can then be installed either during or after WebGate installation.
aaa_cert.pem: the actual certificate for the Access Server, signed by the Root CA.
aaa_chain.pem: the public certificate of the Root CA. This is used when peers communicating in Simple or Cert mode perform an SSL handshake and exchange their certificates for validity. In Simple Mode, the aaa_chain.pem is the OpenSSL certificate located inAccessServer_install_dir/access/oblix/tools/openssl/simpleCA/cacert.pem
Here, aaa is the name you specify for the file (applicable only to Cert and chain files).
You can edit an existing certificate with a text editing utility to remove all data except that which is contained within the CERTIFICATE blocks. You then convert the edited certificate to JKS format, and import it into the keystore. Java KeyTool does not allow you to import an existing Private Key for which you already have a certificate. You must convert the PEM format files to DER format files using the OpenSSL utility.
To convert an Oracle Access Manager certificate to JKS format and import it
Install and configure Java 1.6 or the latest version.
Copy the following files before editing to retain the originals:
aaa_chain.pem
aaa_cert.pem
cacert.pem, only if configuring for Simple mode
Edit aaa_chain.pem using TextPad to remove all data except that which is contained within the CERTIFICATE blocks, and save the file in a new location to retain the original.
-----BEGIN CERTIFICATE----- ... CERTIFICATE ... -----END CERTIFICATE-----
Run the following command for the edited aaa_chain.pem:
JDK_HOME\bin\keytool" -import -alias root_ca -file aaa_chain.pem -keystore rootcerts
Here you are assigning an alias (short name) root_ca to the key. The input file aaa_chain.pem is the one that you manually edited in step 3. The keystore name is rootcerts.
You must give a password to access the keys stored in the newly created keystore.
Note:
To ensure security, Oracle recommends that you allow the keytool to prompt you to enter the password. This prompt occurs automatically when the “-storepass” flag is omitted from the command line.
Enter the keystore password, when asked. For example:
Enter keystore password: <keystore_password> Re-enter new keystore password: <keystore_password>
Enter Yes when asked if you trust this tool:
Trust this certificate? [no]: yes
Confirm that the certificate has been imported to the JKS format by executing the following command and then the password.
JDK_HOME\bin\keytool" -list -v -keystore "rootcerts" Enter keystore password: <keystore_password>
Look for a response like the following:
Keystore type: JKS Keystore provider: SUN Your keystore contains n entries Alias name: root_ca Creation date: April 19, 2009 Entry type: trustedCertEntry Owner: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, O="Oblix, Inc.", L=Cupertino, ST= California , C=US Issuer: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, O="Oblix, Inc.", L=Cupertino, ST= California ,C=US Serial number: x Valid from: Tue Jul 25 23:33:57 GMT+05:30 2000 until: Sun Jul 25 23:33:57 GMT+05:30 2010 Certificate fingerprints MD5: CE:45:3A:66:53:0F:FD:D6:93:AD:A7:01:F3:C6:3E:BC SHA1: D6:86:9E:83:CF:E7:24:C6:6C:E1:1A:20:28:63:FE:FE:43:7F:68:95 Signature algorithm name: MD5withRSA Version: 1 *******************************************
Repeat steps 3 through 7 for the other PEM files (except aaa_chain.pem unless there is a chain).
Convert the aaa_key.pem file to DER format using the OpenSSL utility in the Access Server installation directory path. For example:
AccessServer_install_dir\access\oblix\tools\openssl>openssl pkcs8 -topk8
-nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der –outform DER
Here the input file is aaa_key.pem and the output file is aaa_key.der. Additional options include:
Table 17-1 Options to Create DER Format Files from PEM
| Option | Description |
|---|---|
|
-topk8 |
Reads a traditional format private key and writes a PKCS#8 format key. This reverses the default situation where a PKCS#8 private key is expected on input and a traditional format private key is written. |
|
-nocrypt |
An unencrypted PrivateKeyInfo structure is expected for output. |
|
-inform |
Specifies the input format. If a PKCS#8 format key is expected on input, then either a DER or PEM encoded version of a PKCS#8 key is expected. Otherwise the DER or PEM format of the traditional format private key is used. |
|
-outform |
Specifies the output format. If a PKCS#8 format key is expected on output, then either a DER or PEM encoded version of a PKCS#8 key is expected. Otherwise the DER or PEM format of the traditional format private key is used. |
Simple or Cert Mode: In the PEM file (in this case, aaa_cert.pem), enter the pass phrase for the Oracle Access Manager Access Server if it is configured for Simple or Cert mode.
Passphrase for the certificate
Run the following command to convert the aaa_cert.pem file to DER format.
AccessServer_install_dir\access\oblix\tools\openssl>openssl x509 -in
aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER
Import the DER format files into a Java keystore using the ImportKey utility. For example:
Java_install_dir\doc>java -Dkeystore=jkscerts ImportKey aaa_key.der
aaa_cert.der
Review the results in the window, which should look something like the following example:
Using keystore-file : jkscerts
One certificate, no chain
Key and certificate stored
Alias:importkey Password:your_password
Proceed as follows:
Identity Asserter for Single Sign-On: Go to "Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g".
Authenticator or Oracle Web Services Manager: Perform steps in "Creating Resource Types in Oracle Access Manager 10g".
This section describes how to create resource types in Oracle Access Manager to identify the types of resources that you want the policy domain to protect. This task is required if you use the Oracle Access Manager Authenticator or if you have Oracle Web Services Manager policies protecting Web services.
You use the Oracle Access Manager Access System Console to define resource types as described here.
Note:
If you are using the Oracle Access Manager Identity Asserter for single sign-on, you can skip this task. In this case, only the default http resource type is used.
Defining the wl_authen resource type in Oracle Access Manager is required only when you are using:
Oracle Access Manager Authenticator
Identity Asserter with Oracle Web Services Manager
To define resource types in Oracle Access Manager 10g
Go to the Access System Console and log in.
Select the Access System Configuration tab, and then click Common Information Configuration, Resource Type Definitions, to display the List All Resource Types page.
On the List All Resource Types page, click Add, to display the Define a new Resource Type page.
Define the resource type with the following details:
Name: wl_authen
Display name: wl_authen
Resource matching: Case insensitive
Resource operation: LOGIN
Save the resource type you just defined.
Proceed as follows:
Authenticator: "Configuring the Authenticator for Oracle Access Manager 10g"
Oracle Web Services Manager: "Configuring Identity Assertion for Oracle Web Services Manager and OAM 10g"
This section discusses configuring logout for applications protected by a 10g WebGate with Oracle Access Manager 10g. In Oracle Access Manager 10g, global logout (also known as single log out (SLO) can be handled in various ways. This section describes the recommended method.
Note:
Oracle Access Manager SSO user session tracking is performed using DOMAIN cookies, specifically the ObSSOCookie. WebGates look for the ObSSOCookie. Global or SLO for Oracle Access Manager simply means killing the ObSSOCookie. Without the ObSSOCookie, WebGates enforce a re-authentication workflow.
For more information on killing the ObSSOCookie, see:
There are two steps in the Oracle-recommended approach to configuring logout:
WebGate configuration consist of:
logout.html: A logout page must be available on the Web server in the WebGate installation directory: WebGate_install_dir/oamsso/logout.html.
If the file is located elsewhere on the Web server, ensure that the logout link is correctly specified to load logout.html. See the logout.html in Example 17-1, which you can customize further depending on your needs.
logOutUrls (optional): If this parameter has already been configured for the WebGate, the value "/oamsso/logout.html" must be added to the existing list.
Web Server Configuration: Check the Oracle HTTP Server Web server configuration file, httpd.conf, on which the 10g WebGate is configured and delete the following lines if they are present
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
Use Example 17-1 when you begin constructing a logout.html for logout configuration for an application protected by 10g WebGate in an OAM 10g deployment.
Example 17-1 logout.html Script
<html>
<head>
<script language="javascript" type="text/javascript">
function handleLogout() {
//get protocol used at the server (http/https)
var webServerProtocol = window.location.protocol;
//get server host:port
var webServerHostPort = window.location.host;
//get query string present in this URL
var origQueryString = window.location.search.substring(1);
//vars to parse the querystring
var params = new Array();
var par = new Array();
var val;
if (origQueryString != null && origQueryString != "") {
params = origQueryString.split("&");
//search for end_url and redirect the user to this
for (var i=0; i<params.length; i++) {
par = params[i].split("=");
if ("end_url" == par[0]) {
endUrlVal = par[1];
//check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
if (endUrlVal.substring(0,1) == "/" || endUrlVal.substring(0,1) == "%") {
if (endUrlVal.substring(0,1) == "%")
endUrlVal = "/" + endUrlVal.substring(3);
//modify the end_url value now
endUrlVal = webServerProtocol + "//" + webServerHostPort + endUrlVal;
}
//redirect the user to this URL
window.location.href = endUrlVal;
}
}
}
}
</script>
</head>
<body onLoad="handleLogout();">
<h3>You have been logged out<h3>
</body>
</html>
Application configuration for logout depends on whether it is an ADF application integrated with OPSS or if it is not integrated with OPSS.
Note:
The logout configuration assumes that the applications are present in a single DNS domain. If you would like SLO (single log out) across applications deployed in different DNS domains, you must customize the logout script to ensure processing for each WebGate. If you have a multi DNS domain deployment, see the Oracle Access Manager Access Administration Guide.
One of the following must be done to configure the application for logout:
A non-ADF application must be coded to invoke the logout link: "/oamsso/logout.html?end_url=<target uri>".
An ADF application that has been integrated with OPSS requires configuring OPSS for the OAM SSO provider and the application must send the 'end_url' parameter.
Non-ADF Application
A non-ADF application must be coded to invoke the link for logout: "/oamsso/logout.html?end_url=<target uri>".
The application can pass a parameter (named end_url) indicating the location where the user should eventually be redirected to after logout. The value that is part of end_url could either be a URL or a URI. For example, the logout link for the application might be specified as
/oamsso/logout.html?end_url=<someUri>
or
/oamsso/logout.html?end_url=<someUrl>
If the end_url querystring is a URI, then the logout.html must construct the URL by determining the host:port of the server where logout.html is hosted.
ADF-Coded Applications
If the Application is an ADF application that has been integrated with OPSS, then you can use the following procedure to configure logout.
To configure centralized logout for ADF-coded applications
Check with the OAM Administrator to confirm the location of the logout.html script configured with the Agent, which you need in following steps.
Configure OPSS for OAM as the SSO provider to update jps-config.xml for the WebLogic administration domain, as follows:
Run wlst.sh (Linux) or wlst.cmd (Windows) from the following directory path:
WLST_install_dir/middleware/oracle_common/common/bin
At the WLS prompt, enter the OAM administrator ID and password and the WebGate host and port:
wls:/> /connect("admin_ID", "admin_pw", "hostname:port"
The last parameter is optional if the server is running on localhost at the default port (7001).
Enter the login URI for ADF authentication and the logout URI (location of the logout.html script configured with the agent); the host and port are not needed.
wls:/>addOAMSSOProvider(loginuri="/$<loginuri>",
logouturi="<logouturival>," autologinuri=None")
Here, logouturival is the URI of the logout script /oamsso/logout.html. The logouturl could either begin with "logout" (exceptions are logout.gif and logout.jpg) or could be any other value configured by the OAM Administrator.
Required: The ADF application must pass the end_url parameter indicating where to redirect the user after logout. For ADF applications, logout is initiated when the application causes the following URI to be invoked:
/<app context root>/adfAuthentication?logout=true&end_url=<any uri>
Oracle does not recommend this method unless your application already has a custom logout page that you do not wish to change for any reason.
WebGate logs out of any request for a URL that has the string "logout." in it. Exception: Image files such as logout.gif and logout.jpg. This is the simplest way to integrate an application with OAM SLO. If your logout page begins with "logout." (for example, logout.jsp) then you do not need to do any thing.
Note:
If your logout page begins with "logout." (for example, logout.jsp) then you do not need to do any thing.
If your logout page does not begin with "logout.", then you must add your logout URL to the WebGate LogOutUrls parameter. For instance: LogOutUrls = "/myapplication /customscript.jsp".
This section enumerates the common and provider-specific parameters relevant to the Oracle Access Manager Authentication Provider. These are specified in the Oracle WebLogic Administration Console. For more information, see:
Table 17-2, "Oracle Access Manager Authentication Provider Common Parameters"
Table 17-4, "Provider-Specific Parameters: Oracle Access Manager Authenticator"
Table 17-2 Oracle Access Manager Authentication Provider Common Parameters
| Parameter Name | Parameter Description |
|---|---|
|
Name |
The name of the provider. Read-only. |
|
Description |
The description of the provider. Read-only. |
|
Version |
The version of the provider. Read-only. |
|
Control Flag |
The provider JAAS control flag. Set one of the following: REQUIRED, REQUISITE, OPTIONAL, or SUFFICIENT. When configuring multiple Authentication Providers, use this flag to control how they are use in the login sequence. See JAAS Control Flag. |
|
Active Types |
This parameter is relevant to only Oracle Access Manager Identity Asserter. This parameter determines the token types that the Identity Asserter Provider processes. Set as follows for OAM 10g and 10g WebGate:
|
|
Base64 Decoding Required |
False is Read-only (the default). |
The WebLogic Server Administration Console sets the JAAS Control Flag to OPTIONAL when you create a new security provider. The default value for out-of-the-box security providers is REQUIRED. For more details about the control flag, see the online help.
Table 17-3 lists the provider-specific parameters for Oracle Access Manager the Authenticator or the Identity Asserter for Oracle Web Services Manager.
Note:
With OAM 11g, the Access Server is known as the OAM Server.
Table 17-3 Provider-Specific Parameters
| Parameter Name | Parameter Description |
|---|---|
|
Transport Security |
The mode of communication between AccessGate and Access Server. |
|
Minimum Access Server Connections In Pool |
The minimum number of connections allowed. Default is 5. |
|
Access Gate Password |
The password of the AccessGate used by the provider. |
|
Key Store Pass Phrase |
The password to access the key store. |
|
Access Gate Name |
The name of the AccessGate used by the provider. Required. |
|
Primary Access Server |
The name of the primary access server. It must conform to the format host:port. Required. See "Installing and Setting Up Authentication Providers for OAM 10g". |
|
Maximum Access Server Connections In Pool |
The maximum number of connections allowed. Default is 10. Set to 1. |
|
Simple Mode PassPhrase |
The password shared by AccessGate and Access Server for Simple or Cert communication modes. |
|
Trust Store |
The absolute path of JKS trust store used for SSL communication between the provider and the Oracle Access Manager Access Server. |
|
SSOHeader Name |
OAM_REMOTE_USER |
|
Secondary Access Server |
The name of the secondary access server. It must conform to the format host:port. See "Installing and Setting Up Authentication Providers for OAM 10g". |
|
Key Store |
The absolute path of JKS key store used for SSL communication between the provider and the Oracle Access Manager Access Server. |
Table 17-4 lists provider-specific parameters for the Oracle Access Manager Authenticator.
Table 17-4 Provider-Specific Parameters: Oracle Access Manager Authenticator
| Parameter Name | Parameter Description |
|---|---|
|
Transport Security |
The mode of communication between AccessGate and Access Server. |
|
Maximum Access Server Connections In Pool |
The maximum number of connections allowed. Default is 10. Set to 1. |
|
Simple Mode Pass Phrase |
The password shared by AccessGate and Access Server for simple or cert communication modes. |
|
Minimum Access Server Connections In Pool |
The minimum number of connections allowed. Default is 5. |
|
Trust Store |
The absolute path of JKS trust store used for SSL communication between the provider and the Oracle Access Manager Access Server. |
|
Use Retrieved username As Principal |
Specifies whether to use the user name retrieved from Oracle Access Manager as the Principal in the Subject. |
|
Access Gate Password |
The password of the AccessGate used by the provider. |
|
Key Store Pass Phrase |
The password to access the key store. |
|
Access Gate Name |
The name of the AccessGate used by the provider. Required. |
|
Secondary Access Server |
The name of the secondary access server. It must conform to the format host:port. See: |
|
Key Store |
The absolute path of JKS key store used for SSL communication between the provider and the Oracle Access Manager Access Server. |
|
Primary Access Server |
The name of the primary access server. It must conform to the format host:port. Required. See: |
This topic introduces OAMCfgTool, which can be used only if you are deploying the Oracle Access Manager 10g Identity Asserter for single sign-on.
OAMCfgTool launches a series of scripts to request information and set up the required profiles and policies in Oracle Access Manager 10g. OAMCfgTool runs in the following modes:
CREATE mode
java -jar oamcfgtool.jar mode=CREATE param=value
VALIDATE mode
java -jar oamcfgtool.jar mode=VALIDATE param=value
DELETE mode
java -jar oamcfgtool.jar mode=DELETE param=value
Unless you specify an LDIF output file, configuration changes are written directly in the LDAP directory server that is configured with Oracle Access Manager. In addition, without an LDIF file, OAM Access Server's cache is updated with the configuration changes.
Note:
When configuration changes are written to an LDIF file, it can be loaded into the directory server for Oracle Access Manager at a later time.
You can also specify a log level and an output file for logging details. If errors occur when running OAMCfgTool, these are reported on the command line.
Passwords
OAMCfgTool expects four passwords: LDAP user, Application agent, OAM mode, and Test user.
Without the -noprompt parameter, OAMCfgTool attempts to fetch passwords first from the command line. If no password is found, then OAMCfgTool pauses and prompts for a password to be entered on the command line.
However if you specify the -noprompt parameter, OAMCfgTool checks for passwords passed from the command line:
If the password was not passed from command line, then OAMCfgTool checks for passwords passed from System.in.
If no password is passed from System.in, OAMCfgTool stops execution with an exception indicating that the required password was not provided.
Passwords can be passed from a shell using an echo command and a semi-colon as a separator. For instance:
To specify all four passwords:
$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) | java -jar oamcfgtool.jar <args> -noprompt
To specify only ldapUsrPwd and appAgentPwd:
$ (echo ldapUserPwd; echo appAgentPwd) | java -jar oamcfgtool.jar <args> -noprompt
To specify only appAgentPwd:
$ (echo; echo appAgentPwd) | java -jar oamcfgtool.jar <args> -noprompt
For more information, see "OAMCfgTool Parameters and Values".
This topic describes the processing that occurs when you use OAMCfgTool with various parameters and values for your environment.
This topic focuses on using OAMCfgTool for OAM 10g. If you are using OAM 11g, skip this topic and instead refer to the chapter Chapter 16, "Configuring Single Sign-On with Oracle Access Manager 11g".
See Also:
Process overview: OAMCfgTool creates the authentication scheme, policy domain, and WebGate profile
The app_domain parameter creates a policy domain in the Policy Manager to enable authentication for the application.
The web_domain parameter creates a host identifier that connects the WebGate host sending requests to your application and links the policy to the existing WebGate.
Note:
See the web_domain parameter in Table 17-5.
The protected_uris parameter defines application-specific URL's to protect HTTP resources using the host identifier.
The public_uris parameter creates a policy to protect certain URIs with the Anonymous Authentication scheme for http resources (GET and POST operations) in the app_domain name.
Note:
See the uris_file parameter in Table 17-5 for details about specifying protected and public URIs in a file.
The LDAP parameters specify the directory server used by Oracle Access Manager to identity the searchbase from which all LDAP queries are performed. For more information, see Table 17-5
The log file and level parameters specify an output file and logging level for OAMCfgTool.
The output_ldif_file parameter defines the name of the LDIF file that is created to be loaded later in the directory server, if specified. Otherwise, configuration changes are written to the directory server
Find the following topics here:
Table 17-5 provides both required and optional OAMCfgTool parameters and values for CREATE mode. You can specify multiple parameters at one time.
Table 17-5 OAMCfgTool CREATE Mode Parameters and Values
| Parameters | CREATE Mode Values |
|---|---|
|
Required Parameters |
Required Parameter Values |
|
app_domain |
Name of the Oracle Access Manager policy domain to protect the application. Within the Policy Manager this is known as the policy domain name. |
|
protected_uris |
URIs for the protected application in a comma separated list (with or without spaces): /myapp/login, for example. See Also: The uris_file parameter in this table. |
|
uris_file |
The full path to a file containing any number of protected or public URIs and eliminates the need to use the protected_uris or public_uris parameters. Ensure that the file uses the following syntax and format: --At least one protected URI is required. --Only one product family is allowed per file. --Comments begin with '#' --Keyword: public_uris. List public URIs on separate lines after this key word. --Key word: protected_uris. List URIs to be protected on separate lines after this key word. For example: ######################## #Finance ######################## . ######################## protected_uris ######################## /finance/protected/test1 /finance/protected/test2 ######################## public_uris ######################## /finance/public /finance/protected/test1/public |
|
app_agent_password |
Password to be provisioned for the WebGate. In the AccessGate Profile within the 10g Access System Console, this parameter is known as the AccessGate Password. Your entry appears in clear text on the command line but is not captured in a log file. Note: This parameter is not required if you will not create a WebGate profile. See Also: |
|
ldap_host |
DNS name of the computer hosting the LDAP directory server for Oracle Access Manager. This is the directory server containing the OAM policy data. Note: SSL-enabled communication with the directory server is not supported. |
|
ldap_port |
Port of the LDAP directory server. |
|
ldap_userdn |
The valid DN of the LDAP administrative user, entered as a quoted string. In Oracle Access Manager this is known as the Root DN or Bind DN. |
|
ldap_userpassword |
Password of LDAP administrative user. Passwords appear in clear text but are not captured in a log file. See Also: -noprompt later in this table. See Also: |
|
oam_aaa_host |
DNS name of the computer hosting an accessible Access Server. After making appropriate changes to the Directory Server, a Cache flush request would be sent to this Access Server so that Access Servers refresh their appropriate caches. If the 'primary_oam_servers' parameter is not specified, then the WebGate profile being created would be configured to use the Access Server, specified as part of oam_aaa_host, as the Primary Access Server. Number of connections would default to 1. See Also: primary_oam_servers and secondary_oam_servers, later in this table. |
|
oam_aaa_port |
Listening port on the accessible Access Server |
|
Optional Parameters |
Optional Parameter Values |
|
help |
Provides a list of parameters and descriptions. |
|
version |
Lists the version of the OAMCfgTool. |
|
web_domain |
Primarily used to specify the host identifier. Note: OAMCfgTool either creates a host identifier and Webgate profile together or does not create either of them, as described in the following two scenarios: Creation of a Fresh Web Tier: If the host identifier specified by the parameter "web_domain" (or "app_domain" if "web_domain" is not specified) does not exist in OAM, then the following would be created in OAM:
See Also: The hostname_variations parameter in this table for configuring virtual hosts. Using an existing Web Tier (Join a web domain): If the host identifier specified as part of "web_domain" (or "app_domain", if "web_domain" is not specified) exists in OAM, then:
Note: The host identifier created in a fresh Web Tier is used in the policy domain being used. If virtual Web hosting is supported, supply a reserved name in the Preferred HTTP Host field instead of a host name variation. See Also: The hostname_variations parameter in this table and the Oracle Access Manager Access Administration Guide. |
|
cookie_domain |
Name of the domain to use for the ObSSOCookie. Within the AccessGate Profile in the Access System Console, this is known as the Primary HTTP Cookie Domain. Use this parameter when you create a new WebGate profile in a fresh Web Tier. |
|
public_uris |
URIs that must be unprotected using the Anonymous authentication scheme. You can identify public URIs by providing a comma separated list: "uri1,uri2,uri3", for example. See Also: The uris_file parameter in this table. |
|
ldap_base |
Base from which all LDAP searches are performed. |
|
oam_aaa_mode |
Transport security mode of the accessible Access Server: OPEN, SIMPLE, or CERT. Default presumes OPEN. |
|
oam_aaa_passphrase |
Passphrase required for SIMPLE mode transport security mode only. The passphrase appears in clear text but is not captured in a log file. See Also: The discussion "Passwords". |
|
log_file |
Name of the OAMCfgTool log file. Output to the screen is the default. |
|
log_level |
Level for OAMCfgTool logging: ALL, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, OFF. Default = WARNING |
|
output_ldif_file |
Name of the LDIF file in which to store details from OAMCfgTool operations to load into the LDAP directory server later. If none is specified, changes are written immediately to the LDAP directory server and caches in Oracle Access Manager are flushed to make new information available. |
|
noprompt |
Disables password prompts from OAMCfgTool and enables password checks as follows:
|
|
authenticating_wg_url |
URI containing the host and port of the authenticating WebGate (when you have both an authenticating and a resource WebGate). For example:
This parameter configures the "Challenge Redirect Parameter" of both the following authentication schemes:
Note: The 'Challenge Redirect' parameter is added when the authentication scheme is created. The 'Challenge Redirect' parameter of an existing authentication scheme is not updated. |
|
configOIMPwdPolicy |
Creates the Oracle Identity Manager (OIM) password policy to automate integration with Oracle Access Manager. Also, the corresponding authentication scheme used by the policy is enabled to check password policies. |
|
OimOhsHostPort |
Required when integrating Oracle Identity Manager (OIM) with Oracle Access Manager and an authentication WebGate and resource WebGate. See Also: "OIM Integration-Related Parameters and Values". Not required without an authenticating WebGate. In this case, Oracle Identity Manager (OIM) password policy (OraOIMDefPasswdPolicy) automates integration with Oracle Access Manager and the corresponding authentication scheme used by the policy is enabled to check password policies. Default values are used for the password policy-related parameters with the value in OimOhsHostPort prepended to these. For example: -OimLostPwdRedirectUrl (Lost Password Redirect URL): <OimOHSHostPort>/admin/faces/pages/forgotpwd.jspx -OimPwdRedirectUrl (Password Change Redirect URL): <OimOHSHostPort>/admin/faces/pages/pwdmgmt.jspx?backUrl=%RESOURCE% -OimLockoutRedirectUrl (Account Lockout Redirect URL): <OimOHSHostPort>/ApplicationLockoutURI OimOhsHostPort parameter is applicable only if the -configOimPwdPolicy flag is present. |
|
logouturi |
Facilitates configuration of LogoutRedirectUrl on the Resource WebGate by pointing to the URL location on the Authenticating WebGate where the perl script for logout is configured. The value of logouturi parameter must be a URI. The WebGate LogoutRedirectUrl parameter is configured using the authenticating_wg_url and logouturi parameters: http://<awghost>:<awgport>/cgi-bin/logout.pl LogoutRedirectUrl http://myhost.us.myco.com:7777/cgi-bin/logout.pl. Note: Do not configure the LogoutRedirectUrl parameter on the authenticating WebGate itself. Instead, leave the LogoutRedirectUrl blank on the authenticating WebGate. To configure the logout URI when you create an application domain and provision a fresh WebGate: $ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) java -jar oamcfgtool.jar app_domain=app_domain protected_uris="/protUri" ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager" oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_ base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_ url=http://myhost.us.myco.com:7777 -logouturi=/cgi-bin/logout.pl -noprompt Note: To use an existing WebGate, use the webgate_id parameter as described next. |
|
webgate_id |
Specifies the name of the existing WebGate for which "LogoutRedirectUrl" is not yet configured. Notes: The WebGate profile is created only if the corresponding host identifier does not already exist in Oracle Access Manager. Further:
Following is a sample command using webgate_id.: $ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) java -jar oamcfgtool.jar app_domain=myapp webgate_id=MyWebgate protected_uris="/protUri" ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager" oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_ base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_ url=http://myhost.us.myco.com:7777 -logouturi=/cgi-bin/logout.pl -noprompt |
|
hostname_variations |
Enables you to add values to the Hostname Variations section of the Host Identifier in Oracle Access Manager. To configure virtual hosts for Apache-based Web servers (including OHS), include this parameter as follows: java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ... hostname_variations=vhost1,vhost2 Note:
To configure virtual hosts for non-Apache-based Web servers, include the parameter, preferred_http_host as described next. |
|
preferred_http_host |
Makes configurable the Preferred Http Host field of the WebGate profile. To configure virtual hosts for non-Apache-based Web servers, include this parameter, with a value of HOST_HTTP_HEADER, as follows: java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ... hostname_variations=vhost1,vhost2 preferred_http_host=HOST_HTTP_HEADER You can simply add multiple hostname variations to a host identifier using the java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ... hostname_variations=hostname1,hostname2 preferred_http_host=SOME_ HOSTNAME_VARIATION_VALUE The virtual environment notes apply. Additionally, if the WebGate profile is being created, then you can set the preferred http host field of the profile to any value from the hostname variations Generally, you do not need additional hostname variations when creating a host identifier in a non-virtual host environment. OAMCfgTool adds a default value to the preferred http host field of the WebGate profile and to the hostname variation section of the host identifier being created. |
|
default_authn_scheme |
Configures the default authentication scheme for a policy domain. You must pass the authentication scheme name as displayed in the Access System Console. OAMCfgTool always provisions the following authentication schemes:
The first time you run the tool in a new deployment, the schemes in the previous list are created. The authentication scheme specified as part of the "default_authn_scheme" parameter is used to configure the Default Authentication Rule section of the Policy Domain being configured. With the OAM URIs file, you can configure the authentication scheme for a protected policy (policies that are specified after the key word "protected_uris" for the Policy Domain. You must pass the Authentication Scheme name in the URIs file in the following format (the policy name and authentication scheme name must be separated by a tab character): <Policy Name> 'tab' <Authentication Scheme Name>. Following is an example of entries in a URIs file (for more information, see the uris_file parameter earlier in this table): #-----------------------------------------------------
protected_uris
protected policy1 Basic Over LDAP
/protected1 public1/mystuff.html
protected policy2 OraDefaultFormAuthNScheme
/protected2/public2/prot2 /.../{*.js,*.png,*.gif}
protected policy3 Client Certificate
/protected2/public2/prot2/.../{*.js,*.png,*.gif}
#------------------------------------------------------
The previous entries in a URIs file produce the following named policies:
|
|
max_oam_connections |
Supports high availability and multiple Access Servers by specifying the maximum number of connections ('Maximum Connections') for the WebGate profile being created. |
|
primary_oam_servers |
Supports high availability and multiple Access Servers by configuring the WebGate profile with more than one primary Access Server. The format of this parameter is:
Notes:
|
|
secondary_oam_servers |
Supports high availability and multiple Access Servers by configuring the WebGate profile with more than one secondary Access Server. The format of this parameter is:
Notes:
|
Table 17-6 identifies OIM integration-related parameters and values for OAMCfgTool.
See Also:
The section on integrating Oracle Access Manager 10g with Oracle Identity Manager 11g in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management
Table 17-6 Additional OIM Integration-Related Parameters and Values
| Parameter | Description |
|---|---|
|
configOIMPwdPolicy |
Creates the Oracle Identity Manager (OIM) password policy (OraOIMDefPasswdPolicy) to automate integration with Oracle Access Manager. Additionally, the corresponding authentication scheme used by the policy is enabled to check password policies. For example, if the policy is used with the default authentication scheme (OraDefaultFormAuthnScheme), then the scheme's "Validate_Password" plug-in is updated to include 'obReadPasswdMode="LDAP",obWritePasswdMode="LDAP"'. Note: Use default values for password-related parameters in Identity System Console, prepended with the value specified with OimOhsHostPort. When configOIMPwdPolicy is used, ensure that you do not have the default OIM password policy created using the tool previously and do not pass any of the following parameters: When configOIMPwdPolicy is used, ensure that you do not have the default OIM password policy created using the tool previously and do not pass any of the following parameters: |
|
OimOhsHostPort |
Required when integrating Oracle Identity Manager (OIM) with Oracle Access Manager and an authentication WebGate and resource WebGate. Not required without an authenticating WebGate. In this case, Oracle Identity Manager (OIM) password policy (OraOIMDefPasswdPolicy) automates integration with Oracle Access Manager and the corresponding authentication scheme used by the policy is enabled to check password policies. Default values are used for the password policy-related parameters with the value in OimOhsHostPort prepended to these. For example: -OimLostPwdRedirectUrl (Lost Password Redirect URL): <OimOHSHostPort>/admin/faces/pages/forgotpwd.jspx -OimPwdRedirectUrl (Password Change Redirect URL): <OimOHSHostPort>/admin/faces/pages/pwdmgmt.jspx?backUrl=%RESOURCE% -OimLockoutRedirectUrl (Account Lockout Redirect URL): <OimOHSHostPort>/ApplicationLockoutURI OimOhsHostPort parameter is applicable only if the -configOimPwdPolicy flag is present. |
|
OimPwdRedirectUrl |
Required for configOIMPwdPolicy. Configures the Password Change Redirect URL parameter in Oracle Access Manager. |
|
OimLockoutRedirectUrl |
Required for configOIMPwdPolicy. Configures the Custom Account Lockout Redirect URL parameter in Oracle Access Manager. |
|
OimLostPwdRedirectUrl |
Required for configOIMPwdPolicy. Configures the Lost Password Redirect URL parameter in Oracle Access Manager. |
Note:
This is a one time setup requirement. If the OraOIMDefPasswdPolicy policy already exists, it is not created anew. You must restart the Identity and Access Servers after this operation. See Example 17-2.
Example 17-2 OIM Integration-Related Parameter Usage
$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) java -jar oamcfgtool.jar app_domain=app_domain protected_uris="/protUri" ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager" oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_ base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_ url=http://myhost.us.myco.com:7777 -configOIMPwdPolicy OimPwdRedirectUrl="http://oimredirectutl.com OimLockoutRedirectUrl="http://oimlockouturl.com" OimLostPwdRedirectUrl="http://oimLostpwdurl.com" -noprompt
Master or Delegated Access Administrators can check Oracle Access Manager directly to validate policy domain and WebGate profile setup.
Note:
You cannot use OAMCfgTool mode to validate AccessGate profile creation.
Using OAMCfgTool in VALIDATE mode, you can ensure that the policy domain for single sign-on configuration is correct. In this case, a set of requests are sent automatically to protected resources.
Table 17-7 provides both required and optional OAMCfgTool parameters and values for VALIDATE mode.
Table 17-7 OAMCfgTool VALIDATE Mode Parameters and Values
| VALIDATE Mode Parameters | VALIDATE Mode Values for Required Parameters |
|---|---|
|
Required Parameters |
Values |
|
app_domain |
Name of the Oracle Access Manager policy domain that was created to protect the Application. |
|
ldap_host |
DNS name of the computer hosting the LDAP directory server for Oracle Access Manager. |
|
ldap_port |
Port of the LDAP directory server. |
|
ldap_userdn |
The valid DN of the LDAP administrative user, entered as a quoted string. In Oracle Access Manager this is known as the Root DN or Bind DN. |
|
ldap_userpassword |
Password of the LDAP administrative user. Passwords appear in clear text but are not captured in a log file. See Also: noprompt in this table. |
|
ldap_base |
Base from which all LDAP searches are done. In Oracle Access Manager this is known as the search base or configuration base. For example: dc=company,c=us. |
|
oam_aaa_host |
DNS name of the computer hosting the Access Server. |
|
oam_aaa_port |
Listening port on the Access Server host. |
|
test_username |
User name to be used for policy validation. |
|
test_userpassword |
User password to be used for policy validation. Passwords appear in clear text but are not captured in a log file. See Also: noprompt in this table. |
|
noprompt |
Enables OAMCfgTool to read passwords from System.in to ensure safe passage. Passwords can be passed from a shell using an echo command and a semi-colon as a separator. ConfigTool expects four passwords: Ldap user, App agent, OAM mode and Test user: See Also: noprompt in Table 17-5. |
|
Optional Parameters |
Values |
|
web_domain |
Host identifier |
|
ldap_base |
Base from which all LDAP searches are done. In Oracle Access Manager this is known as the search base or configuration base. For example: dc=company,c=us. |
|
oam_aaa_mode |
Transport security mode of the accessible Access Server: OPEN, SIMPLE, or CERT. Default presumes OPEN. |
|
oam_aaa_passphrase |
Passphrase required for SIMPLE mode transport security mode only. Your entry appears in clear text. However, it is not captured in a log file. |
|
log_file |
Name of the OAMCfgTool log file. Output to the screen is the default. |
|
log_level |
Level for OAMCfgTool logging: ALL, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, OFF (the default). |
|
noprompt |
Enables OAMCfgTool to read passwords from System.in to ensure safe passage. Passwords can be passed from a shell using an echo command and a semi-colon as a separator. OAMCfgTool expects four passwords: LDAP user, Application agent, OAM mode and Test user. See Also Table 17-5. |
Using OAMCfgTool in DELETE mode, you can remove the provisioned policies, the web domain, WebGate registration, and authentication scheme.
Table 17-8 provides both required and optional OAMCfgTool parameters and values for DELETE mode.
Table 17-8 OAMCfgTool DELETE Mode Parameters
| DELETE Mode Parameters | DELETE Mode Values for Required Parameters |
|---|---|
|
ldap_host |
DNS name of the computer hosting the LDAP directory server for Oracle Access Manager. |
|
ldap_port |
Port of the LDAP directory server. |
|
ldap_userdn |
The valid DN of the LDAP administrative user, entered as a quoted string. In Oracle Access Manager this is known as the Root DN or Bind DN. |
|
ldap_userpassword |
Password of the LDAP administrative user. Passwords appear in clear text but are not captured in a log file. See Also: -noprompt in Table 17-5. |
|
oam_aaa_host |
DNS name of the computer hosting the Access Server. |
|
oam_aaa_port |
Listening port on the Access Server host. |
|
Optional Parameters |
Values |
|
app_domain |
To delete the entire application domain, specify only app_domain with no URI-related parameters. |
|
web_domain |
web_domain=existing_host_Identifier To delete the host identifier identified by this parameter and the WebGate registration. See Also: Table 17-5. |
|
protected_uris |
URIs for the protected application in a comma separated list (with or without spaces): /myapp/login, for example. Deletes one or more protected URIs from an application domain. See Also: The uris_file parameter in this table. |
|
public_uris |
Deletes one or more public URIs from an application domain. See Also: The uris_file parameter in this table. |
|
uris_file |
The full path to a file containing any number of protected or public URIs and eliminates the need to use the protected_uris or public_uris parameters. Ensure that the file uses the following syntax and format. See Also: Table 17-5. |
|
authn_scheme |
The name of the authentication scheme to delete: OraDefAuthSchemes, OraDefaultAWGFormAuthNScheme, OraDefaultI18NFormAuthNScheme. To delete all three, specify OraDefAuthSchemes: You can include the following options: -noconfirm With this parameter there is no prompt for confirmation before deleting. |
|
noprompt |
Enables OAMCfgTool to read passwords from System.in to ensure safe passage. Passwords can be passed from a shell using an echo command and a semi-colon as a separator. OAMCfgTool expects four passwords: LDAP user, Application agent, OAM mode and Test user. See Also Table 17-5. |
This topic describes and illustrates the results of running OAMCfgTool when viewed in Oracle Access Manager:
My Policy Domains
Policy Domain, General Tab
Figure 17-1 illustrates the General tab in a sample policy domain created with OAMCfgTool. The Description is provided automatically.
Note:
For descriptions only, the Java API retrieves the current user from the operative platform and the name of the computer host: user@hostname.
Figure 17-1 Sample OAMCfgTool Policy Domain General Tab
Policy Domain, Resources Tab
Figure 17-2 illustrates the Resources tab in a sample policy domain created with OAMCfgTool. The http resource type is the default. The host identifier and URL prefixes are derived from OAMCfgTool parameters and the values you enter. The Description is provided automatically.
Figure 17-2 Sample OAMCfgTool Policy Domain Resources Tab
Policy Domain, Authorization Rules Tab
Figure 17-3 illustrates the Authorization Rules tab in a sample policy domain created with OAMCfgTool. Details found on sub tabs follow the figure. Authorization rules are automatically configured for the policy domain when you use OAMCfgTool.
Figure 17-3 Sample OAMCfgTool Policy Domain Authorization Rules Tab
Policy Domain, Default Rules Tab
Figure 17-4 illustrates the Default Rules tab in a sample policy domain created with OAMCfgTool. All values are configured automatically for the policy domain; details on sub tabs follow the figure.
Figure 17-4 Sample OAMCfgTool Policy Domain Default Rules Tab
Policy Domain, Policies Tab
Figure 17-5 illustrates the Policies tab, General sub tab, in a sample policy domain created using parameters and values that you specify with OAMCfgTool. The host identifiers are based on your app_domain value. Details on other sub tabs follow the figure.
Figure 17-5 Sample OAMCfgTool Policy Domain Policies Tab
Policy Domain, Delegated Access Admins Tab
Figure 17-6 illustrates the Delegated Access Admins tab in a sample policy domain created using OAMCfgTool. No parameters are specified with the tool to set up delegated rights for Master Web resource Admins.
Figure 17-6 OAMCfgTool Policy Domain Delegated Access Admins Tab
See Also:
"Protecting Resources with Policy Domains" in the Oracle Access Manager Access Administration Guide.
Host Identifiers
You can find the Host Identifiers created with OAMCfgTool in the Access System Console, under the Access System Configuration tab.
Figure 17-7 illustrates a sample host identifiers created using OAMCfgTool. As described here, required parameters are derived from the value entered with OAMCfgTool app_domain parameter. A Description is provided by OAMCfgTool.
Figure 17-7 Sample OAMCfgTool Host Identifiers
AccessGate Profile
Figure 17-8 illustrates a sample AccessGate profile created using OAMCfgTool when the web_domain parameter is omitted. The profile is in the Access System Console. As described here, required profile parameters are derived from values entered with OAMCfgTool. Other profile parameters use default values. A Description is provided by OAMCfgTool.
Figure 17-8 Sample OAMCfgTool AccessGate Profile
Table 17-9 identifies known issues with this release. For more information about the tool, parameters, and values, see "Introduction to OAMCfgTool".
Table 17-9 OAMCfgTool Known Issues
| Bug Number | Description |
|---|---|
|
n/a |
The location where you obtain Oracle Access Manager Authentication Provider and OAMCfgTool JAR files when you do not have an Oracle Fusion Middleware application installed could change. If the location is different than the one stated in this chapter, see the Release Notes for the latest information. |
|
8362080 |
OAMCfgTool provides Create, Validate, and Delete modes. It does not provide an Overwrite option. |
|
8362039 |
OAMCfgTool does not provide explicit options to specify the Web Tier host and port. Instead, without web_domain specified the app_domain value specifies the WebGate name, host, and Preferred HTTP Host. For example:
|
|
n/a |
With OAMCfgTool, if web_domain parameter is included in the command line, you must provide a WebGate password. Otherwise, the command can fail. The app_agent_password parameter accepts as the password whatever follows the equal sign, =. For instance, if you enter app_agent_password= and then enter a space character and web_domain=value, the app_agent_password is presumed to be a space character followed by web_domain. |
|
n/a |
SSL-enabled communication with the directory server is not supported by OAMCfgTool. |
This section describes the unique steps needed to configure Oracle Access Manager Identity Assertion for Single Sign-On.
Prerequisites
Unless explicitly noted for the Authenticator or Oracle Web Services Manager, all tasks described in "Installing and Setting Up Authentication Providers for OAM 10g" should be performed, including:
Installing Components and Files for Authentication Providers and OAM 10g
Note:
If you are implementing:
OAM 11g: Provision WebGates and security policies using the remote registration tool as described in "Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g".
OAM 10g: Add WebGate profiles and policies with OAMCfgTool as described in the following Task 3.
To configure Oracle Access Manager Identity Asserter for single sign-on with your application, perform the tasks as described in the following task overview.
Task overview: Deploying and configuring the Oracle Access Manager Identity Asserter for single sign-on includes
Ensuring that all prerequisite tasks have been performed
Configuring the Authentication Scheme for the Identity Asserter
Setting Up the Login Form for the Identity Asserter and OAM 10g
Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates
The following topics explain the tasks you must perform to set up the application for single sign-on with the Oracle Access Manager Identity Asserter:
Note:
This task is the same for both OAM 11g and OAM 10g.
Confirming mod_weblogic for Oracle Access Manager Identity Asserter
Establishing Trust between Oracle WebLogic Server and Other Entities
This topic describes how to create the application authentication method for Oracle Access Manager Identity Assertion.
When you use the Oracle Access Manager Identity Asserter, all web.xml files in the application EAR file must specify CLIENT-CERT in the element auth-method for the appropriate realm.
The auth-method can use BASIC, FORM, or CLIENT-CERT values. While these look like similar values in Oracle Access Manager, the auth-method specified in web.xml files are used by Oracle WebLogic Server (not Oracle Access Manager).
Note:
You can specify CLIENT-CERT, FORM if you are also planning to access the applications directly over WebLogic and want the WebLogic authentication scheme to be invoked.
To specify authentication in web.xml for the Identity Asserter and OAM 10g
Locate the web.xml file in the application EAR file:
your_app/WEB-INF/web.xml
Locate the auth-method in login-config and enter CLIENT-CERT.
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
Save the file.
Redeploy and restart the application.
Repeat for each web.xml file in the application EAR file.
Proceed to "Confirming mod_weblogic for Oracle Access Manager Identity Asserter".
Oracle HTTP Server includes the mod_weblogic plug-in module (mod_wl_ohs.so in 11g) which is already enabled. You can perform the following procedure to confirm this or skip this procedure.
With Oracle HTTP Server 11g, the mod_weblogic configuration is present in mod_wl_ohs.conf by default, and the path of this file is included in httpd.conf. If the mod_weblogic configuration is not present then you must edit httpd.conf.
To configure mod_weblogic for the Identity Asserter and OAM 10g
Locate httpd.conf. For example:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
Confirm that the following statement is in the file with appropriate values for your deployment (add or uncomment this, if needed):
<IfModule mod_weblogic.c> WebLogicHost yourHost.yourDomain.com WebLogicPort yourWlsPortNumber </IfModule> <Location http://request-uri-pattern> SetHandler weblogic-handler </Location>
Save the file.
Proceed to "Establishing Trust between Oracle WebLogic Server and Other Entities".
The Oracle WebLogic Connection Filtering mechanism must be configured for creating access control lists and for accepting requests from only the hosts where Oracle HTTP Server and the front-end Web server are running.
Note:
This topic is the same whether you are using OSSO or Oracle Access Manager.
A network connection filter is a component that controls the access to network level resources. It can be used to protect resources of individual servers, server clusters, or an entire internal network. For example, a filter can deny non-SSL connections originating outside of a corporate network. A network connection filter functions like a firewall since it can be configured to filter protocols, IP addresses, or DNS node names. It is typically used to establish trust between Oracle WebLogic Server and foreign entities.
To configure a connection filter to allow requests from only mod_weblogic and the host where OHS 11g is running, perform the procedure here.
Note:
This chapter uses the generic name of the WebLogic Server plug-in for Apache: mod_weblogic. For Oracle HTTP Server 11g, the name of this plug-in is mod_wl_ohs; the actual binary name is mod_wl_ohs.so. Examples show exact syntax for implementation.
WebLogic Server provides a default connection filter: weblogic.security.net.ConnectionFilterImpl. This filter accepts all incoming connections and also provides static factory methods that allow the server to obtain the current connection filter. To configure this connection filter to deny access, simply enter the connection filters rules in the WebLogic Server Administration Console.
You can also use a custom connection filter by implementing the classes in the weblogic.security.net package. Like the default connection filter, custom connection filters are configured in the WebLogic Server Administration Console.
Connection Filter Rules: The format of filter rules differ depending on whether you are using a filter file to enter the filter rules or you enter the filter rules in the Administration Console. When entering the filter rules on the Administration Console, enter them in the following format:
targetAddress localAddress localPort action protocols
Table 17-10 provides a description of each parameter in a connection filter.
Table 17-10 Connection Filter Rules
| Parameter | Description |
|---|---|
|
target |
Specifies one or more systems to filter |
|
localAddress |
Defines the host address of the WebLogic Server instance. (If you specify an asterisk (*), the match returns all local IP addresses.) |
|
localPort |
Defines the port on which the WebLogic Server instance is listening. (If you specify an asterisk, the match returns all available ports on the server.) |
|
action |
Specifies the action to perform. This value must be allow or deny |
|
protocols |
Is the list of protocol names to match. The following protocols may be specified: http, https, t3, t3s, giop, giops, dcom, ftp, ldap. If no protocol is defined, all protocols match a rule. |
The Connection Logger Enabled attribute logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.
See Also:
"Configuring Security in a WebLogic Domain" in Oracle Fusion Middleware Securing Oracle WebLogic Server
To configure a connection filter to allow requests from the host of the 11g Oracle HTTP Server
Log in to the Oracle WebLogic Administration Console.
Click Domain under Domain Configurations.
Click the Security tab, click the Filter tab.
Click the Connection Logger Enabled attribute to enable the logging of accepted messages for use when debugging problems relating to server connections.
Specify the connection filter to be used in the domain:
Default Connection Filter: In the Connection Filter attribute field, specify weblogic.security.net.ConnectionFilterImpl.
Custom Connection Filter: In the Connection Filter attribute field, specify the class that implements the network connection filter, which should also be specified in the CLASSPATH for Oracle WebLogic Server.
Enter the appropriate syntax for the connection filter rules.
Click Save.
Restart the Oracle WebLogic Server.
Proceed to "Configuring the Authentication Scheme for the Identity Asserter".
This topic focuses on using OAMCfgTool for OAM 10g. If you are using OAM 11g, skip this topic and instead perform tasks in "Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g".
After setting up your application, you must protect it with Oracle Access Manager. To help automate this task, Oracle provides the command-line tool: OAMCfgTool in the Fusion Middleware application-provided oamcfgtool.jar file for OAM 10g.
While you can perform steps manually in the Access System Console and Policy Manager, you can optionally use OAMCfgTool to setup and validate a form-based authentication scheme, a policy domain for the application, and Oracle Access Manager access policies required for Identity Assertion for single sign-on. Additionally, you can create a new WebGate profile in a fresh Web Tier or modify a WebGate profile in an existing Web Tier.
See Also:
For more information, see "Creating an Authentication Scheme, Policy Domain, and a WebGate Profile".
This topic provides a procedure that you can use as a model when you run OAMCfgTool.
This example presumes a fresh Web Tier that requires a new WebGate profile. Therefore, the web_domain= parameter is omitted. A new profile is created and named with the app_domain value (appended with _AG).
The following procedure is only an example to illustrate how to use the tool. Values for your environment will be different.
Note:
If you have an Oracle Fusion Middleware application installed you already have the OAMCfgTool. In this case, skip Step 1.
To create a form authentication scheme, policy domain, and access polices with OAMCfgTool
No Oracle Fusion Middleware Application: Obtain the OAMCfgTool if you have no Oracle Fusion Middleware application.
Log in to Oracle Technology Network at:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Locate the OAMCfgTool ZIP file with Access Manager Core Components (10.1.4.3.0):
oamcfgtool<version>.zip
Extract and copy oamcfgtool.jar to the computer hosting WebGate.
Confirm that JDK 1.6 (or the latest version) is installed and configured.
Log in to the computer that is hosting the application to protect, change to the file system directory containing OAMCfgTool.
Note:
Fresh Web Tier: Omit web_domain parameter to create and associate a new a profile. Include the cookie_domain parameter.
Existing Web Tier: Include web_domain parameter with the value of an existing host identifier.
Create a WebGate Profile, Authentication Scheme, and Policy Domain: Run the following command using values for your environment as described in Table 17-5. For example:
(echo ldappwd | java -jar oamcfgtool.jar mode=CREATE app_domain=IASSO_App1 protected_uris=/myapp/login cookie_domain=<preferred_http_cookie_domain> ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin oam_aaa_host=abcd oam_aaa_port=7789 oam_aaa_mode=cert log_file=OAMCfg_date.log log_level=INFO output_ldif_file=<LDIF_filename> -noprompt
Review the information provided by the tool. For example, the parameters and values in Step 3 would provide the following information:
Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain : IASSO_App1
Host Identifier: IASSO_App1
Access Gate ID : IASSO_App1_AG
Output LDIF Created: Import the LDIF to write information to the directory server. Otherwise, skip this step.
Validate: Run OAMCfgTool to validate the policy domain that was created (see Table 17-7). For example:
(echo ldappwd | java -jar oamcfgtool.jar mode=VALIDATE app_domain=IASSO_App1 protected_uris=/myapp/login ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin oam_aaa_host=abcd oam_aaa_port=7789 log_file=OAMCfg_date.log log_level=INFO test_username=gcf test_userpassword=<test_userpassword> -noprompt
Fresh WebGate Profile/WebGate Not Installed: Specify the same values when you install the WebGate as you specified when creating the profile (plus additional values to properly finish the installation).
Fresh WebGate Profile with Installed WebGate: Using output from the OAMCfgTool Create command, run the Oracle Access Manager configureWebgate tool to set up the installed WebGate. For example:
Go to:
WebGate_install_dir\access\oblix\tools\configureWebGate
where WebGate_install_dir is the directory where WebGate is installed.
Run the following command to configure the WebGate using values specified with OAMCfgTool and other values needed to finish the profile. For example:
configureWebGate -i WebGate_install_dir -t WebGate WebGate_Name -P WebGate_password -m <open|simple|cert> -h Access_Server_Host_Name -p Access_Server_Port -a Access_Server_ID -r Access_Server_Pass_Phrase (must be the same as the WebGate_password) -Z Access_Server_Retry count
See Also:
"Configuring AccessGates and WebGates" in the Oracle Access Manager Access Administration Guide
Confirm Profile in the Access System Console: Perform the following steps to view or modify the WebGate profile.
Log in to the Access System Console as a Master or Delegated Access Administrator. For example:
http://hostname:port/access/oblix
hostname refers to computer that hosts the WebPass Web server; port refers to the HTTP port number of the WebPass Web server instance; /access/oblix connects to the Access System Console.
Click Access System Configuration, and then click AccessGate Configuration.
Click the All button to find all profiles (or select the search attribute and condition from the lists) and then click Go.
Click a WebGate's name to view its details.
Click Cancel to dismiss the page without changes, or click Modify to change values as described in the Oracle Access Manager Access Administration Guide.
Repeat Steps 3 through 8 for each application that you are protecting.
Proceed to "Configuring Providers in the WebLogic Domain".
This topic is divided as follows:
About Oracle WebLogic Server Authentication and Identity Assertion Providers
Configuring Oracle WebLogic Server for a Web Application Using ADF Security, OAM SSO, and OPSS SSO
Setting Up Providers for Oracle Access Manager Identity Assertion
This topic introduces only a few types of Authentication Providers for a WebLogic security realm, if you are new to them.
Each WebLogic security realm must have one at least one Authentication Provider configured. The WebLogic Security Framework is designed to support multiple Authentication Providers (and thus multiple LoginModules) for multipart authentication. As a result, you can use multiple Authentication Providers as well as multiple types of Authentication Providers in a security realm. The Control Flag attribute determines how the LoginModule for each Authentication Provider is used in the authentication process.
Oracle WebLogic Server offers several types of Authentication and Identity Assertion providers including, among others:
The default WebLogic Authentication Provider (Default Authenticator) allows you to manage users and groups in one place, the embedded WebLogic Server LDAP server. This Authenticator is used by the Oracle WebLogic Server to login administrative users.
Identity Assertion providers use token-based authentication; the Oracle Access Manager Identity Asserter is one example.
LDAP Authentication Providers store user and group information in an external LDAP server. They differ primarily in how they are configured by default to match typical directory schemas for their corresponding LDAP server.
Oracle WebLogic Server 10.3.1+ provides the OracleInternetDirectoryAuthenticator.
When you configure multiple Authentication Providers, use the JAAS Control Flag for each provider to control how the Authentication Providers are used in the login sequence. You can choose the following the JAAS Control Flag settings, among others:
REQUIRED—The Authentication Provider is always called, and the user must always pass its authentication test. Regardless of whether authentication succeeds or fails, authentication still continues down the list of providers.
SUFFICIENT—The user is not required to pass the authentication test of the Authentication Provider. If authentication succeeds, no subsequent Authentication Providers are executed. If authentication fails, authentication continues down the list of providers.
OPTIONAL—The user is allowed to pass or fail the authentication test of this Authentication Provider. However, if all Authentication Providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.
When additional Authentication Providers are added to an existing security realm, the Control Flag is set to OPTIONAL by default. You might need to change the setting of the Control Flag and the order of providers so that each Authentication Provider works properly in the authentication sequence.
See Also:
"Configuring Authentication Providers" in Oracle Fusion Middleware Securing Oracle WebLogic Server for a complete list of Authentication Providers and details about configuring the Oracle Internet Directory provider to match the LDAP schema for user and group attributes
This topic introduces WLST, if you are new to it.
You can add providers to a WebLogic domain using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.
WLST is a Jython-based command-line scripting environment that you can use to manage and monitor WebLogic Server domains. Generally, you can use this tool online or offline. You can use this tool interactively on the command line in batches supplied in a file (Script Mode, where scripts invoke a sequence of WLST commands without requiring your input), or embedded in Java code.
When adding Authentication Providers to a WebLogic domain, you can use WLST online to interact with an Authentication Provider and add, remove, or modify users, groups, and roles.
When you use WLST offline to create a domain template, WLST packages the Authentication Provider's data store along with the rest of the domain documents. If you create a domain from the domain template, the new domain has an exact copy of the Authentication Provider's data store from the domain template. However, you cannot use WLST offline to modify the data in an Authentication Provider's data store.
Note:
You cannot use WLST offline to modify the data in an Authentication Provider's data store.
See Also:
On the Oracle WebLogic Server, you can run a Web application that uses Oracles Application Development Framework (Oracle ADF) security, integrates with Oracle Access Manager Single Sign On (SSO), and uses Oracle Platform Security Services (OPSS) SSO for user authentication. However before the Web application can be run, you must configure the domain-level jps-config.xml file on the application's target Oracle WebLogic Server for the Oracle Access Manager security provider.
The domain-level jps-config.xml file is in the following path and should not be confused with the deployed application's jps-config.xml file:
domain_home/config/fmwconfig/jps-config.xml
You can use an Oracle Access Manager-specific WLST script to configure the domain-level jps-config.xml file, either before or after the Web application is deployed. This Oracle JRF WLST script is named as follows:
Linux: wlst.sh
Windows: wlst.cmd
The Oracle JRF WLST script is available in the following path if you are running through JDev:
$JDEV_HOME/oracle_common/common/bin/
In a standalone JRF WebLogic installation, the path is:
$Middleware_home/oracle_common/wlst
Note:
The Oracle JRF WLST script is required. When running WLST for Oracle Java Required Files (JRF), do not use the WLST script under $JDEV_HOME/wlserver_10.3/common/bin.
Command Syntax
addOAMSSOProvider(loginuri, logouturi, autologinuri)
Table 17-11 defines the expected value for each argument in the addOAMSSOProvider command line.
Table 17-11 addOAMSSOProvider Command-line Arguments
| Argument | Definition |
|---|---|
|
loginuri |
Specifies the URI of the login page |
|
logouturi |
Specifies the URI of the logout page |
|
autologinuri |
Specifies the URI of the autologin page |
See Also:
Oracle Fusion Middleware WebLogic Scripting Tool Command Reference "Infrastructure Security Commands" chapter
Prerequisites
Before starting this task, ensure that all previous tasks have been performed as described in:
To modify domain-level jps-config.xml for a Fusion Web application with Oracle ADF Security enabled
On the computer hosting the Oracle WebLogic Server and the Web application using Oracle ADF security, locate the Oracle JRF WLST script. For example:
cd $ORACLE_HOME/oracle_common/common/bin
Connect to the computer hosting the Oracle WebLogic Server:
connect login_id password hostname:port
For example, the Oracle WebLogic Administration Server host could be localhost using port 7001. However, your environment might be different.
Enter the following command-line arguments with values for the application with ADF security enabled:
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",
logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
Stop and start the Oracle WebLogic Server.
Perform the following tasks as described in this chapter:
Run the application.
This topic describes how to configure providers in the WebLogic security domain to perform single sign-on with the Oracle Access Manager Identity Asserter. Several Authentication Provider types must be configured and ordered:
The following procedure uses the WebLogic Administration Console.
Note:
With an Oracle Fusion Middleware application installed, you have the required provider JAR file. Skip Step 1.
To set up Providers for Oracle Access Manager single sign-on in a WebLogic domain
No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider:
Log in to Oracle Technology Network at:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0):
oamAuthnProvider<version number>.zip
Extract and copy oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
With Oracle Fusion Middleware Application Installed:
Locate oamauthenticationprovider.war in the following path:
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi der.war
Copy oamauthenticationprovider.war to the following location:
BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication provider.war
Log in to the WebLogic Administration Console.
Click Security Realms, Default Realm Name, and click Providers.
OAM Identity Asserter: Perform the following steps to add this provider:
Click Authentication, click New, and then enter a name and select a type:
Name: OAM Identity Asserter
Type: OAMIdentityAsserter
OK
In the Authentication Providers table, click the newly added authenticator.
Click the Common tab, set the Control Flag to REQUIRED, and click Save
OID Authenticator: Perform the following steps to add this provider.
Click Security Realms, Default Realm Name, and click Providers
Click New, enter a name, and select a type:
Name: OID Authenticator
Type: OracleInternetDirectoryAuthenticator
OK
In the Authentication Providers table, click the newly added authenticator.
On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, and then click Save.
Click the Provider Specific tab and specify the following required settings using values for your own environment:
Host: Your LDAP host. For example: localhost
Port: Your LDAP host listening port. For example: 6050
Principal: LDAP administrative user. For example: cn=orcladmin
Credential: LDAP administrative user password.
User Base DN: Same searchbase as in Oracle Access Manager.
All Users Filter: For example: (&(uid=*)(objectclass=person))
User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid
Group Base DN: The group searchbase (same as User Base DN)
Do not set the All Groups filter as the default works fine as is.
Save.
Default Authenticator: Perform the following steps to set up the Default Authenticator for use with the Identity Asserter:
Go to Security Realms, Default Realm Name, and click Providers.
Click Authentication, Click DefaultAuthenticator to see its configuration page.
Click the Common tab and set the Control Flag to SUFFICIENT.
Save.
Reorder Providers:
Click Security Realms, Default Realm Name, Providers.
On the Summary page where providers are listed, click the Reorder button
On the Reorder Authentication Providers page, select a provider name and use the arrows beside the list to order the providers as follows:
OAM Identity Asserter (REQUIRED)
OID Authenticator (SUFFICIENT)
Default Authenticator (SUFFICIENT)
Click OK to save your changes
Activate Changes: In the Change Center, click Activate Changes
Reboot Oracle WebLogic Server.
Proceed as follows:
Successful: Go to "Setting Up the Login Form for the Identity Asserter and OAM 10g".
Not Successful: Confirm that all providers have the proper specifications for your environment, are in the proper order, and that oamAuthnProvider.jar is in the correct location as described in "Installing Components and Files for Authentication Providers and OAM 10g".
This topic introduces the login form provided for the Oracle Access Manager Identity Asserter for single sign-on and provides a procedure that you can use to deploy the form.
The form shown in Figure 17-9 is provided with the WebGate installation for Oracle HTTP Server 11g Web server. The form contains two fields (UserID and Password) and a Login button. The variables in this form are required by the Form Login authentication scheme that was generated by the OAMCfgTool and used in the policy domain protecting resources for Identity Assertion.
Figure 17-9 Default Login Form for Single Sign-On with 10g WebGates
Note:
Do not alter any variables in this login form. Variables are required for use with Oracle Access Manager Identity Asserter.
The following information is added to the Oracle HTTP Server 11g Web server httpd.conf file during WebGate installation and configuration. It ensures that WebGate for Oracle HTTP Server 11g can find the default login form.
Alias /oamsso "/oam/webgate/access/oamsso"
Delete the following three lines if they exist:
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
The following procedure guides as you set up the login form for your environment.
Note:
The Login form is for only 10g WebGates with OAM 10g.
To set up the login form for Identity Assertion and OAM 10g
Verify that the login form is located in the following Oracle HTTP Server11g WebGate path on the computer hosting the application:
WebGate_install_dir/access/oamsso/login.html
From your browser, go to the following URL:
http://WebGatehost:port/oamsso/login.html
Confirm that the /access policy was created and enabled to protect Policy Manager resources to ensure that the login process can redirect authenticated users to the originally requested application URL.
Proceed to:
The following procedure describes how to test your Oracle Access Manager Identity Assertion setup.
Alternatively, you can run Access Tester within Oracle Access Manager 10g to test your policy domain, as described in the 10g Oracle Access Manager Access Administration Guide.
To validate Identity Assertion for SSO with OAM 10g
Enter the URL to access the protected resource in your environment. For example:
http://ohs_server:port/<protected url>
Provide appropriate credentials when the login form appears.
Successful: The implementation works.
Not Successful: See "Troubleshooting Tips for OAM Provider Deployments".
To configure the Oracle Access Manager Authentication Provider as the Authenticator, you must perform the tasks in this section.
Prerequisites
Unless explicitly labeled Identity Assertion, all tasks described in "Installing and Setting Up Authentication Providers for OAM 10g" must be completed:
Installing Components and Files for Authentication Providers and OAM 10g which includes manually creating AccessGate profiles in the Access System Console and accepting defaults during Policy Manager setup
Converting Oracle Access Manager Certificates to Java Keystore Format, if you are using Simple or Cert transport security mode.
Remaining tasks to configure the Oracle Access Manager Authenticator are described in the following task overview.
Note:
You must be either a Master or Delegated Access Administrator in Oracle Access Manager to perform tasks here. There is no tool available to automate tasks outside Oracle Access Manager.
Task overview: Configuring the Oracle Access Manager Authenticator includes
Ensuring that all prerequisite tasks have been performed
Configuring a Policy Domain for the Oracle Access Manager Authenticator
Configuring Providers for the Authenticator in a WebLogic Domain
Configuring the Application Authentication Method for the Authenticator
Testing the Oracle Access Manager Authenticator Implementation
This topic describes how to create an authentication scheme for the policy domain you will define for the Authenticator later. The Oracle Access Manager authentication scheme must be available before you create the policy domain.
With the Authenticator, the user is challenged for credentials based on the authentication method that is configured within the application web.xml. However, an Oracle Access Manager authentication scheme is required for the policy domain.
After creating an authentication scheme for the Authenticator, you must create a policy domain in Oracle Access Manager to user the scheme.
A policy domain in Oracle Access Manager includes several types of information. Individual tabs are provided where you can enter specific details, as shown in Figure 17-10.
Figure 17-10 Create Policy Domain Page in the Oracle Access Manager Policy Manager
For more information, see the following topics:
This topic describes the tabs in the Policy Manager that you use to enter details for your policy domain and access policies. While you might not use every tab in your policy domain, the following general information is provided:
General Tab: Enter a short alphanumeric string to name this policy domain. You can use spaces in the Name field. A description is optional. Do not enable this policy domain until all details are saved and you are ready to use the domain.
Resources Tab: Add resources to be protected by this policy domain. You use URL prefixes to define the policy domain content. A description is optional.
Authorization Rules Tab: specify an authorization rule that consists of general information, Allow Access and Deny Access conditions, and actions for the rule, if any, to be used in an Authorization Expression later. You must specify an authorization scheme for every authorization rule you define.
Default Rules Tab: Create default rules that apply to the resources protected by the policy domain, unless the resource is protected by a specific policy. From this tab you add the authentication rule, authorization expression, and audit rule for this policy domain.
Authentication Rule: A policy domain must have at least one authentication rule, which specifies one authentication scheme and authentication actions.
Authorization Expression: These include authorization rules and the operators used to combine them. The Authenticator function requires an Authorization rule that allows access by anyone.
Audit Rule: If there is no Master Audit Rule defined, you are instructed to contact your Access System Administrator.
Policies Tab: If no rules are defined, the default rules for the policy domain remain in effect. For each policy you create, you can assign a specific authentication rule, authorization expression, and auditing rule. You can create policies with granular URL patterns. Before setting up a policy, decide the level of access control needed for the URL you to be protected.
Delegated Administrators Tab: When adding URL prefixes to a policy domain, the Delegated Access Administrator must specify a server hosting the URL prefix.
See Also:
"Creating a Policy Domain and Access Policies for the Authenticator" and the following topics in the Oracle Access Manager Access Administration Guide:
"Creating an Authentication Rule for a Policy Domain"
"Creating an Audit Rule for a Policy Domain"
The Authenticator implementation requires several default and some unique values in the policy domain. You must be a Master or Delegated Access Administrator in Oracle Access Manager to create, view, or modify a policy domain.
In the following procedure, you create a policy domain for the Authenticator to:
Use the default Basic Authentication scheme (set up with Policy Manager) internally to authenticate users and to protect URL resources prefixed with /Authen/Basic.
Protect resources of type wl_authen, which was defined earlier. See also, "Creating Resource Types in Oracle Access Manager 10g"
Request user credentials using the Oracle Access Manager authentication scheme created earlier.
Note:
The Authenticator requires the BASIC authentication method defined in the application web.xml file, which you will set up later as described in "Configuring the Application Authentication Method for the Authenticator".
Require a default authentication rule and actions, which you configure in the following procedure to return users and groups on authentication success.
Require a default authorization rule with no actions, which you configure in the following procedure to allow access by anyone.
Note:
The Authenticator does not perform authorization. However, you must create the authorization rule to allow access by anyone (but no authorization expression is required).
Examples in the following procedure are for illustration only. Be sure to enter appropriate values for your environment.
To create a policy domain for the Oracle Access Manager Authenticator
Go to the Policy Manager and log in. For example:
http://Webserver:port/access/oblix
where Webserver refers to computer that hosts the Policy Manager Web server; port refers to the HTTP port number of the Web server instance; /access/oblix connects to the Access System.
Click Policy Manager.
Click Create Policy Domain in the left navigation pane to display the Create Policy Domain page.
General Tab: Fill in the name and optional description that appear in pages showing lists of policy domains, and then click Save. For example:
Name: Default OAM Authenticator
Description: For Username Resolution
Note:
Do not enable this policy domain until you finish all specifications.
Resources Tab: Click the Resources tab, click the Add button, select resource types, enter URL prefixes, and save as follows:
Resource Type: wl_authen
Host Identifier (optional): Select the Preferred HTTP host for the AccessGate.
URL prefix: /Authen/Basic
Description: OAM Authenticator validates user name, password
Click Add.
Resource Type: wl_authen
URL prefix: /Authen/UsernameAssertion
Description: Authenticator Resource to validate user name
Click Save.
Default Rules Tab: From this tab you add the authentication rule, authorization expression, and audit rule for this policy domain. The policy domain's default rules apply to the resources it contains, unless the resource is protected by a specific policy.
Click Default Rules, and then click Add to create the rule for the Basic Authentication scheme.
Authentication Rule: A policy domain must have at least one authentication rule, which specifies one authentication scheme and authentication actions. Enter a Name, optional description, and choose an Authentication Scheme.
Click Authentication Rule and fill in the General tab as follows.
Name: Basic Authentication Scheme
Description: User name and password based authentication
Authentication Scheme: Basic over LDAP
Click Save.
Note:
For the Authenticator you need only an Authentication Success Return Action in the rule for the ObMyGroups attribute. This Access Server-specific attribute returns all the groups to which the user belongs. Two other implementations require this action, as described in Step C.
Authentication Rule, Actions: For the Authenticator (or to boot Oracle WebLogic with Administrator users who exist in Oracle Access Manager, or if you are using Oracle Web Services Manager).
Click the Actions tab, click Add.
Enter the following for Authentication Success:
Redirection URL: Leave blank
Return
Type: WL_REALM
Name: obmygroups
Return Attribute: obmygroups
This return attribute directs the Access Server to return all groups to which the user belongs.
Next, enter the name of the login parameter for user name to help in identifying the user uniquely in the LDAP directory server
Type: WL_REALM
Name: uid
Return Attribute: uid
This return attribute should be the name of the login parameter for the user name. This helps in identifying the user uniquely in the LDAP directory server used by Oracle Access Manager.
Authorization Rule: Click the Authorization Rules tab, click Add and:
Specify a rule name and, optionally, a brief description. For example:
Name: Default rule for Authenticator.
Description: Default rule enables Authenticator function for anyone.
Select Yes from the Enabled list and then click Save.
Click the rule, click the Allow Access tab, click Add, Under Role, select Anyone to allow anyone access to the protected resources.
Click Save.
Policies Tab: Click the Policies tab, click Add.
Fill in and save General details:
Name: Default Username Resolution Policy
Description: Default Username Policy for Authenticator
Resource Type: wl_authen
Resource operation(s): LOGIN
Resource: /Authen/UsernameAssertion
Leave other items as they are.
Click Save.
Click the Authentication Rule sub tab, click Add, and fill in General details (Name, optional Description, Authentication Scheme).
Name: Username Resolution Authentication Rule
Authentication Scheme: UsernameAssertion Authentication Scheme
See "Creating an Authentication Scheme for the Authenticator".
Click Save.
Click the Actions sub tab and add the following details for Authentication Success:
Return Type: WL_REALM
Return Name: uid
Return Attribute: uid
Note:
Be sure to enter Return Attribute. uid is the name of the login attribute in the LDAP ObjectClass that helps to identity the user uniquely in the directory server used by Oracle Access Manager.
Click the Actions sub tab and add the following details for Authentication Success:
Return Type: WL_REALM
Return Name: obmygroups
Return Attribute: obmygroups
Note:
obmygroups returns all groups to which a member belongs.
Delegated Access Admins: When adding URL prefixes to a policy domain, the Delegated Access Administrator must specify a server hosting the URL prefix.
See Also:
Oracle Access Manager Access Administration Guide, "Delegating Policy Domain Administration"
Proceed with "Configuring Providers for the Authenticator in a WebLogic Domain".
This topic includes a procedure that you can use to add and configure the appropriate Authentication Providers in a WebLogic domain.
The Oracle Access Manager Authenticator must be configured along with the Default Authentication Provider in a WebLogic domain.
The following procedure describes this task using the WebLogic Administration Console. You can also add these using the Oracle WebLogic Scripting Tool (WLST).
See Also:
Note:
When a Oracle Fusion Middleware application is installed, you have the required files and can skip Step 1.
To configure providers for the Oracle Access Manager Authenticator in a WebLogic domain
No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.
Log in to Oracle Technology Network at:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:
oamAuthnProvider<version>.zip
Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Go to the Oracle WebLogic Administration Console.
With Oracle Fusion Middleware Application Installed:
Locate oamauthenticationprovider.war in the following path:
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi der.war
Copy oamauthenticationprovider.war to the following location:
BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication provider.war
Go to the Oracle WebLogic Administration Console.
Click Lock & Edit, if desired.
OAM Authenticator:
Click Security Realms and select the realm you want to configure.
Select Providers, Authentication, and click New to display the Create a New Authentication Provider page
Enter a name and select a type:
Name OAMAuthN
Type: OAMAuthenticator
OK
Click the name of the Authentication Provider you have just created to display the Provider Configuration page.
In the Provider Configuration page, set the required values as follows:
Access Gate Name: The name of the AccessGate profile used by the provider. This must match exactly the name in the AccessGate configuration profile in the Access System Console.
Note:
You might have only one AccessGate configuration profile for the Authenticator.
Access Gate Password: The same password, if any, that is as defined for the AccessGate configuration profile in the Access System Console.
Primary Access Server: The host:port of the primary Access Server that is associated with this AccessGate in the Access System Console.
Advanced Configuration: Following are several advanced configuration values.
Transport Security: The communication mode between Access Server and AccessGate: open, simple, or cert.
If transport security is Simple or Cert, include the following parameters and values:
Trust Store: The absolute path of JKS trust store used for SSL communication between the provider and the Oracle Access Server.
Key Store: The absolute path of JKS key store used for SSL communication between the provider and the Oracle Access Server.
Key Store Pass Phrase: The password to access the key store.
Simple mode pass phrase: The password shared by AccessGate and Access Server for simple communication modes.
Secondary Access Server: The host:port of the secondary Access Server that is associated with this AccessGate in the Access System Console.
Maximum Access Server Connections in Pool: The maximum number of connections that the AccessGate opens to the Access Server. The default value is 10.
Note:
The Maximum Access Server Connections in Pool (or Minimum Access Server Connections in Pool) settings in the WebLogic Administration Console are different from the Maximum (or Minimum) Connections specified in profiles within the Access System Console.
Minimum Access Server Connections in Pool: The minimum number of connections that the Authentication Provider uses to send authentication requests to the Access Server. The default value is 5.
See Also:
"Oracle Access Manager Authentication Provider Parameter List" for descriptions and values of the common and provider-specific parameters
Ensure that the parameter Control Flag is set to OPTIONAL initially.
Note:
Do not set the parameter Control Flag to REQUIRED until you have verified that the Authentication Provided is operational and configured correctly.
In the Change Center, click Activate Changes.
DefaultAuthenticator: Under the Providers tab, select DefaultAuthenticator, which changes its control flag to SUFFICIENT.
Reorder: Under the Providers tab, reorder the providers so that DefaultAuthenticator is first (OAMAuthenticator follows DefaultAuthenticator).
Note:
If the Oracle Access Manager Authenticator flag is set to REQUIRED, or if Oracle Access Manager Authenticator is the only Authentication Provider, perform the next step to ensure that the LDAP user who boots Oracle WebLogic Server is included in the administrator group that can perform this task. By default the Oracle WebLogic Server Admin Role includes the Administrators group.
Oracle Access Manager Authenticator REQUIRED or the Only Authenticator: Perform the following steps to set user rights for booting Oracle WebLogic Server.
Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).
Note:
To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.
Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.
From the WebLogic Administration Console, go to Security Realms, myrealm, Roles and Policies, Global Roles.
Select View Conditions for the Admin Role.
Add the group and click Save.
Reboot the WebLogic Server.
Once the server has started, reset the Authentication Provider parameter Control Flag to the appropriate value (REQUIRED, OPTIONAL, or SUFFICIENT).
Note:
The recommended value is REQUIRED. To prevent a known issue, see "JAAS Control Flag".
Proceed with "Configuring the Application Authentication Method for the Authenticator".
This topic describes how to create the application authentication method for Oracle Access Manager Authenticator.
When you use the Oracle Access Manager Authenticator, all web.xml files in the application EAR file must specify BASIC in the element auth-method for the appropriate realm.
The auth-method can use BASIC or FORM values. While these look like similar values in Oracle Access Manager, the auth-method specified in web.xml files are used by Oracle WebLogic Server (not Oracle Access Manager).
Note:
For the Oracle Access Manager Authenticator, Oracle recommends auth-method BASIC in login-config within web.xml.
To configure the application authentication method for the Authenticator
Locate the web.xml file in the application EAR file:
WEB-INF/web.xml
Locate the auth-method in login-config and enter BASIC. For example:
<security-constraint> <web-resource-collection> <web-resource-name>protected</web-resource-name> <url-pattern>/servlet</url-pattern> </web-resource-collection> <auth-constraint> <role-name>auth-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <description>Authenticated Users</description> <role-name>auth-users</role-name> </security-role>
Save the file.
Redeploy and restart the application.
Repeat for each web.xml file in the application EAR file.
Proceed with "Mapping the Authenticated User to a Group in LDAP".
This topic describes how to map the authenticated user to a group in LDAP. To do this, you must edit the weblogic.xml file. For example, you might need to map your role-name auth-users to a group named managers in LDAP.
To map the authenticated user to a group in LDAP for the Oracle Access Manager Authenticator
Go to the application's weblogic.xml file.
Add the following information for your environment anywhere in the file:
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<security-role-assignment>
<principal-name>managers</principal-name>
<role-name>auth-users</role-name>
</security-role-assignment>
</weblogic-web-app>
Save the file.
Restart the WebLogic Server.
Proceed to:
After performing all tasks to implement the Authenticator, you can test it by attempting to log in to the application using valid credentials. If the configuration is incorrect, a valid user is denied access.
The following procedure describes how to test your Authenticator setup. Alternatively, you can run Access Tester in Oracle Access Manager to test your policy domain, as described in the Oracle Access Manager Access Administration Guide.
To validate the Oracle Access Manager Authenticator implementation
Enter the URL to access the protected resource in your environment. For example:
http://yourdomain.com:port
Provide appropriate credentials when the login form appears.
Successful: The implementation works.
Not Successful: See "Troubleshooting Tips for OAM Provider Deployments"
This section describes how to set up the Oracle Access Manager Identity Asserter to enable validation of ObSSOCookie token when you have Oracle Web Services Manager protecting Web services.
When the Oracle Access Manager Identity Asserter is configured for both header and ObSSOCookie token validation modes, preference is given to the presence of the header. If the header is not present, the Identity Asserter contacts the Access Server to validate the ObSSOCookie token.
Oracle Access Manager Identity Asserter works in two modes:
The default mode of operation simply asserts the header that is set by WebGate at the perimeter.
The alternate mode uses the custom AccessGate in oamAuthnProvider.jar. In this case, and with the absence of the header, the Identity Asserter contacts with the Access Server to validate the ObSSOCookie token.
Note:
The AccessGate is required for Oracle Web Services Manager.
Prerequisites
Installing Components and Files for Authentication Providers and OAM 10g which includes manually creating AccessGate profiles in the Access System Console for the custom AccessGate and accepting defaults during Policy Manager setup
Task overview: Deploying the Identity Asserter with Oracle Web Services Manager includes
Ensuring that all prerequisite tasks have been performed
Creating an Policy Domain for Use with Oracle Web Services Manager
Configuring Providers in a WebLogic Domain for Oracle Web Services Manager
Testing the Identity Asserter with Oracle Web Services Manager
This topic describes how to set up a policy domain for use by the Oracle Access Manager Identity Asserter when you have Oracle Web Services Manager protecting Web services. You must be a Master or Delegated Access Administrator in Oracle Access Manager to create, view, or modify a policy domain.
The following unique values are required in this policy domain:
Requires the default Basic over LDAP Authentication scheme (set up with Policy Manager) internally to authenticate users and to protect URL resources prefixed with /Authen/SSOToken.
Protects resources of type wl_authen, which were defined in "Creating Resource Types in Oracle Access Manager 10g"
Requires a default authentication rule with no actions, which you set up in the following procedure
Requires a default authorization rule with actions, which you set up in the following procedure.
The following procedure walks you through creating a policy domain for use with Oracle Web Services Manager and the Oracle Access Manager Identity Asserter.
To create a policy domain for the Identity Asserter with Oracle Web Services Manager
Go to the Policy Manager and log in. For example:
http://Webserver:port/access/oblix
where Webserver refers to computer that hosts the Policy Manager Web server; port refers to the HTTP port number of the Web server instance; /access/oblix connects to the Access System Console.
Click Policy Manager.
Click Create Policy Domain in the left navigation pane to display the Create Policy Domain page.
General Tab: Fill in a name and optional description that appears in pages showing lists of policy domains, and then click Save. For example:
Name: OAM IA OWSM
Description: Used by Identity Asserter with Oracle Web Services Manager
Note:
Do not enable this policy domain until you finish all details.
Resources Tab: Click the Resources tab, click the Add button, select resource types, enter URL prefixes, and save as follows:
Resource Type: wl_authen
URL prefix: /Authen/SSOToken
Description: Used by IA OWS to validate SSO token
Save.
Authorization Rules Tab: Add an authorization rule to use in an Authorization Expression later.
Click the Authorization Rules tab, then click the Add button
General Tab: For Authorization Rules, enter a rule name and, optionally, a brief description.
Name: Default_OAM_IA_OWS_AuthZ_Rule
Description: For use with OWS and Identity Asserter.
Enabled: Yes
Allow takes precedence: No
Update Cache: Yes (updates all Access Server caches immediately)
Timing Conditions: None required for this scenario.
Actions: None required on this tab. Instead, you set these up under the Default Rules tab.
Allow Access: Add details that define to whom the Allow Access part of the rule applies.
Role: Any one
Deny Access: Not Needed for this scenario.
Return to the General tab for Authorization Rules and enable the rule so that you can add it to an authorization expression later.
See Also:
Chapter 6 in Oracle Access Manager Access Administration Guide for details about configuring authorization schemes and rules.
Default Rules Tab: From here you can add the authentication rule, authorization expression, and audit rule for this policy domain. These default rules apply to the resources it contains, unless the resource is protected by a specific policy.
Click Default Rules, and then click Add.
Authentication Rule: A policy domain must have at least one authentication rule, which specifies one authentication scheme and optional authentication actions. Enter a Name, optional description, and choose an Authentication Scheme.
General tab: Fill in the as follows:
Name: Default AuthN Rule
Description: Default Rule for OAM IA OSW
Authentication Scheme: Basic over LDAP
Click Save.
Actions tab: No authentication actions are needed in the default rule for Oracle Web Services Manager.
Note:
With Oracle Web Services Manager you need an Authorization rule.
Authorization Expression: The authorization expression in the default rules for a policy domain applies to all resources of the domain unless those resources are protected by a policy containing an expression.
Click the Authorization Expression tab, and then click Add.
Expression tab: Select the authorization rule you created in Step 6:
Select Authorization Rule: Default_OAM_IA_OWS_AuthZ_Rule
Click Add.
Click Save.
Actions tab: In Step 6 you defined to whom the Allow Access part of a rule applies. Here, you specify actions for Authorization success for both rules and expressions.
Click Actions, click Add, and then create a return action on Authorization Success with the following to specify what actions should be invoked when authorization succeeds.
Authorization Success: Applies to Allow Access conditions.
Return Type: WL_REALM
Return Name: uid
Return Attribute: uid
Click Save.
Note:
Return Attribute uid should match the value of the login parameter for the user name to help identify the user uniquely in the Oracle Access Manager LDAP repository. Here, uid is the canonical name of the login attribute. If your LDAP directory uses a different attribute as the login attribute, the Name should still be "uid". However, the Return Attribute would be whatever your login attribute is configured as (mail, for example). Be careful to put these values under Return Attribute (not Return Value).
Policies Tab: No policies are needed. Default Rules apply.
Delegated Access Admins: When adding URL prefixes to a policy domain, the Delegated Access Administrator must specify a server hosting the URL prefix.
See Also:
Oracle Access Manager Access Administration Guide, "Delegating Policy Domain Administration"
Validate Policy Domain: Click My Policy Domains, click the new policy domain you created, then click View As a Page to see all specifications at once.
Proceed with "Configuring Providers in a WebLogic Domain for Oracle Web Services Manager".
To use Oracle Access Manager Identity Asserter with Oracle Web Services Manager protected Web services, several Authentication Providers must be configured and ordered in a WebLogic domain:
This procedure is nearly identical to the one for the Oracle Access Manager Identity Asserter. The difference in this case is that Oracle Web Services Manager requires a custom AccessGate and additional provider-specific values are required:
Primary Access Server: Specify the host and part. For example: abcd:7777
Access Gate Name: The name of the AccessGate protecting the application. For example: mmmm
Access Gate Password: The AccessGate password as specified in the Access System Console.
You can add these using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.
See Also:
Note:
With a Oracle Fusion Middleware application installed, you have the required provider file. Skip Step 1.
To set up providers in a WebLogic domain
No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.
Log in to Oracle Technology Network at:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:
oamAuthnProvider<version>.zip
Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Log in to the Oracle WebLogic Administration Console.
OAM Identity Asserter: Perform the following steps to add this provider:
Click Security Realms, Default Realm Name, and click Providers.
Click Authentication, click New, and then enter a name and select a type:
Name: OAM Identity Asserter
Type: OAMIdentityAsserter
OK
In the Authentication Providers table, click the newly added authenticator.
On the Common tab, set the Control Flag to REQUIRED, and click Save.
Click Platform-Specific tab and configure these parameters:
Primary Access Server: Specify the host and part. For example: abcd:7777
Access Gate Name: The name of the AccessGate protecting the application. For example: mmmm
Access Gate Password: The AccessGate password as specified in the Access System Console.
Save
OID Authenticator: Perform the following steps to add this provider.
Click Security Realms, Default Realm Name, and click Providers
Click New, enter a name, and select a type:
Name: OID Authenticator
Type: OracleInternetDirectoryAuthenticator
Click OK.
In the Authentication Providers table, click the newly added authenticator.
On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, and then click Save.
Click the Provider Specific tab and specify the following required settings using values for your own environment:
Host: Your LDAP host. For example: localhost
Port: Your LDAP host listening port. For example: 6050
Principal: LDAP administrative user. For example: cn=orcladmin
Credential: LDAP administrative user password.
User Base DN: Same searchbase as in Oracle Access Manager.
All Users Filter: For example: (&(uid=*)(objectclass=person))
User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid
Group Base DN: The group searchbase (same as User Base DN)
Note:
Do not set the All Groups filter as the default works fine as is.
Click Save.
Default Authenticator: Perform the following steps to set up the Default Authenticator for use with the Identity Asserter:
Go to Security Realms, Default Realm Name, and click Providers.
Click Authentication, Click DefaultAuthenticator to see its configuration page.
Click the Common tab and set the Control Flag to SUFFICIENT.
Click Save.
Reorder Providers:
Click Security Realms, Default Realm Name, Providers.
On the Summary page where providers are listed, click the Reorder button
On the Reorder Authentication Providers page, select a provider name and use the arrows beside the list to order the providers as follows:
OAM Identity Asserter (REQUIRED)
OID Authenticator (SUFFICIENT)
Default Authenticator (SUFFICIENT)
Click OK to save your changes
Activate Changes: In the Change Center, click Activate Changes
Reboot Oracle WebLogic Server.
Proceed as follows:
Successful: Go to "Testing the Identity Asserter with Oracle Web Services Manager".
Not Successful: Confirm the all providers have the proper specifications for your environment, are in the proper order, and that oamAuthnProvider.jar is in the correct location as described in "Installing Components and Files for Authentication Providers and OAM 10g".
To validate the use of the Oracle Access Manager Identity Asserter with Oracle Web Services Manager, you can access the Web service protected by the Identity Asserter and Oracle Web Services Manager policies. If access is granted, the implementation works. If not, see "Troubleshooting Tips for OAM Provider Deployments".
In Fusion Middleware 11g, a new component that synchronizes the container user session and SSO session has been introduced. SSO Sync Filter is an Oracle WebLogic system filter implementation that intercepts all requests to the container, acts on protected resource requests, and attempts to synchronize the container's user session with the user identifying header in OSSO (Proxy-Remote-User) or the user data in the Oracle Access Manager SSO session cookie (ObSSOCookie).
SSO Synchronization Filter (SSO Sync Filter) is an implementation of the Servlet Filter based on Java Servlet Specification version 2.3. SSO sync filter relieves applications from tracking the SSO user session and synchronizing it with their respective sessions. Instead, applications would only need to synchronize with container's user session.
SSO Sync Filter intercepts each request to the container and determines whether to act on it based on certain HTTP headers that are attached to the request. Filter expects SSO agent to have set those headers in the Web Tier. When access is made to unprotected areas of the application, the filter acts as a pass through. Once a protected resource is accessed, SSO agents in the Web Tier, direct user to perform authentication with SSO system such as Oracle Access Manager. After the authentication, Oracle Access Manager Identity Asserter helps establish a user identity in form of JAAS Subject to the container and a user session is created. WebLogic maintains the user session data as part of HTTP Session Cookie (JSESSIONID).
Subsequent access to the application resources provides two pieces of information to the SSO Sync Filter:
User identifying header in OSSO (Proxy-Remote-User)
User data in the Oracle Access Manager SSO session cookie (ObSSOCookie)
The job of SSO Sync Filter is to make sure that the user identity in the container matches with that of the SSO session. If there is a mismatch, filter invalidates the container's user session. As a result, the downstream application would only have to track container user session and react in a consistent fashion regardless of SSO environment in use.
Notes:
Enabled and Active by Default: SSO Sync Filter fetches the user information from the configured tokens, gets the user from existing session (if any), invalidates the session and redirects to the requested URL in case the CurrentSessionUser does not match the incoming SSO User. Otherwise, the request is simply passed through.
If you have not configured the OSSO or Oracle Access Manager Assertion Providers in your domain, the filter disables automatically during WebLogic Server start-up.
Active for All URI's by Default (/*): No changes are required in the application code.
Configured for the OSSO Tokens/Header: Proxy-Remote-User, and performs a case insensitive match.
Configured for the Oracle Access Manager SSO Tokens/Header: OAM_REMOTE_USER and REMOTE_USER, and does a case insensitive match.
Global Logout: SSO Sync Filter is intended to provide the Single Logout Experience to the Oracle Fusion Middleware applications that use the OSSO or Oracle Access Manager Solutions. Is handled similarly to single sign-on. After global logout is performed, SSO filter reconciles the session when subsequent access to an application that has not cleaned up its session is made.
Any application that use the OSSO or Oracle Access Manager Solutions is expected to invalidate its session before making a call to OSSO logout or Oracle Access Manager logout. For more information on OSSO logout, see Example 18-2, "SSO Logout with Dynamic Directives". For details about Oracle Access Manager logout, see "Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates".
Application Session Time Out: SSO cookies typically track user inactivity/idle times and force users to login when a time out occurs. OSSO and Oracle Access Manager are no exception. Oracle Access Manager takes a sophisticated approach at this and specifically tracks Maximum Idle Session Time and Longest Idle Session Time along with SSO session creation time and time when it was last refreshed.
The general recommendation for applications that are maintaining their own sessions when integrating with SSO systems is to configure their session time outs close to that of SSO session time outs so as to make user experience remains consistent across SSO and application session time outs.
You can alter the behavior of the SSO Sync Filter for application requirements by passing various over-riding system properties to WebLogic. To do this, you change the Oracle WebLogic startup script and check for EXTRA_JAVA_PROPERTIES in setDomainEnv.sh. The properties and Sync behavior is shown in Table 17-12.
Table 17-12 SSO Sync Filter Properties and Sync Behavior
| Area | Overriding System Property | Default value of System property | Default Behavior of the Sync Filter |
|---|---|---|---|
|
Status (Active or Inactive) |
sso.filter.enable |
Not configured |
Enabled |
|
Case sensitive matches |
sso.filter.name.exact.match |
Not configured |
Case Ignore Match |
|
Configured Tokens |
sso.filter.ssotoken |
Not configured |
|
|
URI Mappings |
Not Applicable |
Not Applicable |
/* |
You cannot enable the filter for selected applications. The SSO Sync Filter is a system filter. As such, it is activated for all deployed applications (the URI mapping is /*).
Note:
You cannot enable the filter for selected applications.
The following procedure gives some tips about modifying the SSO Sync filter properties and behavior.
To modify the SSO Sync Filter properties and behavior
Disable the Filter: Change the system property "sso.filter.enable" to "false" (pass as -D to the jvm) and restart the Oracle WebLogic Server. This toggles the filter status.
User-Identifying Header Differs from Pre-Configured Sync Filter Tokens: Over-ride the SSO token that the Sync Filter looks for using the system property "sso.filter.ssotoken".
For example, pass to the WebLogic Server jvm in the WebLogic Server startup script -Dsso.filter.ssotoken=HEADERNAME, and restart the server.
When you contact Oracle Support you might be requested to set up debugging, as described in "Setting Up Debugging in the WebLogic Administration Console".
This section contains the following topics:
Oracle Fusion Middleware and Oracle Access Manager support Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6.) Among other features, IPv6 supports a larger address space (128 bits) than IPv4 (32 bits), providing an exponential increase in the number of computers that can be addressable on the Web.
See Also:
Oracle Fusion Middleware Administrator's Guide for details about using IPv6.
If you experience a failure of the Apache bridge, you might see a message stating that there is no back-end server available for connection. In this case, the connection times out.
The Oracle WebLogic Server might be down or there might be incorrect values set in mod_weblogic.
To recover from an Apache Bridge Failure
Check the Oracle WebLogic Server to ensure that it is available.
Confirm that host and port information is specified correctly in the WebGate's Web server httpd.conf. For example:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>
It is possible that an authenticated user does not have access rights to the requested resource.
If a user login is inconclusive or invalid, the user can be authenticated but not recognized as authorized for the requested resource. In this case, no explicit error message states the issue. Instead, the user is prompted to log in again.
After successful authentication, if you click the Back button in the browser window, you might get an error for access/oblix/apps/webgate/bin/webgate.so.
When form-based authentication is used, Oracle Access Manager creates a form login cookie that holds information about the requested resource. On successful authentication, the state of the cookie changes. When the user clicks the Back button, the login form appears. When re-posted, the form login cookie no longer holds redirection details.
The ObSSOCookie is also sent with the form login cookie.The ObSSOCookie is correctly checked. As the form login cookie state changes, the form-based authentication does not occur and the form action is considered as a request for the resource.
Solution
Retry the request using the original URL.
If the Oracle Access Manager Authenticator flag is set to REQUIRED, or if Oracle Access Manager Authenticator is the only Authentication Provider, perform the next step to ensure that the LDAP user who boots Oracle WebLogic Server is included in the administrator group that can perform this task. By default the Oracle WebLogic Server Admin Role includes the Administrators group.
To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.
To ensure you can restart the WebLogic Server
Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).
Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.
From the WebLogic Administration Console, go to Security Realms, myrealm, Roles and Policies, Global Roles.
Select View Conditions for the Admins Role.
Add the group and click Save.
Out of the box, Oracle Access Manager does not support load balanced AccessGates; you must use a third-party load balancer.
Suppose you have two WebGates: WebGateA and WebGateB. You can use the OAMCfgTool to create the profile to be shared by the two WebGates.
See Also:
If you have an Oracle Fusion Middleware Application installed you already have the OAMCfgTool. In this case, skip Step 1.
Solution:
No Oracle Fusion Middleware Application: Obtain the OAMCfgTool if you have no Oracle Fusion Middleware application installed.
Log in to Oracle Technology Network at:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Locate the OAMCfgTool ZIP file with Access Manager Core Components (10.1.4.3.0):
oamcfgtool<version>.zip
Extract and copy oamcfgtool.jar to the computer hosting WebGate:
Log in to the computer for WebGateA (even if WebGate is not yet installed).
Change to the file system directory containing OAMCfgTool and run a command like the following one to create one AccessGate Profile to be shared by the two WebGates. For example:
java -jar oamcfgtool.jar mode=CREATE app_domain=SharedA_B app_agent_password=<WebGate_password> cookie_domain=<preferred_http_cookie_domain> ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin ldap_userpassword=<ldap_userpassword> oam_aaa_host=abcd oam_aaa_port=7789 oam_aaa_mode=cert log_file=OAMCfg_date.log log_level=INFO output_ldif_file=<LDIF_filename>
Review the information provided by the tool. For example, the parameters and values in Step 3 would provide the following information:
Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain : SharedA_B
Host Identifier: SharedA_B_WD
Access Gate ID : SharedA_B_AG
Note:
Perform Step 5 if you have WebGate installed.
Perform Step 6 if WebGate is not yet installed.
Output LDIF Created: Import the LDIF to write information to the directory server. Otherwise, skip this step.
WebGates Not Installed: Install WebGateA and WebGateB and specify the same values as you did when creating the profile (plus additional values to properly finish the installation).
Installed WebGates: Using output from the OAMCfgTool Create command, run the Oracle Access Manager configureWebGate tool to set up the WebGate. For example:
Go to:
WebGate_install_dir\access\oblix\tools\configureWebGate
where WebGate_install_dir is the directory where WebGate is installed.
Run the following command to configure the WebGate using values specified with OAMCfgTool and other values needed to finish the installation. For example:
configureWebGate -i WebGate_install_dir -t WebGate SharedA_B_AG -P WebGate_password -m <open|simple|cert> -h Access_Server_Host_Name -p Access_Server_Port -a Access_Server_ID -r Access_Server_Pass_Phrase (must be the same as the WebGate_password) -Z Access_Server_Retry count
See Also:
"Configuring AccessGates and WebGates" in the Oracle Access Manager Access Administration Guide
Repeat these steps to configure WebGateB.
Confirm Profile in the Access System Console: Perform the following steps to view or modify the WebGate profile.
Log in to the Access System Console as a Master or Delegated Access Administrator. For example:
http://hostname:port/access/oblix
hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the Web server instance; /access/oblix connects to the Access System Console.
Click Access System Configuration, and then click AccessGate Configuration.
Click the All button to find all profiles (or select the search attribute and condition from the lists) and then click Go.
Click a WebGate's name to view its details.
Click Cancel to dismiss the page without changes, or click Modify to change values as described in the Oracle Access Manager Access Administration Guide.
In the load balancer host identifiers, add host name variations for both WebGates: WebGateA and WebGateB.
An error message like the following:
401 Authorization Required
This typically means that the Oracle Access Manager Authentication Provider is incorrectly configured. For a listing of correct configurations, see "Oracle Access Manager Authentication Provider Parameter List".
An error message like the following:
403 Forbiden
This typically means that the post-authenticate actions are incorrectly configured in the policy domain. Under the policy domain's authentication success actions, ensure that you have set obmygroups and uid in the Return Attribute field (not in the Return Value field).
For more information, see "Configuring a Policy Domain for the Oracle Access Manager Authenticator".
Generally, this error indicates that the server has not found anything matching the Request-URI. This message informs that the Oracle WebLogic Server is not able to find a resource.
There is no indication of whether the condition is temporary or permanent:
If the server cannot make temporary or permanent information available to the client, the status code 403 (Forbidden) can be used.
If, through some internally configurable mechanism, the server could state that an old resource is permanently unavailable and has no forwarding address, the 410 (Gone) status code should be used.
To recover from Error 404
Confirm that the resource is deployed on the Oracle WebLogic Server. For example, if the pattern is /private1/Hello, confirm that Hello is accessible on the server with private1 as the root.
This issue occurs if Form Authentication scheme is not properly configured in Oracle Access Manager. However, this cannot occur if you use the OAMCfgTool to set up a policy domain. For example:
Symptoms include:
The user name and password fields in the login form must match the details in the Form authentication scheme
The credential_mapping filter must be specified correctly in the Form authentication scheme
The login form action URL must be protected with a policy
The login form action URL must match the Action value specified in the authentication scheme's challenge parameter
If the WebLogic Server user is not part of the administrator's group in Oracle Access Manager, Oracle WebLogic Server restart and Authentication Provider initialization can fail. In this case, one of the following messages might appear in the AdminServer.log in $DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log:
)<Failed ---- FatalError:InvalidSchemeMapping ... Authentication Failed. ... Login failed. ...
Solution
Confirm that the implementation is using the Oracle-provided default login form.
Create a group named "Administrators" in the Oracle Access Manager Identity System, and include the Oracle WebLogic Server user.
Login to Oracle WebLogic Server using the credentials of the user in the Administrators group defined within the Oracle Access Manager Identity System.
Restart the Oracle WebLogic Server.
If this flag is set to REQUIRED and any other parameter is set to an incorrect value, the server does not start.
To prevent this issue, ensure that the Oracle Access Manager Authentication Provider is properly configured while this parameter value is set to OPTIONAL. Only after you have validated proper behavior in this way, should you reset the control flag to REQUIRED.
For more information, see "Configuring Providers for the Authenticator in a WebLogic Domain".
This issue typically points to an incorrect user name or password. No error is shown.
Ensure that you are supplying the correct user name and password. The user login name must be the value of the attribute that is configured in the Form Login authentication scheme. For example, Challenge Parameter creds: userid.
When a user logs out, or a user session times out, the user should be challenged for reauthentication. However, the following might occur instead:
Logout: After logging out, if the user attempts to access the application in the same browser window the application is still accessible without reauthenticating.
Session Time Out: After a user session time out, the user is challenged to reauthenticate. However, if the user gives a different user ID he is granted the same privileges as the previous user.
The ObSSOCookie is still present. Some configuration must be done at the application level to kill the ObSSOCookie. For proper behavior, WebLogic application session time out values should be the same as WebGate session time out values.
If setting up an Identity Asserter in the WebLogic Application Console, the Web application using the Identity Asserter must have its auth-method set to CLIENT-CERT. For more information, see "Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g".
If you receive a message stating that the requested URL or resource was not found on this server, the reverse proxy Web server might not be forwarding requests to the Oracle WebLogic Server.
To ensure that the reverse proxy is forwarding requests to Oracle WebLogic Server
Locate the httpd.conf file on the reverse proxy WebGate Web server. For example:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
Confirm the correct settings to forward requests to the correct host and port of the Oracle WebLogic Server:
#httpd.conf
<IfModule mod_weblogic.c>
WebLogicHost <host>
WebLogicPort yourWlsPortNumber
</IfModule>
<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>
If the Oracle WebLogic Server fails to start, you can take the following actions.
Determine whether the Oracle Access Manager Authentication Provider is the only provider configured in the Oracle WebLogic Server realm. If it is, continue with Step 2.
Confirm whether the Oracle Access Manager Authentication Provider is configured correctly and make any changes needed.
Determine whether the Oracle Access Manager Authentication Provider control flag is set to REQUIRED. In this case, perform the following steps:
Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).
Note:
To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.
Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.
From the WebLogic Administration Console, go to Security Realms, Your Realm, Roles and Policies, Global Roles.
Select View Conditions for the Administrators (or other) role.
Add the group and click Save.
Problem
WebGate configuration of cache directives might not be compatible with certain browser versions (specifically Internet Explorer v7) when accessing certain URLs that allow you to download Microsoft Office documents (.xls, .doc, and so on).
For example, suppose that you have an Excel workbook deployed along with an Oracle ADF application in an Oracle Access Manager Cert-based environment.
If the ADFDi component is trying to access two URLs, and trying the second URL first, a failure occurs regardless of the ADFDi client side code. It is not able to handle the redirect from Oracle Access Manager WebGate to the SSL enabled endpoint and fails with the following stack trace:
WebException: The request was aborted: Could not create SSL/TLS secure channel
If you attempt to access the workbook, and the following message appears:
Microsoft Office Excel cannot access the file
The cause could be any of the following:
The file name or path does not exist.
The file is being used by another program.
The workbook you are trying to save has the same name as a currently open workbook.
However, if the message appears when the URL to workbook is explicitly pasted to Internet Explorer v7 address bar it might be due to WebGate default Cache Directives.
WebGates have default Cache Directives (Pragma=no-cache and CacheControl=no-cache) that might cause a problem with Internet Explorer v7 when a URL to an .xls workbook is directly pasted into the browser's address bar.
Solution
If the message appears when the URL to workbook is explicitly pasted to Internet Explorer v7 address bar, Oracle recommends removing the cache directives from respective WebGate configuration pages in the Access System Console.
To remove cache directives from respective WebGate configurations
From the Access System Console, click the Access System Configuration tab.
Click AccessGate Configuration, click Go on the search page, and then click the link to the desired AccessGate configuration page.
On the Details for AccessGate page, click Modify.
On the Modify AccessGate page, locate Web Server Client label and clear the following fields:
CachePragmaHeader
CacheControlHeader
Click Save.
OAM Policies are evaluated based on the URIs passed to it. With earlier releases, there was no policy for protecting *;jsessionid*. When an application resource URL was accessed and the JSESSIONID cookie was not found, WebLogic Server wrote the URL by including the JSESSIONID as part of the URL. If the URL in question was protected, Oracle Access Manager and OSSO Web agents could have issues matching the re-written URL.
In this release, a new policy is available that uses a pattern "*;jessionid=*" for all URIs under the context-root. Therefore, any URI under the context-root, with ";jsessionid=string" appended to it, is considered protected.
The /context-root itself must be listed as a resource. The URL pattern is *;jsessionid=*. The Default authentication rule is a protected authenticating scheme. The Default authorization expression is also used. When ordering policies, this policy must be first.
Suppose you have one protected resource named /test/protectedUri and a public resource named /test. When you create a public policy with the pattern *jessionid;* and apply this policy to both the above resources the public policy should have precedence over the public resource.
When /test;jessionid=blah is requested, OAM first checks for a default rule for "/test;jessionid=blah". Without such a rule, OAM then checks for a rule for "/". Without this rule, the URI, "/test;jessionid=blah" is considered to be unprotected.
When "/test/protectedUri;jessionid=blah" is requested, OAM checks for a default rule to protect this. Without such a rule, OAM then checks for a rule for "/test". With "/test" in the Resources list, OAM further determines which policy to apply. In this case, the jessionid policy is applied and the request deemed to be protected.
|
 Copyright © 2003, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|