| 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 provides information on configuring single sign-on using Oracle Access Manager 11g. It includes the following major sections:
Configuring Centralized Log Out for Oracle Access Manager 11g
Synchronizing the User and SSO Sessions: SSO Synchronization Filter
Oracle Access Manager 11g is part of Oracle's enterprise class suite of security products. Intended for use in new and existing SSO deployments, Oracle Access Manager 11g provides a full range of Web perimeter security functions that include Web single sign-on; authentication and authorization; policy administration, and more.
Oracle Access Manager 11g single sign-on (SSO) and single log-out (SLO) supports a variety of application platforms including:
SOA
WebCenter
Oracle Access Manager 11g supports integration with a variety of applications, as described in the Oracle Fusion Middleware Integration Guide for Oracle Access Manager.
Oracle Identity Navigator
Oracle Identity Federation
Oracle Identity Manager
Oracle Adaptive Access Manager
As described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service, Oracle Access Manager 11g differs from Oracle Access Manager 10g in that identity administration features have been transferred to Oracle Identity Manager 11g. This includes user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration.
Console Protection for Oracle Identity Management Applications
Oracle Access Manager 11g and other Oracle Identity Management applications are deployed in a WebLogic container. Individual administration consoles include Oracle Access Manager, Oracle Adaptive Access Manager, Oracle Identity Navigator, Oracle Identity Manager, Oracle WebLogic Server, and Oracle Entitlements Server.
These are protected by default using pre-configured Authentication Providers in the WebLogic Administration Console and a pre-registered IAMSuiteAgent with Oracle Access Manager 11g. OAM 11g SSO policies are pre-seeded. No further configuration is needed for the consoles.
Preview of OAM 11g Deployments
You can configure Oracle Access Manager in a new WebLogic administration domain or in an existing WebLogic administration domain using the Oracle Fusion Middleware Configuration Wizard.
See "Requirements for the Provider with Oracle Access Manager"
Oracle Access Manager 11g provides new server-side components that maintain backward compatibility with new or existing policy-enforcement agents. Dynamic Server-initiated updates are performed for any policy or configuration changes.
Oracle Access Manager Console (installed on WebLogic Administration Server) replaces the OAM 10g Policy Manager
OAM Server (installed on a WebLogic Managed Sever; replaces the OAM 10g Access Server)
Oracle Access Manager 11g provides single sign-on (SSO), authentication, authorization, and other services to registered Agents (in any combination) protecting resources:
11g WebGates
10g WebGates
Java-based IAMSuiteAgent
OSSO Agents (10g mod_osso)
You can integrate with Oracle Access Manager 11g, any Web applications currently using Oracle ADF Security and the OPSS SSO Framework.
Only users with sufficient privileges can log in to the Oracle Access Manager Administration Console or use OAM administrative command-line tools. Your enterprise might require independent sets of administrators: one set of users responsible for OAM administration and a different set for WebLogic administration. For more information, see "Defining a New OAM Administrator Role" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
Overview of OAM 11g
The following outlines some of the basic features of Oracle Access Manager 11g:
Provisioning/Remote Registration: A new remote registration tool enables administrators inside or outside the network to register agents and policies. A username and password must be set in the primary User Identity Store for OAM 11g.
Authentication: Oracle Access Manager 11g application domains aggregate resources and security policies (one policy per resource). Oracle Access Manager 11g authentication policies include a specific scheme. Supported authentication modules include LDAP, X.509, and Kerberos. Authentication user mapping is performed against the primary user-identity provider by the centralized credential collector.
Authorization: Oracle Access Manager 11g performs authorization based on security policies defined in the application domain and persisted in the database. Authorization policies define the resource and constraint evaluation.
Responses: Administrators can set session attributes using authentication and authorization Responses. Aside from session attributes, a Response can also obtain user-related data and request-related data. Responses, once set, are then sent as either HTTP Headers or Cookies to the agent that helps manifest them. For cookie values and header variables, Responses can retrieve session attributes previously set by another Response. For example, session attributes set by a Response upon authentication can be retrieved as a header value during authorization.
Session Management: Oracle Access Manager 11g session management services track active user sessions through a high performance distributed cache system based on technology from Oracle Coherence. Each Oracle Access Manager runtime instance is a node within the distributed cache system. Secure communication between the nodes is facilitated using a symmetric key. The Oracle Access Manager runtime instances move user session data in the local cache into the distributed cache for other nodes to pick up. Each Oracle Access Manager runtime instance can also configure the replication factor and determine how session data is distributed. Administrators can configure the session lifecycle, locate and remove specific active sessions, and set a limit on the number of concurrent sessions a user can have at any time. Out-of-band session termination prevents unauthorized access to systems when a user has been terminated.
Keys: The Oracle Access Manager 11g runtime is deployed as an application to a WebLogic Managed Server or Cluster. New Oracle Access Manager 11g WebGates support a shared secret per agent trust model. 11g WebGates use agent/host specific cookies, which offers superior security. Oracle Access Manager 11g WebGates are all trusted at the same level; a cookie specific for the WebGate is set and cannot be used to access any other WebGate-protected applications on a user's behalf. Cookie-replay types of attacks are prevented.
SSO and SLO: The Oracle Access Manager 11g Server Session Token forms the basis for SSO between Oracle Access Manager and OSSO Agents. Logout is driven through Oracle Access Manager 11g Server Global Logout, which terminates the central session and logs out the user from each agent that was visited.
With Oracle Access Manager 10g WebGates, logout removes the ObSSOCookie and then redirects to the Global Logout page.
With Oracle Access Manager 11g WebGates and mod_osso agents, logout redirects to the Global Logout page and each agent is called back to remove the agent-specific cookie.
Logging and Auditing: Oracle Access Manager 11g components use the same logging infrastructure and guidelines as any other component in Oracle Fusion Middleware 11g. Oracle Access Manager 11g provides agent and server monitoring functions. Oracle Access Manager 11g auditing functions are based on the Common Audit Framework; audit-report generation is supported using Oracle Business Intelligence Publisher.
Access Tester: The new Oracle Access Manager 11g Access Tester enables IT professionals and administrators to simulate interactions between registered Oracle Access Manager Agents and Servers. This is useful when testing security policy definitions or troubleshooting issues involving agent connections.
Transition from Test to Production: Oracle Access Manager 11g enables moving configuration or policy data from one Oracle Access Manager 11g deployment to another (from a small test deployment to a production deployment, for example). Support for the creation of new topologies is based on templates. You can also copy and move policy changes.
Co-existence and Upgrades for OSSO 10g: The Oracle-provided Upgrade Assistant scans the existing OracleAS 10g SSO server configuration, accepts as input the 10g OSSO policy properties file and schema information, and transfers configured partner applications into the destination Oracle Access Manager 11g SSO.
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for an "Introduction to Post-Upgrade Co-existence Between Oracle Access Manager 11g and OSSO 10g Servers"
Oracle Fusion Middleware Upgrade Planning Guide
Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management
This topic is required for only 10g custom AccessGates. Skip this topic if it does not apply to your environment.
The Application Authenticator application domain is delivered with OAM 11g. It is pre-seeded with the policy objects that enables integration with applications deployed in WebLogic environments using the OAM Authentication Provider as the security provider. It is not associated with WebGate provisioning. When you provision a WebGate or AccessGate to use this (or another existing application domain), you will decline having policies created automatically.
The Application Authenticator application domain comes into play with the custom 10g AccessGate used with the OAM Authenticator (and the Identity Asserter for Oracle Web Services Manager). In this case, the custom AccessGate (not WebGate) contacts the WebLogic Server directly with a token to authenticate the user before OAM 11g is contacted.
The Application Authenticator application domain protects only resources of type wl_authen and is seeded with two authentication policies and one authorization policy. The following wl_authen resources are also seeded in this domain:
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion protected by LDAPNoPasswordValidationScheme
Note:
Only resources of type wl_authen are allowed in this domain; no other resource types can be added. Policies and Responses for wl_authen resources can be added. However, ideally, you will not need to modify this domain.
Figure 16-1 illustrates details of the seeded Application Authenticator application domain in the OAM 11g Administration Console. The page shown describes the pre-seeded User ID Assertion authentication policy, which protects the /Authen/UsernameAssertion resource. The authentication scheme for this policy is also shown along with the resources that are protected by the policy.
Figure 16-2 illustrates pre-seeded Responses for the User ID Assertion authentication policy. For more information about Responses, see the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
Figure 16-3 illustrates the pre-seeded Application SSO authentication policy, the resources protected by this policy, and the authentication scheme.
Figure 16-4 illustrates Pre-seeded Responses for the Application SSO authentication policy in the application domain.
Figure 16-5 illustrates the pre-seeded Application SSO authorization policy and Resources in the application domain.
Authorization Constraints: There are no pre-seeded Application SSO authorization policy Constraints in this application domain. However, you can add constraints as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
Authorization Responses: There are no pre-seeded Application SSO authorization policy Responses in the application domain. However, you can add responses as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
This section introduces how to implement OAM 11g with the Authentication Provider when you have applications that are (or will be) deployed in a WebLogic container.
This section provides the following topics to help you implement OAM 11g SSO when you have applications deployed in a WebLogic container. Aside from these uniquely OAM 11g methods, implementing OAM solutions are the same whether you have OAM 11g or OAM 10g:
Installing the Authentication Provider with Oracle Access Manager 11g
Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g
Configuring Identity Assertion for SSO with Oracle Access Manager 11g
Configuring the Authenticator Function for Oracle Access Manager 11g
Configuring Identity Assertion for Oracle Web Services Manager and OAM 11g
Configuring Centralized Log Out for Oracle Access Manager 11g
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for details about the scenario for Identity Propagation with the OAM Token.
The following overview outlines the tasks that must be completed to install the required components and files for the Oracle Access Manager 11g SSO solution using the Authentication Provider. While many of these tasks are nearly the same for Oracle Access Manager 11g and Oracle Access Manager 10g, there are a few differences.
See Also:
Oracle Fusion Middleware Installation Guide for Oracle Identity Management for installation and initial configuration details for Oracle Access Manager 11g.
Task overview: Installing components for use with the Authentication Provider and OAM 11g
Install and set up Oracle Internet Directory for Oracle Access Manager.
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.
Install OHS 11g for the Oracle Access Manager WebGate, if needed:
Identity Asserter: Requires Oracle HTTP Server 11g Web server configured as a reverse proxy in front of Oracle WebLogic Server.
WebGate: For identity assertion with the OAM Identity Asserter, a perimeter Webgate is required (installed and configured) on the OHS Web Server.
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.
Authentication Provider Files: Confirm the required JAR and WAR files as follows:
Confirm the location of required JAR files in the following Fusion Middleware path:
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.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
Oracle Access Manager 11g:
Install Oracle Access Manager and perform initial configuration as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Trusted Header Assertion: Go to My Oracle Support, retrieve Bundle Patch 02 (Oracle Access Manager Bundle Patch 11.1.1.5.2), and apply it as described in the companion readme file: http://support.oracle.com.
AccessGate for the Authenticator (or for Oracle Web Services Manager):
You can provision the 10g AccessGate as described in "Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g" (or refer to an existing OAM Agent registration when configuring the Authentication Provider).
Deploy the custom 10g AccessGate available in oamAuthnProvider.jar
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 OAM Server in Simple or Cert (certificate) mode.
Note:
This procedure is required regardless of the SSO mechanism you choose.
When communicating in Simple or Cert mode, the OAM 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 OAM 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 OAM 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 inOAMServer_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 OAM Server installation directory path. For example:
OAM_Server_HOME\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 16-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 OAM 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
This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header assertion or clear text header mechanism, skip this topic.
Provisioning is the process of registering an agent and creating an application domain to use OAM 11g authentication and authorization services.You must provision a WebGate with OAM 11g whether you are preparing to install a fresh 11g or 10g instance or you have a legacy 10g WebGate installed.
The term WebGate is used for WebGates (and for the custom 10g AccessGates used with the Authenticator and the Identity Asserter for Oracle Web Services Manager). Unless explicitly stated, topics apply equally to both.
When you have multiple agents, each one can be provisioned independently or you can use a single OAM Agent registration for multiple agents.
Note:
The Application Authenticator application domain is pre-seeded and delivered with OAM 11g. When you provision an OAM Agent to use this (or another existing) application domain, decline the option of having policies automatically created.
The following topics are provided:
This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header or clear text header mechanism, skip this topic.
Table 16-2 outlines the methods and tools you can use to provision WebGates for use with OAM 11g. The remote registration tool enables you to specify a small amount or all WebGate parameters using templates.
Table 16-2 Provisioning Methods for OAM 11g
| Method | Description |
|---|---|
|
Oracle Access Manager Administration Console |
Enables OAM Administrators to manually 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. |
|
Remote Registration |
Application administrators who are implementing the Identity Asserter for single sign-on, can register the WebGate using the command line. This also creates a new application domain with security policies for a fresh or existing Web Tier. Required parameters are provisioned using values for your environment specified in a template. Default values are accepted for non-required parameters. After registration, values can be modified in the Oracle Access Manager Console. |
During remote registration, you must provide the details discussed in Table 16-3.
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for a complete list of WebGate parameters
Table 16-3 Required Registration Details for OAM Agents
| OAM Agent Element | Description |
|---|---|
|
<serverAddress> |
Points to a running instance of the Oracle Access Manager Administration Console, including the host and port. |
|
<webDomain> OSSO requests only |
Defines the Web server domain under which the Agent Base URL is stored internally. |
|
<agentName> |
Defines a unique identifier for the agent on the OAM (Administration) Server. For every agent on the same server instance, this tag must be unique to avoid re-registering the same agent. Re-registering an agent on the same server instance is not supported. |
|
<hostIdentifier> |
This identifier represents the Web server host. The field is filled in automatically when you specify a value for the OAM Agent Name. If the agent name or host identifier of the same name already exists, an error occurs during registration. |
|
<protectedResourcesList> |
Specifies the resource URLs that you want the OAM Agent to protect with some authentication scheme. The resource URLs should be relative paths to the agentBaseUrl. |
|
<publicResourcesList> |
Specifies the resource URLs that you want to keep public (not protected by the OAM Agent). The resource URLs should be relative paths to the agentBaseUrl. For instance, you might want to specify the Home page or the Welcome page of your application |
This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header or clear text header mechanism, skip this topic.
Provisioning a WebGate or AccessGate involves the same steps. You can provision a new instance for use with the Authentication Provider or you can refer to an existing registration when configuring the provider.
In this example, an OAM 10g WebGate is provisioned using the OAMRequest_short.xml template. The registered agent is named my-wl-agent1, protecting /.../*, and declaring a public resource, /public/index.html. Your values will be different.
Note:
When provisioning an OAM 11g WebGate, use the OAM11gRequest_short.xml template.
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service
To provision a WebGate with OAM 11g
Acquire the Tool: On the computer to host the WebGate, acquire the remote registration tool and set up the script for your environment. For example:
Locate RREG.tar.gz file in the following path:
WLS_home/Middleware/domain_home/oam/server/rreg/client/RREG.tar.gz
Untar RREG.tar.gz file to any suitable location. For example: rreg/bin/oamreg.
In the oamreg script, set the following environment variables based on your situation (client side or server side) and information in Table 6–7 in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service:
Create the registration request:
Locate the *Request_short.xml file and copy it to a new location and name. For example:
WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/
Copy: OAMRequest_short.xml (or OAM 11gRequest.xml)
To: my-wl-agent1.xml
Edit my-wl-agent1.xml to include details for your environment, and set automatic policy creation to false. For example:
<OAMRegRequest>
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>my-wl</hostIdentifier>
<agentName>my-wl-agent1</agentName>
<primaryCookieDomain>.us.example.com</primaryCookieDomain>
<autoCreatePolicy>false</autoCreatePolicy>
<logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
</OAMRegRequest>
See Also:
"Creating the Registration Request" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service
Provision the agent. For example:
Locate the remote registration script.
chmod +x oamreg.shWindows: rreg\bin\oamreg.bat
From the directory containing the script, execute the script using inband mode. For example:
$ ./bin/oamreg.sh inband input/my-wl-agent1.xml
Welcome to OAM Remote Registration Tool! Parameters passed to the registration tool are: Mode: inband Filename: ...
When prompted, enter the following information using values for your environment:
Enter your agent username: userame Username: userame Enter agent password: ******** Do you want to enter a Webgate password?(y/n) n iv.Do you want to import an URIs file?(y/n) n
Review the final message to confirm that this was a successful registration:
Inband registration process completed successfully! Output artifacts are created in the output folder"
Confirm in the Console: Log in to the Oracle Access Manager Console and review the new registration:
From the OAM 11g Console System Configuration tab, Access Manager Settings section, expand the SSO Agents nodes to search for the agent you just provisioned:
In the Search Results table, click the agent's name to display the registration page and review the details, which you will use later. For example:
Agent Name—During WebGate installation, enter this as the WebGate ID. If you deploy the custom 10g AccessGate, enter this as the AccessGate Name when configuring the OAM Authentication Provider in the WebLogic Administration Console.
Access Client Password—During WebGate installation, enter this as the WebGate password. If no password was entered, you can leave the field blank.
Access Server Host Name—Enter the DNS host name for the primary OAM 11g Server with which this WebGate is registered.
OAM Proxy Port—From the Oracle Access Manager Console, System Configuration tab, Common Configuration section, open Server Instances and locate the port on which the OAM Proxy is running.
Ignore the Obaccessclient.xml file, which is created during provisioning, for now.
Proceed as needed for your environment:
Agent is Installed: Go to the appropriate topic for your implementation:
Agent is Not Installed:
11g WebGate: See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
10g WebGate: See Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
This section describes the unique steps needed to configure Oracle Access Manager 11g Identity Assertion for Single Sign-On with your application.
Task overview: Deploying the Identity Asserter for SSO with OAM 11g includes
Finishing all prerequisite tasks for the mechanism you are implementing:
Trusted Header Assertion: Configuring Digital Signature Verification
Configuring Centralized Log Out for Oracle Access Manager 11g
Synchronizing the User and SSO Sessions: SSO Synchronization Filter
Testing Oracle Access Manager Identity Assertion for Single Sign-on
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.
Task overview: Establishing Trust with Oracle WebLogic Server
Setting Up the Application Authentication Method for Identity Asserter for Single Sign-On
Confirming mod_weblogic for Oracle Access Manager Identity Asserter
Clear Text Header: 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.
You can add comma separated values here when you want applications accessed directly over the WebLogic Server host:port to be authenticated by the container. For instance: <auth-method>CLIENT-CERT,FORM</auth-method>.
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).
To specify authentication in web.xml for the Identity Asserter
Locate the web.xml file in the application EAR file:
my_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 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 Oracle Access Manager Identity Asserter
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 myHost.myDomain.com WebLogicPort myWlsPortNumber </IfModule> <Location http://request-uri-pattern> SetHandler weblogic-handler </Location>
Save the file.
Proceed as needed for your implementation:
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 filter is required for security when you use Identity Assertion with the Clear Text Header mechanism. This task is optional when you use one of the other mechanisms.
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 16-4 provides a description of each parameter in a connection filter.
Table 16-4 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 Oracle HTTP Server host
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 Providers in the WebLogic Domain".
The information here applies equally to OAM 11g and OAM 10g. 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 11g 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 uses token-based authentication; the Oracle Access Manager Identity Asserter is one example. This must be configured to use the appropriate action for the installed WebGate (either 10g or 11g).
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 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 16-5 defines the expected value for each argument in the addOAMSSOProvider command line.
Table 16-5 addOAMSSOProvider Command-line Arguments
| Argument | Definition |
|---|---|
|
loginuri |
Specifies the URI of the login page |
|
autologinuri |
Specifies the URI of the autologin page. |
|
logouturi |
Specifies the URI of the logout page |
See Also:
Oracle Fusion Middleware WebLogic Scripting Tool Command Reference "Infrastructure Security Commands" chapter
Prerequisites
Configuring Providers in the WebLogic Domain
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 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:
OAM Identity Asserter: REQUIRED (also specify a chosen Active Type for the mechanism you are using (Table 15-1))
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 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.
On the Common tab, specify one Chosen Active Type for your SSO mechanism (Table 15-1). For example:
OAM_IDENTITY_ASSERTIONSave the configuration.
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: Proceed as needed or your implementation.
Trusted Header Assertion: Configuring Digital Signature Verification
Testing Oracle Access Manager Identity Assertion for Single Sign-on
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 mentioned earlier, a login form shipped with 10g WebGate is used only with OAM 10g Access Server. For OAM 11g, neither the 10g WebGate nor 11g WebGate provide a login page.
Note:
The OAM 11g Server displays a login page. No set up is needed.
This is a manual task. The Oracle Access Manager certificate public key is required for digital signature verification. The certificate, which is consumed by the Identity Asserter, must be in the .oamkeystore.
For the SSO Sync Filter to consume the certificate, you need to provide the truststore to the filter. SSO Sync Filter behavior can be altered for application requirements by passing various over-riding system properties to WebLogic. To do this, you add a property in Oracle WebLogic startup script (setDomainEnv.sh) under EXTRA_JAVA_PROPERTIES. The truststore location can be provided as the system property. By default filter will look for keystore at ssofilter.jar location. If not found then it looks in system property.
The following procedure guides as you retrieve the .oamkeystore password required to perform export and import operations. After you export and import the required OAM certificate, you provision the keystore to enable the Identity Asserter to consume the certificate. Finally, you choose the OAM_IDENTITY_ASSERTION token type, provision the certificate in the SSO Sync Filter, and confirm that the authorization policy enables Identity Assertion.
To configure digital signature verification for trusted header assertion
Retrieve the .oamkeystore password using WLST script tool as follows:
Locate the WLST tool in your $MW_HOME/Oracle_IDM1/common/bin.
Execute wst.sh: $ ./wlst.sh.
Confirm execution with the following onscreen messages:
Initializing WebLogic Scripting Tool (WLST) ... Jython scans all the jar files it can find at first startup. Depending on the system, this process may take a few minutes to complete, and WLST may not return a prompt right away Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands
Execute wls:/offline> connect() and supply information for your environment (WebLogic Administrator username and password and AdminServer URL). For example:
Please enter your username: weblogic Please enter your password: password Please enter your server URL //localhost:7001 not return a prompt right away Connecting to ... Successfully connected to Admin Server 'AdminServer' ... domain 'base_domain'. Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead. wls:/base_domain/serverConfig
Execute wls:/base_domain/serverConfig> domainRuntime() and check the following onscreen messages. For example:
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root For more help, use help(domainRuntime) wls:/base_domain/domainRuntime>
Execute wls:/base_domain/domainRuntime> listCred(map="OAM_STORE",key="jks"). For example:
Already in Domain Runtime Tree
PASSWORD: lleoi4sbkpo3bj8fg55k7jgbgh
wls:/base_domain/domainRuntime>
Export the alias to a certificate file using the JDK6 keytool, as follows:
jdk/bin]$ keytool -exportcert -alias "assertion-cert" -keystore .oamkeystore
-storepass gtml6es9qderjc66f76hvtqm5a -storetype JCEKS -file assertion.cer
Import the certificate file using the JDK6 keytool, as follows:
Note:
The keystore alias oam.assertion.cert and the keystore name oamiap-keystore.jks are fixed. Use those names only.
jdk/bin $ keytool -importcert -trustcacerts -alias "oam.assertion.cert" -file
assertion.cer -keystore /scratch/oamiap-keystore.jks -storepass password
-storetype JKS
Provision the Identity Asserter keystore for consumption of the OAM certificate with the public key in oamiap-keystore.jks:
From the WebLogic Console, Security Realm, Identity Asserter entry, add the absolute path of oamiap-keystore.jks in the provider-specific configuration.
Select token type OAM_IDENTITY_ASSERTION in provider-specific configuration.
Save this configuration.
Provision .oamkeystore in the SSO Sync Filter, as follows:
By default, the filter looks for the keystore in the ssofilter.jar location. If not found there, the system property is checked.
Default configuration: Place the keystore file oamiap-keystore.jks in the same location as ssofilter.jar. For example: $MW_HOME/oracle_common/modules/oracle.ssofilter_11.1.1
Fallback Mechanism: Set the keystore file oamiap-keystore.jks as a systemproperty in setDomainEnv.sh ($MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh):
-Dsso.filter.oam.keystore=/scratch/keystore/oamiap-keystore.jks
Set System Properties for OAM_IDENTITY_ASSERTION, as follows:
Stop the WebLogic Server.
Open the file setDomainEnv.sh in $MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh
Add the following property under EXTRA_JAVA_PROPERTIES, and save the file:
-Dsso.filter.ssotoken=OAM_IDENTITY_ASSERTION
Start the WebLogic Server.
Proceed to "Trusted Header Assertion: Configuring Policies".
To use OAM_IDENTITY_ASSERTION as a token type for the assertion, the Identity Assertion option must be enabled within the authorization policy that protects the resources. Default policies are generated during agent registration. You can also create policies manually using the Oracle Access Manager Console.
Figure 16-6 provides an example of an authorization policy for the Trusted Header Assertion mechanism.
The following procedure provides the steps to enable Identity Assertion within the Oracle Access Manager 11g authorization policy that protects the resources.
To enable Identity Assertion for Trusted Header Assertion
From the Policy Configuration tab, navigation tree, open the following nodes:
Enable Identity Assertion (check the box).
Resources:
On the Resource tab, confirm the desired resources are protected by this policy.
Add or remove resources as needed.
Click Apply to save changes and close the Confirmation window.
Close the page when you finish.
Proceed with "Testing Oracle Access Manager Identity Assertion for Single Sign-on".
The following procedure describes how to test your Oracle Access Manager Identity Assertion setup, regardless of the mechanism you are using.
Alternatively, you can run Access Tester in Oracle Access Manager to test your policy domain, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
To validate Oracle Access Manager Identity Assertion for Single Sign-on
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".
With the Authenticator function, 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 and available in the pre-seeded application domain that is delivered with Oracle Access Manager 11g. It protects the following resources (resource type wl_authen):
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion
You can add Responses and Constraints to policies. However, no other configuration is needed.
For more information about the pre-seeded application domain, see "Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate".
Prerequisites
Installing the Authentication Provider with Oracle Access Manager 11g
Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g
Note:
You can provision the custom 10g AccessGate for the Authenticator or simply refer to an existing OAM Agent registration when configuring providers for the Authenticator.
Tasks to configure the Oracle Access Manager Authenticator are described in the following overview.
Task overview: Configuring the Authenticator function for OAM includes
Ensuring that all prerequisite tasks have been performed
Configuring Providers for the Authenticator in a WebLogic Domain
Configuring the Application Authentication Method for the Authenticator
Configuring Centralized Log Out for Oracle Access Manager 11g
Testing the Oracle Access Manager Authenticator Implementation
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 an 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 used by the Provider. This must match exactly the name of an OAM Agent registration in the Oracle Access Manager Console.
Note:
You can have one or more 10g OAM Agents registered with OAM 11g. Be sure to choose the correct Agent registration name.
Access Gate Password: The same password, if any, that is as defined for the Agent registration (see the Oracle Access Manager Console).
Primary Access Server: The host:port of the primary OAM Server that is associated with this AccessGate in the Oracle Access Manager Console.
Advanced Configuration: Following are several advanced configuration values.
Transport Security: The communication mode between OAM 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 OAM Server.
Key Store: The absolute path of JKS key store used for SSL communication between the provider and the OAM Server.
Key Store Pass Phrase: The password to access the key store.
Simple mode pass phrase: The password shared by AccessGate and OAM Server for simple communication modes.
Secondary OAM Server: The host:port of the secondary OAM Server that is associated with this AccessGate in the Oracle Access Manager Console.
Maximum OAM Server Connections in Pool: The maximum number of connections that the AccessGate opens to the OAM Server. The default value is 10.
Note:
The Maximum OAM Server Connections in Pool (or Minimum OAM Server Connections in Pool) settings in the WebLogic Administration Console are different from the Maximum (or Minimum) Connections specified in the Oracle Access Manager Console.
Minimum Access Server Connections in Pool: The minimum number of connections that the Authentication provider uses to send authentication requests to the OAM 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.
Configure centralized logout as described in "Configuring Centralized Log Out for Oracle Access Manager 11g" and then return here to perform "Testing the Oracle Access Manager Authenticator Implementation".
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 Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
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".
This section describes how to set up the Oracle Access Manager Identity Asserter to enable validation of the token when you have Oracle Web Services Manager protecting Web services.
As discussed earlier, the 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, which handles most SSO situations. The alternate mode uses the custom AccessGate in oamAuthnProvider.jar. In this case, and with the absence of the header, the Identity Asserter contacts the OAM Server to validate the token. For more information about the token, see "Installing the Authentication Provider with Oracle Access Manager 11g".
Note:
The 10g custom AccessGate provided with the Authentication Provider is required for Identity Assertion for Oracle Web Services Manager.
With OAM 10g, you would need to manually create the policy domain and policies for this configuration. However, with OAM 11g, a pre-seeded application domain is delivered with policies that protect the following resources (resource type wl_authen):
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion
You can add policies, Responses, or Constraints for resources of type wl_authen only. Ideally, however, you can use this application domain with no further configuration. For more information, see "Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate".
When the Oracle Access Manager Identity Asserter is configured for both header and token validation modes, preference is given to the presence of the header. If the header is not present, the Identity Asserter contacts the OAM Server to validate the token. For more information on the token, see "Oracle Access Manager Authentication Provider Parameter List".
Prerequisites
Installing the Authentication Provider with Oracle Access Manager 11g
Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g
Task overview: Deploying the Identity Asserter with Oracle Web Services Manager includes
Configuring Providers in a WebLogic Domain for Oracle Web Services Manager
Configuring Centralized Log Out for Oracle Access Manager 11g
Testing the Identity Asserter with 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 with OAM 11g. The difference in this case is that Oracle Web Services Manager requires the custom 10g AccessGate and additional provider-specific values:
Primary Access Server: Specify the primary OAM Server host and port. For example: mnop:8888
Access Gate Name: The name of the AccessGate registration protecting the application. For example: AG1
Access Gate Password: The AccessGate password as specified in the Oracle Access Manager 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 the Common tab, specify ObSSOCookie as the chosen Active Type for the 10g custom AccessGate, and click Save.
Click the Provider Specific tab and configure these parameters:
Primary Access Server: Specify the primary OAM Server host and port. For example: abcd:7777
Access Gate Name: The name of the OAM Agent registration protecting the application. For example: AG1
Access Gate Password: The AccessGate password, if any, that was specified in during provisioning.
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 "Configuring Centralized Log Out for Oracle Access Manager 11g", and then return here to perform "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 the Authentication Provider with Oracle Access Manager 11g".
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".
This section introduces Centralized logout for Oracle Access Manager 11g.
With OAM 11g, centralized logout refers to the process of terminating an active user session. Guidelines include:
Applications must not provide their own logout page for use in an SSO environment.
Applications must make their logout links configurable with a value that points to the logout URL specified by the OAM WebGate Administrator.
Note:
Oracle strongly recommends that applications use the ADF Authentication servlet, which in turn interfaces with OPSS, where a domain wide configuration parameter can be used to specify the logout URL. This way applications need not be modified or redeployed to change logout configuration.
For more information, see:
Several elements in the OAM 11g Agent registration page enable centralized logout for OAM 11g WebGates. After agent registration, the ObAccessClient.xml file is populated with the information.
11g WebGate logout options that you must have in the agent registration include the following:
Logout URL: Triggers the logout handler, which removes the cookie (ObSSOCookie for 10g WebGates; OAMAuthnCookie for 11g WebGates) and requires the user to re-authenticate the next time he accesses a resource protected by Oracle Access Manager.
Logout Callback URL: The URL to oam_logout_success, which clears cookies during the call back. This can be a URI format without host:port (recommended), where the OAM Server calls back on the host:port of the original resource request.
Logout Redirect URL: This parameter is automatically populated after agent registration completes.By default, this is based on the OAM Server host name with a default port of 14200.
Logout Target URL: The value for this is name for the query parameter that the OPSS applications passes to WebGate during logout. This query parameter specifies the target URL of the landing page after logout.
For more information, see "Configuring Centralized Logout for 11g WebGate with OAM 11g Server" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
Logout is initiated when an application causes the invocation of the logout.html file configured for the OAM Agent (in this case, a 10g WebGate). The application might also pass end_url as a query string to logout.html. The end_url parameter could either be a URI or a URL.
See Also:
Task overview: Configuring centralized logout for 10g WebGates
Create a default logout page (logout.html) and make it available on the WebGate installation directory: For example, WebGate_install_dir/oamsso/logout.html.
In your logout.html, confirm that the logOutUrls parameter is configured for each resource WebGate and that <callBackUri> is the second value as part of 'logOutUrls'.
In your logout.html, confirm (from Step 1), confirm that the user is redirected to the central logout URI on the OAM 11g Server, "/oam/server/logout'.
Optional: Allow the application to pass the end_url parameter indicating where to redirect the user after logout.
Check the OHS Web server configuration file, httpd.conf, on which the 10g WebGate is configured and if the following lines exist delete them.
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
For more information, see "Configuring Centralized Logout for 10g WebGate with OAM 11g Servers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
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.
Configured for the Oracle Access Manager SSO Tokens/Header: OAM_IDENTITY_ASSERTION, a case insensitive match. For details, see "Trusted Header Assertion: Configuring Digital Signature Verification".
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 16-6.
Table 16-6 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".
For more information, see "Troubleshooting" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
|
 Copyright © 2003, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|