| Oracle® Fusion Middleware Security Guide 11g Release 1 (11.1.1) E10043-04 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Security Guide 11g Release 1 (11.1.1) E10043-04 |
|
Previous |
Next |
The chapter outlines a set of recommended single sign-on solutions for Oracle Fusion Middleware. It also provides some general guidelines and common use cases for configuring authentication and single sign-on in the Oracle Fusion Middleware environment. This chapter includes the following major sections:
Oracle Platform Security Services comprise Oracle WebLogic Server's internal security framework. A WebLogic domain uses a separate software component called an Authentication provider to store, transport, and provide access to security data. Authentication providers can use different types of systems to store security data. The Authentication provider that WebLogic Server installs uses an embedded LDAP server.
Oracle Fusion Middleware 11g supports two new single sign-on solutions that applications can use to establish and enforce perimeter authentication:
Security-enabled components, such as Oracle Service Oriented Architecture (SOA) and Oracle WebCenter, can choose either solution (Oracle Access Manager 10g or OracleAS Single Sign-On 10g). Customers using a mixed product stack must carefully choose the solution appropriate to their needs. Selecting the right SSO solution requires careful consideration and depends upon your requirements. This section outlines some general information and guidelines to help you choose the best solution for your needs.
|
See Also: Oracle Fusion Middleware Security Overview |
Development or Small Stand-Alone Environment: Oracle recommends a light-weight SSO solution when deployed applications are not integrated into an enterprise-level single sign-on framework.
In such cases, a SAML-based solution that uses the Oracle WebLogic Server SAML Credential Mapping Provider is best. The embedded LDAP server is used as the default user repository. Alternatively, an LDAP Authenticator can be configured to leverage an external LDAP server as a user repository.
|
See Also: "Configuring Single Sign-On with Web Browsers and HTTP Clients" in Oracle Fusion Middleware Securing Oracle WebLogic Server |
Enterprise-Level SSO with Oracle Fusion Middleware 11g: Oracle recommends Oracle Access Manager because it supports:
A wide variety of LDAP vendors as the user and group repository and also works with Oracle Virtual Directory
Integration with non-Oracle application server vendors and Web Tier components on a large number of OS platforms to provide a flexible solution.
Oracle Access Manager is the recommended choice whether you are new to Oracle Fusion Middleware, or you are considering an enterprise-level SSO solution, or you already have Oracle Access Manager in your environment.
Existing OSSO 10g Customers: Oracle Single Sign-On is part of the 10g Oracle Application Server suite. OSSO is an enterprise-level single sign-on solution that works in conjunction with Oracle Internet Directory and Oracle HTTP Server 11g.
If OSSO is already in place as the enterprise solution for your existing Oracle deployment, Oracle Fusion Middleware continues to support the existing OSSO as a solution.
|
See Also: Oracle Application Server Single Sign-On Administrator's Guide 10g (10.1.4.0.1) on Oracle Technology Network at:http://www.oracle.com/technology/documentation/oim1014.html |
Portal, Forms, Reports, and Discoverer 11g : In 10g these components relied on Oracle Single Sign-On as the SSO solution, and they continue to do so in 11g. OSSO 10g, along with Oracle Delegated Administration Services 10g, are mandatory for these components. Oracle Internet Directory 10g or 11g are also mandatory for these components.
|
See Also: The following topic in this chapter and other 11g Release 1 (11.1.1) manuals:
|
Oracle Access Manager Integration with OSSO: Oracle Access Manager is the recommended enterprise-wide solution. If applications mandating OracleAS Single Sign-On (Oracle Portal for example) are deployed, it is possible to delegate the authentication from OracleAS Single Sign-On (OSSO) to Oracle Access Manager. When integrating Oracle Access Manager's authorization functionality, either Oracle Access Manager or OSSO can act as the authentication engine. Such an integration also requires Oracle Internet Directory for the applications that require integrating Oracle Access Manager and OSSO
|
See Also: "Integrating with Oracle Application Servers" in the 10g (10.1.4.3) Oracle Access Manager Integration Guide. |
Windows Native Authentication for Microsoft Clients: Oracle WebLogic Server can be configured to use the Simple and Protected Negotiate (SPNEGO) mechanism for authentication to provide Windows Native Authentication support.
|
See Also: "Configuring Single Sign-On with Microsoft Clients" in Oracle Fusion Middleware Securing Oracle WebLogic Server |
Oracle Access Manager is part of Oracle's enterprise class suite of products for identity management and security. Oracle Access Manager provides a wide range of identity administration and security functions, including a single sign-on solution.
The Oracle Access Manager Authentication provider is a new component that works with Oracle WebLogic Server. An application can use either or both of the Oracle Access Manager Authentication provider features, each of which enables a specific Oracle Access Manager function for WebLogic users:
Identity Asserter for Single Sign-on
This function uses Oracle Access Manager authentication services and also validates already-authenticated Oracle Access Manager users through the ObSSOCookie and creates a WebLogic-authenticated session. It also provides single sign-on between WebGates and portals.
|
Note: Oracle Web Services Manager uses the Identity Asserter for single sign-on. |
This function uses Oracle Access Manager authentication services to authenticate users who access applications deployed in WebLogic Server. Users are authenticated based on their credentials, such as a user name and password.
The information in this section presumes that you are familiar with Oracle WebLogic Server and with Oracle Access Manager. For general details about configuring and managing Oracle Access Manager, see the Oracle Access Manager Identity and Common Administration Guide and the Oracle Access Manager System Administration Guide.
The rest of this section is organized as follows:
Scenarios for Applications with the Oracle Access Manager Authentication Provider explains how an application can use Oracle Access Manager Authentication provider features according to the current application setup.
Uses of the Authentication Provider for Oracle Access Manager describes the two provider features: authentication and single sign-on.
Configuring Oracle Access Manager Identity Assertion for Single Sign-On provides the procedures that you must perform to set up the provider for single sign-on.
Configuring the Oracle Access Manager Authenticator provides the procedures that you must perform to set up the provider for authentication.
Configuring Identity Assertion for Oracle Web Services Manager explains the procedures that you must perform to set up this scenario.
Troubleshooting Tips for Provider Deployment describes how to detect and correct issues with your implementation of the Oracle Access Manager Authentication provider.
This section explains how an application can use Oracle Access Manager and the companion Authentication provider according to the current application setup:
Applications Migrating from Oracle Application Server to Oracle WebLogic Server
Applications Using Oracle Access Manager Security Provider for WebLogic SSPI
If your application is to use Oracle Access Manager Authentication provider for the first time, proceed based on the functionality that you want to use:
Identity Asserter for Single Sign-On: Review "About Using Oracle Access Manager Identity Asserter for Single Sign-on".
|
Note: The Identity Asserter is also used when you have Oracle Web Services Manager protecting Web services. |
Authenticator: Review "About Using the Oracle Access Manager Authenticator".
If your application has been deployed on the old Oracle Application Server (OC4J), to have the application use the Oracle Access Manager Authentication provider feature with Oracle WebLogic Server, proceed as follows:
Remove all OC4J-specific settings from the application configuration.
Identity Asserter for Single Sign-On: Review "About Using Oracle Access Manager Identity Asserter for Single Sign-on".
|
Note: The Identity Asserter is also used when you have Oracle Web Services Manager protecting Web services. |
Authenticator: Review "About Using the Oracle Access Manager Authenticator".
|
See Also: Oracle Fusion Middleware Upgrade Guide for Java EE for information about upgrading your Java EE applications from Oracle Containers for Java EE (OC4J) 10g Release 3 (10.1.3) to Oracle WebLogic Server |
The 10g (10.1.4.2.0) or earlier Oracle Access Manager Security Provider for WebLogic SSPI provides authentication, authorization, and single sign-on across J2EE applications that are deployed in the WebLogic platform. The Security Provider for WebLogic SSPI enables WebLogic administrators to use Oracle Access Manager 10g (10.1.4.2.0) to control user access to business applications.
|
Note: Security Provider for WebLogic SSPI is also known as "Security Provider" in the Oracle Access Manager Integration Guide for release 10g (10.1.4.2.0). |
The 10g (10.1.4.2.0) or earlier Oracle Access Manager Security Provider for WebLogic SSPI provides authentication to Oracle WebLogic Portal resources and supports single sign-on between Oracle Access Manager and Oracle WebLogic Portal Web applications. Apart from this, the Security Provider for WebLogic SSPI also offers user and group management functions.
The 10g (10.1.4.3) Oracle Access Manager Authentication provider is more easily installed and configured than the 10g (10.1.4.2.0) Security Provider for WebLogic SSPI. The 10g (10.1.4.3) Authentication provider works with all platforms supported by Oracle WebLogic Server. However, the 10g (10.1.4.3) Authentication provider offers just two services: authentication and single sign-on (SSO).
If your application has been using the 10g (10.1.4.2.0) or earlier Oracle Access Manager Security Provider for WebLogic SSPI for only authentication and SSO, the deployment is a good candidate for the latest Authentication provider when this implementation is certified. Oracle continues to certify the 10g (10.1.4.3) Oracle Access Manager Authentication provider with earlier WebLogic Server releases. Be sure to check the latest certification matrix for more information. However, if your application relies on features other than those offered by the latest Oracle Access Manager Authentication provider, you should continue to use the Oracle Access Manager Security Provider for WebLogic SSPI.
Applications can use the Authentication provider for Oracle Access Manager for authentication or single sign-on (or both). This section outlines the common components required by these functions as well as how these work:
Regardless of the functionality you intend to use (Authentication or Identity Assertion for single sign-on), a number of components and files are required. The following list provides a brief overview of the required components and files:
An enterprise directory server (Oracle Internet Directory or Sun One directory server is used by the Oracle Access Manager Access Server and Oracle WebLogic Server.
Oracle WebLogic Server 10.3.1 to be configured to use the Oracle Access Manager Authentication provider as described later in this chapter.
Optional: A Fusion Middleware product (Oracle Identity Manager, Oracle SOA Suite, or Oracle Web Center for example) includes the Oracle Access Manager Authentication provider and OAMCfgTool JAR files.
Authentication provider for Oracle Access Manager jar files are available when you install an Oracle Fusion Middleware product (Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter).
|
Note: If you have a stand-alone Oracle WebLogic Server with no Oracle Fusion Middleware application, you obtain the JAR files as described in procedures later in this chapter: |
oamAuthnProvider.jar: Includes files for both the Oracle Access Manager Identity Asserter for single sign-on and the Authenticator for Oracle WebLogic Server 10.3.1. A custom Oracle Access Manager AccessGate is also provided to process requests for Web and non-Web resources (non-HTTP) from users or applications.
oamcfgtool.jar: Provides the platform-agnostic OAMCfgTool and scripts that automate creation of the Oracle Access Manager form-based authentication scheme, policy domain, access policies, and WebGate profile for the Identity Asserter for single sign-on. OAMCfgTool requires JRE 1.5 or 1.6.
OHS 11g must be configured as a reverse proxy for the 10g (10.1.4.3) WebGate required by the Oracle Access Manager Identity Asserter
Oracle Access Manager 10g (10.1.4.3) components:
Identity Server
WebPass
Policy Manager
Access Server
WebGate (use for Identity Assertion for single sign-on only)
WebGate is Web server plug-in access client that intercepts HTTP requests for Web resources and forwards them to the Access Server for authentication and authorization.
AccessGate (use with the Authenticator or when you have Oracle Web Services Manager protecting Web services)
The custom AccessGate is available in oamAuthnProvider.jar. No Web server is required for this component.
This topic describes and illustrates the use of the Oracle Access Manager Identity Asserter for single sign-on.
The Authentication provider for Oracle Access Manager can be configured as the Identity Asserter for single sign-on. In this case, the provider protects Web resources only.
This Identity Asserter for single sign-on uses perimeter authentication performed by WebGate on the Web Tier and the ObSSOCookie to assert the identity of users who try to access protected WebLogic resources.
All requests are routed to a reverse proxy Web Server; requests are intercepted by WebGate. The user is challenged for credentials based on the authentication scheme that is configured within Oracle Access Manager. The recommended scheme is Form (form-based login).
If authentication succeeds, WebGate generates an ObSSOCookie, the Web server mod_weblogic module forwards the request to Oracle WebLogic Server, which, in turn, invokes Oracle Access Manager Identity Asserter for single sign-on (with the request and the cookie) for validation.
|
Note: The user is challenged for credentials based on the authentication scheme that is configured within Oracle Access Manager. You can set up this scheme using OAMCfgTool, as described later.In text, 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 Security Service invokes Oracle Access Manager Identity Asserter for single sign-on, which gets the ObSSOCookie from the incoming request, and populates the subject with WLSUserImpl principal. The Identity Asserter for single sign-on also adds the WLSGroupImpl principal that corresponds to the user's groups, if any. Oracle Access Manager validates the cookie.
Figure 10-1 illustrates the distribution of components and the flow of information when Oracle Access Manager Identity Asserter for single sign-on is configured with Oracle Fusion Middleware. A detailed description follows the figure.
Figure 10-1 Oracle Access Manager Single Sign-On Solution for Web Resources Only
The following process overview describes the processing that occurs between components when the Identity Asserter for single sign-on is used with Web-only applications. This implementation handles nearly all SSO use cases. The exception is when you have Oracle Web Services Manager protected Web services. In this case, there is no trusted WebGate. Instead the AccessGate provided with the Identity Asserter is contacted and interacts with the Access Server; all other processing is essentially the same.
|
Note: The Identity Asserter for single sign-on processing is the same whether the implementation relies on a trusted WebGate or the custom AccessGate provided in oamAuthnProvider.jar. |
Process overview: Oracle Access Manager Identity Asserter with Web-only applications
A user attempts to access an Oracle Access Manager protected Web application that is deployed on the Oracle WebLogic Server.
WebGate on a reverse proxy Web server intercepts the request and queries the Oracle Access Manager Access Server to check if the requested resource is protected.
If the requested resource is protected, WebGate challenges the user for credentials based on the type of Oracle Access Manager authentication scheme configured for the resource (Oracle recommends Form Login). The user presents credentials such as user name and password.
WebGate forwards the authentication request to the Access Server.
Access Server validates the user credentials against those stored in user directory and returns the response back to WebGate. Processing continues based on:
Successful Authentication: Processing continues with Step 6.
Authentication Not Successful: The login form appears asking the user for credentials again; no error is reported.
Access Server generates the session token and sends it to the WebGate. WebGate sets the ObSSOCookie and value as that returned from Access Server. The Web server forwards this request to the proxy, which in turn forwards the request to the Oracle WebLogic Server using the mod_weblogic plug-in.
mod_weblogic forwards requests as directed by its configuration.
WebLogic Server security service invokes the Oracle Access Manager Identity Asserter for single sign-on which is configured to accept the tokens of type "ObSSOCookie". The Identity Asserter initializes a CallbackHandler with the ObSSOCookie. In addition, the Identity Asserter sets up NameCallback with the username for downstream LoginModules.
Oracle WebLogic Security service authorizes the user and allows access to the requested resource.
A response is sent back to the reverse proxy Web server.
A response is sent back to the browser.
|
See Also: Set up details for the implementation you need in: |
This topic describes and illustrates use of the Oracle Access Manager Authenticator.
Oracle Access Manager can be configured to protect access to Web and non-Web resources and to use the Authentication provider as the Authenticator.
|
Note: The Authenticator function does not provide single sign-on. |
When a user attempts to access a protected resource, the Oracle WebLogic Server challenges the user for credentials according to the authentication method specified in the application's web.xml file. Oracle WebLogic Server then invokes the Authentication provider, which passes the credentials to Oracle Access Manager Access Server for validation through the enterprise directory server.
|
Note: As the authenticator, the Authentication provider requests credentials from the user based on the authentication method specified in the application configuration fileweb.xml, not according to the Oracle Access Manager authentication scheme. |
Figure 10-2 illustrates the distribution of components and flow of information for Oracle Access Manager authentication for Web and non-Web resources. Details follow the figure. Standard Oracle Access Manager Identity System (Identity Server and WebPass), Policy Manager, and WebGate components are present but not illustrated because the Authenticator communicates with the Access Server through a custom AccessGate.
Figure 10-2 Oracle Access Manager Authentication for Web and non-Web Resources
Process overview: Oracle Access Manager Authenticator for Web and non-Web Resources
A user attempts to access a J2EE application (secured with the authentication mechanism in the application's web.xml file) that is deployed on the Oracle WebLogic Server.
Oracle WebLogic Server intercepts the request.
Oracle Access Manager Authentication provider LoginModule is invoked by the Oracle WebLogic security service. The LoginModule uses the NAP library to communicate with the Access Server and validate the user credentials.
If the user identity is authenticated successfully, WLSUserImpl and WLSGroupImpl principals are populated in the Subject.
If Oracle Access Manager LoginModule fails to authenticate the identity of the user, it returns a LoginException (authentication failure) and the user is not allowed to access the Oracle WebLogic resource.
Oracle Access Manager Authenticator supports Oracle WebLogic Server UserNameAssertion.
Oracle Access Manager Authenticator can be used with any Identity Asserter. In this case, the Oracle Access Manager Authenticator performs user name resolution and gets the roles and groups associated with the user name.
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:
This topic provides a brief installation and setup overview if you are new to Oracle Access Manager.
Identity System: The Identity System consists of at least one Identity Server and one WebPass. After installing at least one Identity Server and one WebPass, you must set up the Identity System. During Identity System setup, you specify a Master Administrator (the highest level administrator). A Master Administrator can specify other Master and Delegated Administrators for Identity and Access Systems.
Policy Manager: After Identity System setup, you can install and set up a Policy Manager. During Policy Manager setup, ensure that the default policy protecting the Policy Manager, /access, is created and enabled.
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 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
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.
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:
|
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 Authentication Provider
An Oracle Internet Directory or 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), and 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
|
Note: With a stand-alone Oracle WebLogic Server with no Fusion Middleware application, you obtain and store the JAR files as described when you perform tasks later in this chapter. |
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.
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:
Create Resource Types: "Creating Resource Types in Oracle Access Manager" 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 Oracle Access Manager Identity Assertion for Single Sign-On".
Authenticator: Perform tasks in "Configuring the Oracle Access Manager Authenticator ".
Oracle Web Services Manager: Perform tasks in "Configuring Identity Assertion for Oracle Web Services Manager".
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. 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
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 Oracle Access Manager Authenticator "
Oracle Web Services Manager: "Configuring Identity Assertion for Oracle Web Services Manager"
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 Required Components for Oracle Access Manager Providers" should be performed, including:
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 Oracle Access Manager Identity Asserter
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:
Setting Up the Application Authentication Method for Identity Asserter for Single Sign-On
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.
|
See Also: Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server |
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).
To specify authentication in web.xml for the Oracle Access Manager Identity Asserter
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 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 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. In the WebLogic Administration Console |
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 10-12 provides a description of each parameter in a connection filter.
Table 10-1 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".
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.
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.
For more information, see:
This topic introduces OAMCfgTool, which can be used only if you are deploying the Oracle Access Manager 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. 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
Unless you specify an LDIF output file, configuration changes are written directly in the LDAP directory server that is configured with Oracle Access Manager. 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. Without an LDIF file, Oracle Access Manager cache flush is triggered so that changes are implemented immediately.
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.
Table 10-2 provides both required and optional OAMCfgTool parameters and values for CREATE mode. You can specify multiple parameters at one time. See also, "Known Issues: JAR Files and OAMCfgTool".
|
Note:
|
Table 10-2 OAMCfgTool CREATE Mode Parameters and Values
| Parameters | CREATE Mode Values |
|---|---|
|
Required Parameters |
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. |
|
app_agent_password |
Password to be provisioned for the WebGate. In the AccessGate Profile within the 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. |
|
ldap_host |
DNS name of the computer hosting the LDAP directory server for Oracle Access Manager 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. |
|
oam_aaa_host |
DNS name of the computer hosting an accessible Access Server. OAMCfgTool does not recognize primary and secondary Access Server designations. Set up the WebGate profile with a single accessible Access Server. Oracle Access Manager can later associate the profile with designated Access Servers. |
|
oam_aaa_port |
Listening port on the accessible Access Server |
|
Optional |
Values |
|
-help |
Provides a list of parameters and descriptions. |
|
web_domain |
Fresh Web Tier: Omit web_domain to create a new WebGate profile. The profile is populated with a WebGate name, Host name, and Preferred HTTP host all using the same app_domain value as follows:
Existing Web Tier: Include web_domain to specify the name of an existing host identifier in Oracle Access Manager to tie new policies to an existing host ID. For example: web_domain=existing_host_Identifier When WebGate intercepts a request, it checks the request for an address. If the address is on the host identifiers list, this address is mapped to the official host name, and the Access System can apply the rules and policies that protect the resource. If virtual Web hosting is supported, you supply a reserved name in the Preferred HTTP Host field instead of a host name variation. For more information, see Oracle Access Manager System 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 identity public URIs by providing a comma separated list: "uri1,uri2,uri3", for example. The default URL pattern that is part of the URIs is created: /.../public/.../. For example "uri1,uri2,uri3" creates 3 public URLs which include "/.../public/.../" as a default URL pattern. Users can log in to Policy Manager and change the URL patterns, if needed. |
|
ldap_base |
Base from which all LDAP searches are performed. Note: If Oracle Access Manager user data and configuration data are stored in different directory servers, the following information is required for each:
|
|
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. |
|
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). |
|
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. |
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 10-3 provides both required and optional OAMCfgTool parameters and values for VALIDATE mode.
Table 10-3 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. |
|
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 |
|
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. Note: If Oracle Access Manager user data and configuration data are stored in different directory servers, the following information is required for each:
|
|
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). |
This topic describes the processing that occurs when you use OAMCfgTool with various parameters and values for your environment.
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. If no existing access policy uses this host identifier, a new policy is set up.
|
Note: In a fresh Web Tier the web_domain parameter should be omitted in CREATE mode to create new WebGate profile. In this case, as described in Table 10-2:
|
The protected_uris parameter defines application-specific URL's to protect HTTP resources using the host identifier (or the new WebGate/AccessGate profile created in Step 2).
The public_uris parameter creates a Public_URI_Policy to unprotect certain URIs for http resources (GET and POST operations) in app_domain name.
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 10-2
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
This topic describes and illustrates the results of running OAMCfgTool when viewed in Oracle Access Manager:
My Policy Domains
Policy Domain, General Tab
Figure 10-3 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 10-3 Sample OAMCfgTool Policy Domain General Tab
Policy Domain, Resources Tab
Figure 10-4 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 10-4 Sample OAMCfgTool Policy Domain Resources Tab
Policy Domain, Authorization Rules Tab
Figure 10-5 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 10-5 Sample OAMCfgTool Policy Domain Authorization Rules Tab
Policy Domain, Default Rules Tab
Figure 10-6 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 10-6 Sample OAMCfgTool Policy Domain Default Rules Tab
Policy Domain, Policies Tab
Figure 10-7 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 10-7 Sample OAMCfgTool Policy Domain Policies Tab
Policy Domain, Delegated Access Admins Tab
Figure 10-8 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 10-8 OAMCfgTool Policy Domain Delegated Access Admins Tab
|
See Also: "Protecting Resources with Policy Domains" in the Oracle Access Manager System 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 10-9 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 10-9 Sample OAMCfgTool Host Identifiers
AccessGate Profile
Figure 10-10 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 10-10 Sample OAMCfgTool AccessGate 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
Applications Deployed on a Stand Alone WebLogic Server: Obtain OAMCfgTool, as follows.
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:
|
Create a WebGate Profile, Authentication Scheme, and Policy Domain: Run the following command using values for your environment as described in Table 10-2. For example:
java -jar oamcfgtool.jar mode=CREATE app_domain=IASSO_App1 protected_uris=/myapp/login 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 : 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 10-3). For example:
java -jar oamcfgtool.jar mode=VALIDATE app_domain=IASSO_App1 protected_uris=/myapp/login ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin ldap_userpassword=<ldap_userpassword> oam_aaa_host=abcd oam_aaa_port=7789 log_file=OAMCfg_date.log log_level=INFO test_username=gcf test_userpassword=<test_userpassword>
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 System 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 System 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 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 10-4 defines the expected value for each argument in the addOAMSSOProvider command line.
Table 10-4 addOAMSSOProvider Command-line Arguments
| Argument | Definition |
|---|---|
|
loginuri |
Specifies the URI of the login page |
|
logouturi |
Specifies the URI of the logout page Note: For ADF security enabled applications, the logouturi value should be empty (or the word |
|
autologinuri |
Specifies the URI of the autologin page |
|
See Also:
|
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=None, 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: If you have 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
Applications Deployed on a Stand Alone WebLogic Server: 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
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 Oracle Access Manager Identity Asserter".
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 "Required Components and Files".
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 10-11 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 10-11 Default Login Form for Single Sign-On
|
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" <LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
The following procedure guides as you set up the login form for your environment.
To set up the login form for Oracle Access Manager Identity Assertion
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 "Testing Oracle Access Manager Identity Assertion for Single Sign-on".
The following procedure describes how to test your Oracle Access Manager Identity Assertion setup.
Alternatively, you can run Access Tester in Oracle Access Manager to test your policy domain, as described in the Oracle Access Manager System Administration Guide.
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 for Provider Deployment".
Proceed to "Configuring Global Logout for Oracle Access Manager".
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 Required Components for Oracle Access Manager Providers" must be completed:
Installing Components and Files which includes manually creating AccessGate profiles in the Access System Console and accepting defaults during Policy Manager setup
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.
|
Note: You must perform this task in the Access System Console of Oracle Access Manager. You cannot use OAMCfgTool for this task. |
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.
This topic is divided as follows:
Each policy domain in Oracle Access Manager must include at least one authentication rule that includes one Oracle Access Manager authentication scheme and authentication actions. The Oracle Access Manager Authenticator performs two functions: credential authentication and role-fetching based on the username.
As you create the Oracle Access Manager authentication scheme, you give this scheme a unique name and optional description. The level of the scheme is a number that corresponds to the relative security level for this scheme. Higher levels are considered more secure.
The Oracle Access Manager Authenticator performs two functions: credential authentication and role-fetching based on the username. With the Authenticator, the scheme's challenge method is specified as None, with no challenge parameters. However, each scheme includes one or more steps, each of which can include one or more plug-ins that perform part of the authentication process. A single-step scheme, or a multi-step (chained) scheme, requires an authentication flow.
For more information about authentication schemes, see the chapter on configuring user authentication in the Oracle Access Manager System Administration Guide.
You can use the following procedure to create an authentication scheme in the Access System Console.
To create an authentication scheme for the Oracle Access Manager Authenticator
From the Access System Console, click Access System Configuration, Authentication Management, Add.
Create the authentication scheme for the policy domain used by the Authenticator, as follows:
General tab: Enter and Save the following information for use with Authenticator.
Name: Username Resolution
Description: AuthN Scheme for the Authenticator
Level: 1
Challenge Method: None
Challenge Parameter:
SSL Required: No
Challenge Redirect: (Leave blank)
Enabled: (Leave as is)
Plugins tab: Use the credential_mapping plug-in from existing Oracle Access Manager authentication schemes.
Table 10-5 Plug-ins for the Authentication Scheme
| Plug-in Name | Plugi-in Parameters |
|---|---|
|
credential_mapping |
obMappingBase="o=company,c=us",obMappingFilter="(&(&(ob jectclass=inetOrgPerson)(uid=%userid%))(|(!(obuseraccou ntcontrol=*))(obuseraccountcontrol=ACTIVATED)))" |
obMappingBase: The base DN in the user search in the LDAP directory server.
obMappingFilter: The LDAP filter used to search for a user with a given userID. The directory login attribute is an attribute defined in the Identity System using a Semantic login type.
|
Note: No spaces are allowed in the filter. The Policy Manager does not validate the credential_mapping filter string. If you make a mistake and enter an erroneous filter, no error occurs while saving. However, the filter can fail and the plug-in returns "Authentication Failed" each time it is run. |
After you create at least one plug-in, default steps and a default authentication flow are created automatically.
Enable the authentication scheme: Click the General tab, click Modify; beside Enable, click Yes, and then click Save.
Restart the Access Server.
Proceed to "Creating a Policy Domain and Access Policies for the Authenticator".
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 10-12.
Figure 10-12 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.
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 System Administration Guide:
|
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"
Request user credentials using the Oracle Access Manager authentication scheme created earlier. See also, "Creating an Authentication Scheme in Oracle Access Manager".
|
Note: The Authenticator requires the BASIC authentication method defined in the applicationweb.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.
|
Note: The Authenticator does not perform authorization. Therefore 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.
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 System 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: If you have an Oracle Fusion Middleware application installed, you can skip Step 1. |
To configure providers for the Oracle Access Manager Authenticator in a WebLogic domain
Applications Deployed on a Stand Alone WebLogic Server: Obtain the Oracle Access Manager provider as follows.
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.
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 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).
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.
|
See Also: Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server |
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.
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 System 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 Provider Deployment"
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 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 a Policy Domain for Use with Oracle Web Services Manager
Configuring Oracle Web Services Manager Policies for Web Services
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"
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 System 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 Attributeuid 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 System 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 Oracle Web Services Manager Policies for Web Services".
This section provides an overview of configuring Oracle Web Services Manager policies to protect Web services.
To use the Identity Asserter with Oracle Web Services Manager, you must set up a Web service with the oracle/wss_oam_token_service_policy and a corresponding client with the oracle/wss_oam_token_client_policy in Oracle Web Services Manager.
About oracle/wss_oam_token_service_policy
This Oracle Web Services Manager policy contains the policy assertion oracle/wss_oam_token_service_template. This template uses the credentials in the WS-Security header's binary security token to authenticate users against the Oracle Access Manager identity store.
The Oracle Access Manager Identity Asserter uses the ObSSOCookie token to assert the identity of users who try to access a Web service protected by the oracle/wss_oam_token_service_policy policy. A Web service that is protected by this policy must be presented with an ObSSOCookie token in a SOAP header. That is, the Web service consumes the ObSSOCookie token; it is not involved in how the token is generated. Specifically, the WebLogic Server security service detects the token type and invokes the Oracle Access Manager Identity Asserter. The Oracle Access Manager Identity Asserter then validates the ObSSOCookie token against the Oracle Access Manager Access Server and obtains the username. The username is populated as the principal in the authenticated subject.
The Web service client, for example the Web application, must obtain the ObSSOCookie token to send it to the Web service. This is typically done using an AccessGate. AccessGate challenges the Web service client user for credentials (depending on the authentication scheme configured in Oracle Access Manager) and authenticates the user. The WebGate sends the ObSSOCookie to the user's browser upon successful authentication
The Web service client then sends the ObSSOCookie token in the SOAP request to the Web service.
|
Note: Settings for thewss_oam_token_service_template are identical to the client version of the assertion: wss_oam_token_client_template. Identity store configuration for the service template is identical to the client version of the assertion. |
About oracle/wss_oam_token_client_policy
This Oracle Web Services Manager policy contains the following policy assertion: oracle/wss_oam_token_client_template. This template inserts Oracle Access Manager credentials into the WS-Security header as part of the binary security token.
oracle/wss_oam_token_client_policy is the analogous client policy to the oracle/wss_oam_token_service_policy service endpoint policy. This policy can be enforced on any SOAP-based endpoint.
The following task overview outlines the procedures you must perform.
Task overview: Setting policies in Oracle Web Services Manager
Using Oracle Web Services Manager, set up a Web service with the oracle/wss_oam_token_service_policy policy.
Using Oracle Web Services Manager, set up a corresponding client for the Web service with the oracle/wss_oam_token_client_policy policy.
Configuring Providers in a WebLogic Domain for Oracle Web Services Manager.
|
See Also:
|
To use Oracle Access Manager Identity Asserter with Oracle Web Services Manager protected Web services, several setting up providersAuthentication 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: If you have an Oracle Fusion Middleware application installed, you have the required provider JAR file. Skip Step 1. |
To set up providers in a WebLogic domain
Applications Deployed on a Stand Alone WebLogic Server: Obtain the Oracle Access Manager provider, as follows.
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 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 "Required Components and Files".
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 Provider Deployment".
In Oracle Access Manager, global logout or SLO (single log out) is handled in various ways. This section describes the options supported by Oracle Access Manager and different paths to integrate these.
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:
This is a form of WebGate-managed SLO. In this mode, WebGate logs out any request for 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.
The requirement is to include a logout.jsp or logout.html as part of the application resource. No special policies are required to "unprotect" this URL. There is no need to include any logic within the page to delete any cookies.
To implement zero-configuration SLO
Include a logout.jsp or logout.html as part of the application resource
Optionally: The logout page could simply redirect back to the application Home page.
This is another form of WebGate-managed SLO. You can designate a set of logout URLs and set them as LogoutURLs parameter in the WebGate/AccessGate profile.
Caveat: WebGate matching of these URLs does not include query parameters. There is no requirement to have any logic in the logout page to clear the cookie explicitly. For example, a valid URL is illustrated in the first line while the second line has an example of an entry that cannot be matched as a LogoutURL:
/myapp/myapp.action/signout /myapp/myapp.action/do?logout=true
|
Note: Once the LogoutURLs parameter is specified, zero configuration SLO (matching of "logout." string) functionality ceases. Essentially, you can use either zero configuration SLO or specify LogoutURLs but not both. |
If you do not want the application to rely on WebGate managed SLO, you can handle SLO in an application-specific manner. In this mode, the application has a logout page resource defined. The page logic includes clearing the ObSSOCookie.
A logout.html template is shipped with every WebGate. Applications can use the template as reference. In this mode, it is also essential for the application to "unprotect" access to the logout resource using Oracle Access Manager policies. The application can also "brand" the page and also handle redirects to its home page as part of logout logic.
To implement application-managed SLO
Ensure that your application references the WebGate logout.html template.
Ensure that no Oracle Access Manager policies for the application protect access to the logout resource.
Optional: Allow the application to branch the page and handle redirects to the application Home page as part of logout logic.
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 10-6, "Oracle Access Manager Authentication Provider Common Parameters"
Table 10-7, "Provider-Specific Parameters for Identity Asserter for Single Sign-On"
Table 10-8, "Provider-Specific Parameters: Oracle Access Manager Authenticator"
Table 10-6 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 to ObSSOCookie. |
|
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 10-7 lists the provider-specific parameters for Oracle Access Manager Identity Asserter.
Table 10-7 Provider-Specific Parameters for Identity Asserter for Single Sign-On
| 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 Required Components for Oracle Access Manager Providers". |
|
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 Required Components for Oracle Access Manager Providers". |
|
Key Store |
The absolute path of JKS key store used for SSL communication between the provider and the Oracle Access Manager Access Server. |
Table 10-8 lists provider-specific parameters for the Oracle Access Manager Authenticator.
Table 10-8 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 "Installing and Setting Up Required Components for Oracle Access Manager Providers". |
|
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 "Installing and Setting Up Required Components for Oracle Access Manager Providers". |
Table 10-9 identifies known issues with this release. For more information about the tool, parameters, and values, see "About Using OAMCfgTool".
Table 10-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 and Validate options. It does not provide Delete or Overwrite options. |
|
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 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 backend 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 reposted, 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.
If you have an Oracle Fusion Middleware Application installed you already have the OAMCfgTool. In this case, skip Step 1.
Solution:
Applications Deployed on a Stand Alone WebLogic Server: Obtain OAMCfgTool, as follows.
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:
|
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 System 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 System 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.
|
See Also: Oracle Access Manager Identity and Common Administration Guide |
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 Oracle Access Manager Identity Assertion for Single Sign-On".
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.
In some cases when an application resource (URL) is accessed and the JSESSIONID cookie is not found, WebLogic Server rewrites the URL by including the JSESSIONID as part of the URL. If the URL in question is protected, Oracle Access Manager and OSSO Web agents might have issues matching the re-written URL.
To avoid issues of a mismatch with Oracle Access Manager, you can create a policy for matching the URL with JSESSIONID. For this example, suppose the protected URL is:
/myapp/login
You can create a policy within the appropriate policy domain to match the URL with JSESSIONID.
To avoid issues matching a re-written URL
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 My Policy Domains, and click the link to the desired policy domain.
Click the Policies tab, and then click Add.
Fill in and save General details:
Name: JSESSIONID Matching Policy
Resource operation(s): Select all applicable HTTP operations
Resource: Select the context root (create it if needed). For example: /myapp
URL Pattern: login
Click Save.
The OracleAS Single Sign-On solution provides single sign-on access to Web Applications. Oracle Internet Directory is the LDAP-based repository.
This solution is intended for applications that have been deployed on Oracle WebLogic Server but do not yet have single sign-on implemented. Requirements and steps to configure the OSSO solution are explained in "New Users of the OSSO Identity Asserter".
Applications that are already using the OracleAS Single Sign-On solution with the JPS login module and dynamically re-directing requests to OSSO are unaffected by the new OSSO solution. In this case, there is no need to configure the new OSSO Authentication provider described in this section.
This section is divided as follows:
This section describes the expected behavior when you implement the OracleAS Single Sign-On Identity Asserter. This section is divided as follows:
Figure 10-13 illustrates the location of components in the Oracle WebLogic Security Framework, including the OSSO Identity Asserter. Additional details follow.
Figure 10-13 Location of OSSO Components in the Oracle WebLogic Security Framework
At the top of the figure, Oracle HTTP Server is installed. This installation includes mod_weblogic and mod_osso, which are required to pass the identity token to the Providers and Oracle WebLogic Server. The Oracle WebLogic Server includes the partner application and the Identity Asserter (also known as the Identity Assertion Provider). The 10g OracleAS Single Sign-On server (OSSO Server), on the right side of the figure, communicates directly with the directory server and Oracle HTTP Server.
|
Note: For simplicity in text, this chapter uses the generic name of the WebLogic Server plug-in for Apache: mod_weblogic. For Oracle HTTP Server, the name of this plug-in differs from release 10g to 11g:
|
Figure 10-14 illustrates the processing that occurs when you have OSSO implemented with the Identity Asserter. Additional details follow the figure.
Figure 10-14 OSSO Identity Asserter Processing
The first time a request for a protected resource arrives at the mid-tier Web server, the request is redirected to the 10g OracleAS Single Sign-On server, which requires user credentials For a certificate-based authentication, no login page is displayed. After the user has been successfully authenticated, all further requests from that user require only that the user identity be asserted by the OSSO Identity Asserter before the population of a JAAS Subject takes place. The Subject is consumed by the downstream applications.
For example, suppose you have an application residing on an Oracle WebLogic Server that is front-ended with the Oracle HTTP Server. The application is protected using resource mappings in the mod_osso configuration. This case is described in the following process overview.
Process overview: OSSO Identity Asserter
The user requests a protected application.
The Oracle HTTP Server intercepts the request and processes it using mod_osso to check for an existing, valid Oracle HTTP Server cookie.
If there is no valid Oracle HTTP Server cookie, mod_osso redirects to the OracleAS SSO Server, which contacts the directory during authentication.
After successful authentication mod_osso decrypts the encrypted user identity populated by the OSSO server and sets the headers with user attributes.
mod_weblogic completes further processing and redirects the request to the Oracle WebLogic Server.
The WebLogic security layer invokes providers depending on their settings and the order specified. For example: the security layer invokes the:
A response is sent to the user through the Oracle HTTP Server, and access to the application is granted.
This topic describes the headers sent by Oracle HTTP Server and the tokens set in the header and the headers consumed by the OSSO Identity Asserter. If the application needs to use the JAAS subject, configure OSSO Identity Asserter.
Table 10-10 provides the list of headers set by Oracle HTTP Server (mod_osso and mod_weblogic). An application whose logic consumes the JAAS subject for identifying user information, should be configured to use the OSSO Identity Asserter. which uses the OracleAS SSO token type set in bold in the table (Proxy-Remote-User). The OSSO Identity Asserter looks for the Proxy-Remote-User header and asserts the user's identity. The follow up OID Authenticator populates the JAAS subject.
Table 10-10 Headers Sent by Oracle HTTP Server
| Attribute | Sample Value | Description |
|---|---|---|
|
Cookie |
OHS-Stads42.us.oracle.com:7777=....... |
Cookies |
|
Osso-User-Guid |
4F4E3D2BF4BFE250E040548CE9816D7E |
GUID of the authenticated user |
|
Osso-User-Dn |
cn=orcladmin,cn=users, dc=us,dc=oracle,dc=com |
DN of the authenticated user |
|
Osso-Subscriber |
DEFAULT COMPANY |
Subscriber name |
|
Osso-Subscriber-Dn |
dc=us,dc=oracle,dc=com |
Base DN of the subscriber |
|
Osso-Subscriber-Guid |
4F4E3D2BF410E250E040548CE9816D7E |
GUID of the subscriber |
|
Proxy-Remote-User |
ORCLADMIN |
The authenticated user |
|
Proxy-Auth-Type |
Basic SSO |
Authentication type |
Applications that do not require the JAAS subject for identifying user information, can read the headers directly using the request.getHeader() API. Such applications are free to read any header they need. Headers with user info are Osso-User-Dn, Osso-User-Guid, and Proxy-Remote-User.
The new OracleAS Single Sign-On solution includes the OSSO Identity Asserter, one of the two new Authentication providers for the Oracle WebLogic Server.
To have your application use the OSSO solution, you need the components described in the following task.
|
Note: If you already have components installed and set up, you do not need more. You can skip any steps that do not apply to your deployment. |
Task overview: Deploying and configuring the OSSO Identity Asserter
Install the following components:
OracleAS Single Sign-On Server 10g (10g OSSO server
|
See Also: Oracle Application Server Installation Guide on Oracle Technology Network at:http://www.oracle.com/technology/documentation/oim1014.html |
An Oracle Internet Directory repository configured to be used by the 10g OSSO server. Ensure that the directory server is tuned for your deployment.
|
See Also: The following manuals for Release 11g (11.1.1.1.0)
|
One of the following Web servers (based on Apache 2):
Oracle HTTP Server 11g as a front end to the Oracle WebLogic Server. This installation includes mod_osso and mod_weblogic.
OHS 10g, available in the companion CD release Oracle HTTP Server 10.1.3. This includes mod_osso. However, mod_weblogic must be added.
|
See Also: The following manuals for Release 11g (11.1.1.1.0)
|
Oracle WebLogic Server 10.3.1
|
See Also: Oracle Fusion Middleware Getting Started With Installation for Oracle WebLogic Server |
An Oracle Fusion Middleware product such as Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter is required; it includes the provider required for OSSO by Oracle WebLogic Server in the following path:
ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar
|
See Also:
|
Configure mod_weblogic so that it forwards requests to Oracle WebLogic Server, as explained in section "Configuring mod_weblogic".
Register the module mod_osso with the 10g SSO Server as a partner application, as described in "Registering Oracle HTTP Server mod_osso with OSSO Server 10.1.4".
Configure mod_osso, as described in "Configuring mod_osso to Protect Web Resources".
Add the OSSO Identity Asserter to the appropriate domain, as explained in section "Adding Providers to a WebLogic Domain for OSSO".
Configure a connection filter, as explained in section "Establishing Trust Between Oracle WebLogic Server and Other Entities".
Configure the use of the solution by the application, as explained in section "Configuring the Application for the OSSO Identity Asserter".
Identify and resolve issues with your OSSO Identity Asserter implementation, see "Troubleshooting for an OSSO Identity Asserter Deployment".
You can either edit the Oracle HTTP Server httpd.conf file directly or add mod_weblogic configuration in a separate file and include that file in httpd.conf.
The following procedure includes steps for two different Web server releases. Perform steps as needed for your deployment:
OHS 11g ships with mod_wl_ohs.so. In this case, skip Step 1.
OHS 10g does not ship with mod_weblogic (mod_wl_.so). If Oracle HTTP Server 10g is installed, start with Step 1 to copy mod_wl_20.so before configuration.
|
Note: For Oracle HTTP Server, the name of this plug-in differs from release 10g to 11g:
|
To install and configure mod_weblogic
Oracle HTTP Server 10.1.3: Copy mod_wl_20.so to the Oracle HTTP Server modules directory: For example:
From: WL_HOME/wlserver_10.0/server/plugin/linux/i686
To: ORACLE_HOME/ohs/modules
Locate the Oracle HTTP Server httpd.conf file. For example:
Oracle HTTP Server 10.1.3:
ORACLE_HOME/ohs/conf/httpd.conf
Oracle HTTP Server 11g:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
Verify that mod_weblogic configuration is in httpd.conf, either by inclusion of the appropriate configuration file or the configuration itself directly. For example, for Oracle HTTP Server 10g:
LoadModule weblogic_module ${ORACLE_INSTANCE}/ohs/modules/mod_wl_20.so
<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>
<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>
The mod_osso module is an Oracle HTTP Server module that provides authentication to OracleAS applications. This module resides on the Oracle HTTP Server that enables applications protected by OracleAS Single Sign-On to accept HTTP headers in lieu of a user name and password once the user has logged into the OracleAS Single Sign-On server. The values for these headers are stored in a mod_osso cookie.
The mod_osso module enables single sign-on for Oracle HTTP Server by examining incoming requests and determining whether the requested resource is protected. If it is, then it retrieves the Oracle HTTP Server cookie.
Under certain circumstances, you must register Oracle HTTP Server mod_osso using the 10.1.4 Oracle Identity Manager single sign-on registration tool (ssoreg.sh or ssoreg.bat). Table 10-11 provides a summary of parameters and values for this purpose. Running the tool updates the mod_osso registration record in osso.conf. The tool generates this file whenever it runs.
Table 10-11 ssoreg Parameters to Register Oracle HTTP Server mod_osso
| Parameter | Description |
|---|---|
|
-oracle_home_path |
Path to the 10.1.4 SSO Oracle_Home |
|
-site_name |
Any site name to be covered |
|
-config_mod_osso |
TRUE. If set to TRUE, this parameter indicates that the application being registered is mod_osso. You must include config_mod_osso for osso.conf to be generated. |
|
-mod_osso_url |
URL for front-ending Oracle HTTP Server Host:port. This is the URL that is used to access the partner application. The value should be specified in the URL format:http://oracle_http_host.domain:port |
|
-update_mode |
Optional. CREATE, the default, generates a new record. |
|
-remote_midtier |
Specifies that the mod_osso partner application to be registered is at a remote mid-tier. Use this option only when the mod_osso partner application to be configured is at a different ORACLE_HOME, and the OracleAS Single Sign-On server runs locally at the current ORACLE_HOME. |
|
-config_file |
Path where osso.conf is to be generated |
|
[-admin_info |
Optional. User name of the mod_osso administrator. If you omit this parameter, the Administer Information field on the Edit Partner Application page is left blank. |
|
admin_id |
Optional. Any additional information, such as email address, about the administrator. If you omit this parameter, the Administrator E-mail field on the Edit Partner Application page is left blank. |
|
<VirtualHost ...> |
Host name. Optional. Include this parameter only if you are registering an Oracle HTTP virtual host with the single sign-on server. Omit the parameter if you are not registering a virtual host. If you are creating an HTTP virtual host, use the httpd.conf file to fill in the directive for each protected URL. |
|
See Also: The following books on Oracle Technology Network at:http://www.oracle.com/technology/documentation/oim1014.html
|
The following procedure includes a sample command to register mod_osso. Values for your environment will be different.
To register mod_osso
Go to the following 10.1.4 Oracle Identity Manager directory path:
ORACLE_HOME/sso/bin/ssoreg
Run ssoreg with the following parameters and values for your environment. For example, on Unix, this might look like:
./ssoreg.sh -oracle_home_path \OraHome -site_name wls_server -config_mod_osso TRUE -mod_osso_url http://oracle_http_host.domain:7788 -update_mode CREATE -remote_midtier -config_file \tmp\osso.conf
Verify that the module mod_osso of the required Oracle HTTP Server is registered.
Proceed to "Configuring mod_osso to Protect Web Resources".
mod_osso redirects the user to the single sign-on server only if the URL you request is configured to be protected. You can secure URLs in one of two ways: statically or dynamically. Static directives simply protect the application, ceding control over user interaction to mod_osso. Dynamic directives not only protect the application, they also enable it to regulate user access.
For more information, see:
You can statically protect URLs with mod_osso by applying directives to the mod_osso.conf file. You must configure mod_osso to ensure that requests are intercepted properly. In addition, you specify the location of protected URIs, time out interval, and the authentication method. Oracle recommends that you place in the httpd.conf file the include statement for mod_osso.conf before the one wherein the weblogic_module statement is loaded.
The following procedure describes how to configure mod_osso by editing the mod_osso.conf file. This procedure provides details for two different releases. Ensure that you follow instructions for your OHS deployment:
Oracle HTTP Server 11g: Requires Step 2 and AuthType Osso in Step 4. The path name in Step 5 differs for Oracle HTTP Server 11g.
Oracle HTTP Server 10g: Requires Step 3 and AuthType Basic in Step 4. The path name in Step 5 differs for Oracle HTTP Server 10g.
To configure mod_osso to protect Web resources
Copy osso.conf from the location where it was generated to the following location:
From: /tmp/osso.conf
To:
ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
Oracle HTTP Server 11g: Copy mod_osso.conf from the disabled directory to the moduleconf directory for editing. For example:
From:
ORACLE_INSTANCE/config/OHS/<ohs_name>/disabled/mod_osso.conf
To:
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
Oracle HTTP Server 10g: Locate mod_osso.conf for editing. For example:
ORACLE_HOME/ohs/conf/mod_osso.conf
Edit mod_osso.conf to add the following information using values for your deployment. For example, using Oracle HTTP Server as an example (paths are different for 10g):
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
#Location is the URI you want to protect
<Location />
require valid-user
#OHS 11g AuthType Osso
#OHS 10g AuthType Basic
AuthType Osso
</Location>
</IfModule>
Locate the httpd.conf file for editing. For example:
Oracle HTTP Server 10.1.3:
ORACLE_HOME/ohs/config/httpd.conf
Oracle HTTP Server 11g:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
In the httpd.conf, confirm that the mod_osso.conf file path for your environment is included. For example:
include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
Restart the Oracle HTTP Server.
|
Tip: If the interception of requests is not working properly, consider placing the include statement for mod_osso.conf before the LoadModule weblogic_module statement in the httpd.conf. |
Proceed to "Adding Providers to a WebLogic Domain for OSSO".
Applications that use dynamic directives require no entry in mod_osso.conf because mod_osso protection is written directly into the application as one or more dynamic directives.
Dynamic directives are HTTP response headers that have special error codes that enable an application to request granular functionality from the single sign-on system without having to implement the intricacies of the single sign-on protocol. Upon receiving a directive as part of a simple HTTP response from the application, mod_osso creates the appropriate single sign-on protocol message and communicates it to the single sign-on server.
OracleAS supports dynamic directives for Java servlets and JSPs. The product does not currently support dynamic directives for PL/SQL applications. The JSPs that follow show how such directives are incorporated. Like their "static" counterparts, these sample "dynamic" applications generate user information:
|
Note: After adding dynamic directives, be sure to restart the Oracle HTTP Server, and the proceed to "Adding Providers to a WebLogic Domain for OSSO". |
Example 10-1 SSO Authentication with Dynamic Directives
The home.jsp includes ssodynauth.jsp that uses the request.getUserPrincipal().getName() method to check the user in the session. If the user is absent, it issues dynamic directive 499, a request for simple authentication. The key lines are in boldface.
//home.jsp <%@ include file="ssodynauth.jsp" %> <% //page content goes here %> //ssodynauth.jsp <% response.setHeader("Cache-Control", "no-cache"); response.setHeader("Pragma", "no-cache"); response.setHeader("Expires", "0"); %> <% // Check for user String ssoUser = null; try ( //ssoUser = request.getRemoteUser(); ssoUser = request.getUserPrincipal( ).getName( ); ssoUser = ssoUser.trim( ); } catch(Exception e) { ssoUser = null; } // If user is not authenticated then generate // dynamic directive for authentication if((ssoUser == null) || (ssoUser.length() < 1)) { response.sendError(499, "Oracle SSO"); return; }%>
|
See Also: Oracle Identity Management Application Developer's Guide 10g (10.1.4.0.1) Part Number B15997-01 on Oracle Technology network at:http://www.oracle.com/technology/software/products/ias/htdocs/101401.html |
Example 10-2 SSO Logout with Dynamic Directives
To achieve global logout (also known as single log-out), applications are expected to first invalidate sessions and then make a call to OSSO logout. The logout.jsp issues dynamic directive 470, a request for OSSO logout. The osso-return-logout is set by the application to specify the return URL after logout.
The key lines for SSO logout with dynamic directives appear in boldface in the following example. In 11g, the SSOFilter handles session synchronization.
//logout.jsp
<%@page session="false"%>
<%
response.setHeader("Osso-Return-Url", "http://my.oracle.com/");
HttpSession session = null;
session = request.getSession();
if (null != session )
{
// necessary for achieving SLO
session.invalidate();
}
response.sendError(470, "Oracle SSO");
%>
|
See Also:
|
|
Note: After adding dynamic directives, be sure to restart the Oracle HTTP Server, and the proceed to "Adding Providers to a WebLogic Domain for OSSO". |
You must add the OSSO Identity Asserter to a WebLogic domain. In addition to the OSSO Identity Asserter, Oracle recommends the following Authentication providers:
You can add providers using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.
|
See Also:
|
The following procedure illustrates adding Authentication providers using the Oracle WebLogic Administration Console. Before you begin, there is a condition to pay attention to:
Step 10: If your application requires the user in the same case as in Oracle Internet Directory (uppercase, lowercase, initial capitals), check Use Retrieved User Name as Principal. Otherwise, leave it unchecked.
To add providers to your WebLogic domain for OSSO Identity Assertion
Log in to the WebLogic Administration Console.
OSSO Identity Asserter: Perform the following steps to add this to the domain:
Click Security Realms, Default Realm Name, Providers.
Select New under the Authentication Providers table.
Enter a name for the new provider, select its type, and then click OK. For example:
Name: OSSO Identity Asserter
Ok
Click the name of the newly added provider.
On the Common tab, set the appropriate values for common parameters and set the Control Flag to SUFFICIENT and then save the settings.
Default Authentication Provider:
Click Security Realms, Default Realm Name, Providers.
Click Default Authentication Provider.
Set the control flag to OPTIONAL, and click Save
OID Authenticator: Perform the following steps to add this provider.
Click Security Realms, Default Realm Name, Providers.
Click New, and enter a name and type:.
Name. OID Authenticator
Type: OracleInternetDirectoryAuthenticator
Click Save.
Click the newly added authenticator to see the Settings page. Retain the default settings; do not change the Control Flag until you have verified that the Oracle Internet Directory configuration is valid.
|
Note: If OID Authenticator is the only provider, ensure the WebLogic Server user account and its granted group memberships are created in Oracle Internet Directory. Otherwise the WebLogic domain does not start properly. |
Click the Provider Specific tab and specify the following required settings:
Propagate Cause For Login Exception: Check
Principal: LDAP administrative user. For example: cn=orcladmin
Host: The Oracle Internet Directory hostname
Use Retrieved User Name as Principal: Check
Credential: LDAP administrative user password. For example: password
Confirm Credential: For example: password
Group Base DN: Oracle Internet Directory group search base
User Base DN: Oracle Internet Directory user search base.
Port: Oracle Internet Directory port
Reorder Providers: The order in which providers populate a subject with principals is significant and you might want to reorder the list of all providers in your realm and bring the newly added provider to the top of the list.
Save all configuration settings.
Stop and restart the Oracle WebLogic Server for the changes to take effect.
Log in to the WebLogic Administration Console:
Click Security Realms, Default Realm Name, Providers.
Select the Users and Groups tab to see a list of users and groups contained in the configured Authentication providers.
You should see usernames from the Oracle Internet Directory configuration, which implicitly verifies that the configuration is working.
--If the Oracle Internet Directory instance is configured successfully, you can change the Control Flag.
--If the Oracle Internet Directory authentication is sufficient for an application to identify the user, then choose the SUFFICIENT flag. SUFFICIENT means that if a user can be authenticated against Oracle Internet Directory, no further authentication is processed. REQUIRED means that the Authentication provider must succeed even if another provider already authenticated the user.
Application Requires User in Same Case as in Oracle Internet Directory: Check Use Retrieved User Name as Principal. Otherwise, leave it unchecked.
Save the changes.
Activate the changes and restart Oracle WebLogic Server.
Proceed with "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. In the WebLogic Administration Console. |
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.
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
|
See Also: "Configuring Security in a WebLogic Domain" in Oracle Fusion Middleware Securing Oracle WebLogic Server |
Table 10-12 provides a description of each parameter in a connection filter.
Table 10-12 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.
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 Application for the OSSO Identity Asserter".
This topic describes how to create the application authentication method for the OSSO Identity Asserter.
|
See Also: Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server |
Oracle WebLogic Server supports adding multiple auth-methods. If you are setting up an OSSO Identity Asserter in the WebLogic Application Console, the Web application using the OSSO Identity Asserter must have its auth-method set to CLIENT-CERT.
After deploying the application on the Oracle WebLogic Server, all web.xml files in the application EAR file must include CLIENT-CERT in the element auth-method for the appropriate realm, as described in the following procedure.
To edit web.xml for the OSSO Identity Asserter
Locate the web.xml file in the application EAR file. For example:
WEB-INF/web.xml
Locate the auth-method for the appropriate realm and enter CLIENT-CERT. For example:
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>myRealm</realm-name>
</login-config>
Save the file.
Redeploy and restart the application.
Repeat for each web.xml file in the application EAR file.
The troubleshooting items described in this section are grouped into the following categories:
|
See Also:
|
This section addresses the following troubleshooting items:
Error 404 - Not Found is Issued (Oracle WebLogic Server Side)
OSSO Solution for Applications Deployed on a Standalone WebLogic Server
OHS Is Not Redirecting to SSO - Internal Server Error 500
The most likely source of this problem is an incorrect configuration.
The following sample uses Oracle HTTP Server 11g. Path names are different if you have Oracle HTTP Server 10g.
To address it, proceed as follows:
Open the file mod_osso.conf and ensure that the resource is protected. For example:
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
<Location /protected-resource-uri> require valid-user AuthType Basic </Location>
Ensure that osso.conf is present and included in mod_osso.conf. For example, using Oracle HTTP Server 11g (paths are different for 10g)
OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
|
Note: There is no set location for osso.conf. The value is determined at registration time; it can be any absolute path. |
Ensure that httpd.conf includes mod_osso.conf. For example, using Oracle HTTP Server 11g (paths are different for 10g):
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
If all of the above were correctly specified, the SSO registration did not complete successfully and you must re-register SSO.
To register SSO, proceed as follows using the appropriate ssoreg tool for your platform. For example:
Run ssoreg.sh in 10.1.4 ORACLE_HOME/sso/bin to produce the file osso.conf. The following is a sample usage of this utility that produces the file in /tmp/osso.conf (the arguments are displayed in different lines only for illustration):
>ssoreg.sh -oracle_home_path /OraHome
-site_name wls_server
-config_mod_osso TRUE
-mod_osso_url http://host.domain.com:6666
-update_mode CREATE
-remote_midtier
-config_file /tmp/osso.conf
Copy the generated osso.confto another file system directory. For example: ORACLE_INSTANCE/config/OHS/<ohs_name>/osso.
Restart OHS.
Is Attribute AuthName Required?
Log messages might suggest that the attribute AuthName is required, and certain versions of Apache do require this attribute.
This example uses Oracle HTTP Server 11g. Path names are different for Oracle HTTP Server 10g.
To include this attribute, edit the file mod_osso.conf and insert a fragment like the following:
LoadModule osso_module modules/mod_osso.so <IfModule mod_osso.c> OssoIdleTimeout off OssoIpCheck on OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf <Location /> AuthName "Oracle Single Sign On" require valid-user AuthType Basic </Location> </IfModule>
URL Request not Redirected to SSO
Once a URL request is issued, if a basic pop-up is displayed instead of being redirected to SSO, then, most likely, the URL request has been intercepted by the Apache authorization module.
To address this problem, proceed as follows:
Edit the file httpd.conf and comment out the loading authorization modules as illustrated in the following fragment:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
LoadModule access_module modules/mod_access.so #LoadModule auth_module modules/mod_auth.so #LoadModule auth_anon_module modules/mod_auth_anon.so #LoadModule auth_db_module modules/mod_auth_dbm.so LoadModule proxy_module modules/mod_proxy.so
Restart OHS.
Error 404 - Not Found is Issued (OHS Side)
Typically, this error has the following format:
The requested URL <request-uri> was not found on this server
Most likely, the WebLogic redirect is not happening, and the request is attempting to grab an OHS resource not available.
To address this problem, verify that mod_weblogic is included in the file httpd.conf and that the WebLogic handler is set for the request pattern, as illustrated in the following fragment:
#httpd.conf <IfModule mod_weblogic.c> WebLogicHost <host> WebLogicPort yourWlsPortNumber </IfModule> <Location /request-uri-pattern> SetHandler weblogic-handler </Location>
Error 404 - Not Found is Issued (Oracle WebLogic Server Side)
Typically, this error has the following format:
Error 404--Not Found
Cause
This message informs that the Oracle WebLogic Server is not able to find a resource.
Solution
To address the problem, check that the resource is indeed deployed on the server. For example, if the pattern is /private1/Hello, check that Hello is accessible on the server with private1 as root.
Oracle SSO Failure - Unable to process request
Problem
You receive a message stating:
Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or Oracle HTTP Server single sign-on is incorrectly configured. Please notify your administrator.
Solution
Modify the Oracle HTTP Server httpd.conf file to include a port number in the ServerName and restart the Web server. For example:
From: ServerName host.domain.com
To: ServerName host.domain.com:port
OSSO Solution for Applications Deployed on a Standalone WebLogic Server
The Oracle Fusion Middleware Security Guide describes how to configure single sign-on (SSO)for applications that are deployed on Oracle Fusion Middleware Oracle WebLogic Server. However, details for applications that are deployed on a stand-alone Oracle WebLogic Server are provided here only.
Differences between the two environments include:
Oracle Fusion Middleware with OSSO: The required OSSO Identity Asserter (ossoiap.jar) is provided automatically when you install Oracle Fusion Middleware: Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter.
|
Note: Oracle Fusion Middleware with OSSO enables you to use either the Oracle HTTP Server 10g or 11g Web server. |
Stand-Alone Oracle WebLogic Server with OSSO: The required OSSO Identity Asserter (ossoiap.jar) must be acquired from the Oracle Web Tier, as described here.
|
Note: Stand-Alone Oracle WebLogic Server with OSSO requires Oracle HTTP Server 11g Web server. |
Whether you use OSSO for Oracle Fusion Middleware applications or other applications, the Identity Asserter performs the same functions as those illustrated and described in "Using the OSSO Identity Asserter" in the chapter "Configuring Single Sign-On in Oracle Fusion Middleware" of the Oracle Fusion Middleware Security Guide.
Also included in the following note are additional, optional details you can use to configure and test Single Logout for session invalidation and synchronization between the SSO cookie and the JSESSIONID cookie. Required files must also be acquired from the Oracle Web Tier, as described here.
Task overview: Deploying and configuring the OSSO Identity Asserter for applications on a stand-alone WebLogic Server
Install Oracle WebLogic Server 10.3.1 and other required components as follows:
Perform Step 1, a-d as described in the "Task overview: Deploying and configuring the OSSO Identity Asserter for applications on a stand-alone WebLogic Server".
Skip Step 1e and instead deploy your application.
Create a WebLogic security domain with the weblogin domain extension template that is supplied with Oracle WebLogic Server and can be used from $WLS_HOME/common/bin/config.sh.
Configure mod_weblogic to forward requests to Oracle WebLogic Server, as explained in "Configuring mod_weblogic".
Register and configure the module mod_osso with the 10g SSO Server as a partner application, as described in "New Users of the OSSO Identity Asserter".
Perform steps described in "Registering Oracle HTTP Server mod_osso with OSSO Server 10.1.4".
Perform steps described in "Configuring mod_osso to Protect Web Resources".
Add Authentication Providers to the appropriate security domain as follows:
Acquire the OSSO Identity Asserter (ossoiap.jar from the Oracle Web Tier at:
$ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar
Copy ossoiap.jar into $WLS_HOME/wlserver_10.x/server/lib/mbeantype, then restart the Oracle WebLogic Server.
Configure providers as described in "Adding Providers to a WebLogic Domain for OSSO".
Configure the Oracle WebLogic Connection Filtering mechanism to create access control lists and accept requests from the hosts where Oracle HTTP Server and the front-end Web server are running, as explained in "Establishing Trust Between Oracle WebLogic Server and Other Entities".
|
Note: Test the secured application to ensure that it is working with the default authenticator using the Oracle WebLogic Server host and port. |
Configure the application authentication method for the OSSO Identity Asserter (all web.xml files in the application EAR file must include CLIENT-CERT in the element auth-method), as explained in "Configuring the Application for the OSSO Identity Asserter".
|
Note: Test the application with users authenticated by OSSO while accessing the application with the Oracle HTTP Server host and port. |
Optional: You can configure and test Single Logout [Session Invalidation and synchronization between the SSO cookie and JSESSIONID cookie] as follows:
|
See Also: ""Synchronizing the User and SSO Sessions: SSO Synchronization Filter" for details on SSOFilter |
Acquire ssofilter.jar and configure Oracle WebLogic Server to use it as follows:
1. Acquire ssofilter.jar from the Oracle Web Tier at:
$ORACLE_INSTANCE/modules/oracle.ssofilter_11.1.1/ssofilter.jar
2. Copy it to an appropriate directory in Oracle Middleware home: WLS_INSTALL/Oracle/Middleware/modules directory, for example.
3. Add the absolute path of ssofilter.jar to the Oracle WebLogic Server classpath (by editing the setDomainEnv.sh script POST_CLASSPATH variable or CLASSPATH variable).
Deploy system-filters.war as a system filter, as follows:
1. Acquire system-filters.war from the Oracle Web Tier at:
$ORACLE_INSTANCE/modules/oracle.jrf_11.1.1/system-filters.war
2. Copy system-filters.war to an appropriate directory in Oracle Middleware home: WLS_INSTALL/Oracle/Middleware/modules directory, for example.
3. Deploy system-filters.war as an application library: From the WebLogic Administration Console, click Deployment, select New, and choose the location of file.
4. Restart the Oracle WebLogic Server, if asked.
Enable Logs to verify that the SSOFilter is working, as follows:
1. From the WebLogic Administration Console, click Domain, Environment, Servers, AdminServer.
2. Click the Logging tab.
3. From the Advanced drop-down, select "Minimum Severity to Log" as "Debug".
4. From the Advanced drop-down, "Message destinations", select LogFile: Severity Level as "Debug".
5. Save changes and restart the Oracle WebLogic Server.
Confirm that the SSOFilter is loaded as a system filter:
1. Open the AdminServer.log file in DomainHome/Servers/AdminServer/log/AdminServer.log.
2. Search for "SSOFilter" and confirm that you can see <Debug> messages, which indicate SSOFilter initialization nd confirm a filter load
Test the filter functionality to confirm that the SSO and JSESSIONID cookie are cleaned up after user logout and that attempts to access the application after logout require another login.
|
Note: You must have OSSO Identity Asserter configured in the WebLogic security domain, otherwise the filter will automatically disable during its initialization. |
Test logout with applications to confirm that the session is ends cleanly.
SSO Users Specified in "Users to Always Audit" Must Be Uppercase
When you specify SSO users in the Oracle HTTP Server audit configuration "Users to Always Audit" section, the SSO username must be specified in uppercase characters.
A comma-separated list of users can be specified to force the audit framework to audit events initiated by these users. Auditing occurs regardless of the audit level or filters that have been specified. This is true for all authentication types.
For more information, see "Managing Audit Policies" in the chapter "Configuring and Managing Auditing" in the Oracle Fusion Middleware Security Guide.
This section addresses the following troubleshooting items:
Error 403 - Forbidden
This message informs that the user does not have the required permission to access a resource. This message is shown, for example, when the application has been configured to allow access to users belonging to WLS Group SSOUsers and the asserted user belongs to a different group.
If you have verified that this is not a permissions issue, then check whether the JAAS Control Flag for the Default Identity Authenticator is set to REQUIRED, and if so, change the setting to OPTIONAL or to SUFFICIENT, as appropriate.
Error 401 - Unauthorized
This message informs that the access to a resource requires the user to be first authenticated.
Solution
Check that the user is indeed authenticated.
Check whether the server is being hit without first going through authentication using SSO.
OSSO Identity Assertion Not Getting Invoked
Situations in which the OSSO Identity Asserter is not getting invoked for a protected source, typically, involve incorrect configuration. Make sure that your environment accurately includes a configuration as that described in "Configuring the Application for the OSSO Identity Asserter".
In some cases when an application resource (URL) is accessed and the JSESSIONID cookie is not found, WebLogic Server rewrites the URL by including the JSESSIONID as part of the URL. If the URL in question is protected, Oracle Access Manager and OSSO Web agents might have issues matching the re-written URL.
To avoid issues of a mismatch, you can append an asterisk, *, to the end of the protected resource specified in mod_osso.conf. For example, if the protected URL is:
/myapp/login
The location in the mod_osso entry would be:
<Location /myapp/login*> valid user AuthType OSSO </Location>
Mod_osso module provides communication between the SSO-enabled login server and the Oracle HTTP Server listener. The mod_osso module is controlled by editing the mod_osso.conf file:
Oracle HTTP Server 11g installation includes mod_osso and mod_weblogic.
OHS 10g, available in the companion CD release Oracle HTTP Server 10.1.3, includes mod_osso.
|
See Also: The following topic and Release 1 (11.1.1) manuals
|
This section provides the following information:
A new configuration directive has been added to mod_osso to configure setting the HTTPOnly flag on OSSO cookies. The new Directive is: OssoHTTPOnly. Values are On (to enable) and Off (to disable) the flag. By default, the HTTPOnly flag is set to On; the directive is not set in the configuration.
This directive appends the HttpOnly flag to the OSSO cookies set in the browser. This purpose of this flag is to prevent cross-site scripting. Cookies that have this flag set are not accessible by javascript code or applets running on the browser. Cookies that have this flag set is only sent to the server that set the cookie for the particular domain across over http or https.
This is a per VirtualHost directive. It can only be set at the global scope or inside a VirtualHost section. The following example shows the new directive:
<VirtualHost *.7778> OssoConfigFile conf/osso.conf OssoHTTPOnly On --- --- --- <Location /osso> AuthType Osso --- --- </Location> </VirtualHost>
In mod_osso 10g, the OssoSecureCookies directive is disabled by default. However, in mod_osso 11g, this behavior is enabled by default. In mod_osso 11g, to disable the OssoSecureCookies directive you must set OssoSecureCookies to Off in the corresponding configuration file. When mod_osso is enabled, the mod_osso.conf file is available at:
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
Set the OssoSecureCookies directive as follows:
OssoSecureCookies "Off"
Mod_osso does not URL encode the return URL in the query when redirecting to the Oracle SSO Server for logout.
To fix this issue, the encoded URL must be passed. For example: response.setHeader("Osso-Return-Url", encoded-url)
Oracle Fusion Middleware supports 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 with the Oracle Single Sign-on Server. |
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 "SSO Logout with Dynamic Directives". For details about Oracle Access Manager logout, see "Configuring Global Logout for Oracle Access Manager".
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 10-13.
Table 10-13 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. The following procedure describes how to do this.
The Authentication providers use messages with verbose descriptions of low-level activity within the application when Debug mode issued. Ordinarily, you do not need this much information. However, if you must call Oracle Support, you might be advised to set up debugging. When set, Authentication providers messages appear in the Oracle WebLogic Server default log location.
To set up debugging
Log into WebLogic Administration Console.
Go to Domain, Environment, Servers, yourserver.
Click the Debug tab.
Under Debug Settings for this Server, click the following to expand: weblogic, security, atn.
Click the option beside DebugSecurityAtn to enable it.
Save Changes.
Restart the Oracle WebLogic Server.
In the Oracle WebLogic Server default log location, search for SSOAssertionProvider. For example:
####<Apr 10, 2009 2:32:16 AM PDT> <Debug> <SecurityAtn> <sta00483> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1239355936490> <BEA-000000> <SSOAssertionProvider:Type = Proxy-Remote-User>
|
 Copyright © 2003, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|