| Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
This chapter discusses how to use the Oracle Access Manager security provider, formerly known as Oracle COREid Access and Identity, for authentication, authorization, and single sign-on. The chapter is useful for those who have already deployed, or plan to deploy, the Oracle Access Manager system. It describes integration between the Oracle Access Manager 10.1.4 implementation and the OC4J 10.1.3.1 implementation, and how to secure applications deployed on OC4J through features of Oracle Access Manager. This includes detailed configuration steps for Web applications, and examples for Web applications, EJBs, and Web Service authentication schemes (including username token, X.509 token, and SAML token).
This chapter covers the following topics:
Notes:
The emphasis in this chapter is on what you must do from an OC4J and OracleAS JAAS Provider perspective to enable the use of Oracle Access Manager with Oracle Application Server. Some prior familiarity with Oracle Access Manager is assumed, and there is no attempt to thoroughly document the use of its features or tools. In terms of what to do for necessary Oracle Access Manager setup, the emphasis is on required settings, and how they map to OracleAS JAAS Provider configuration, rather than on how to accomplish the settings. Please consult Oracle Access Manager documentation for details on its features and administration.
Only the 10.1.4 implementation of Oracle Access Manager is supported with the 10.1.3.1 implementation of OC4J.
See Also:
Oracle Access Manager Installation Guide
Oracle Access Manager System Administration Guide for information related to settings of the Access Server (described later in this chapter) and definition of access controls and user access to applications and data
Oracle Access Manager Identity and Common Administration Guide for information related to Identity Server settings and functions common to both the Access Server and Identity Server (both described later in this chapter)
Oracle Access Manager Developer Guide
These and other Oracle Access Manager documents are available through:
http://www.oracle.com/technology/documentation/index.html
They are available with the Oracle Identity Management 10.1.4 documentation release, listed under "Application Servers".
This section provides an overview of Oracle Access Manager and discusses prerequisites and architecture:
Oracle Access Manager is an enterprise-class authentication, authorization, and auditing solution that provides centralized security administration. This includes functionality for access control, single sign-on (separate from Oracle Single Sign-On), personalization, and user profile management in heterogeneous application environments across a variety of application servers, legacy applications, and databases. Oracle Access Manager provides key features for creating, managing, and enforcing access policies. If you have different sets of users that require access to different data sets, while all require access to a common set of data, Oracle Access Manager can allow the right levels of access to each group so that everyone can access only the data that is appropriate for them.
In comparing Oracle Access Manager to other authentication, single sign-on, and authorization services, note the following differentiating features:
You can centralize authentication and authorization for multiple OC4J instances through a single Oracle Access Manager instance, allowing centralized single sign-on and auditing functionality, as well as more robust authentication options.
Oracle Access Manager offers superior identity administration through workflow, fine-grained attribute control, and delegation of administration.
Oracle Access Manager supports access control based on dynamic groups, with members based on a given identity profile.
Oracle Access Manager allows realtime access and identity integration, with runtime changes made through Oracle Access Manager being automatically populated into the Access Server cache to eliminate security loopholes.
In OC4J 10.1.3.x implementations, OracleAS JAAS Provider supports Oracle Access Manager integration through a custom login module and a special authentication method setting.
Oracle Access Manager includes the following components:
WebGate, the policy enforcer, is a Web server plug-in access client (with an associated Apache mod for use on Oracle HTTP Server) that intercepts HTTP requests and forwards them to the Access Server for authentication and authorization. In comparison, an AccessGate is a custom access client, built with the Oracle Access Manager SDK, that processes Web and non-Web resource requests from users or applications. It intercepts user requests and forwards them to the Access Server for authentication and authorization. The terms WebGate and AccessGate can be used interchangeably in most situations.
WebPass is a Web server plug-in that passes information between a Web server and an Oracle Access Manager Identity Server.
Oracle Access Manager Identity Server processes all user identity, group, organization, and credential-management requests.
Access Server, the policy decision-maker, receives requests, responds to the access client, and manages the login session. The Access Server receives requests from WebGate and queries the authentication, authorization, and auditing rules in Oracle Internet Directory. The Access Server also manages the login session by helping WebGate terminate sessions, set user session timeouts, reauthenticate when timeouts occur, and track session activity.
Policy Manager writes policy data to Oracle Internet Directory (or other suitable LDAP server), and updates the Access Server with policy modifications. It includes an Access System Console that enables administrators to manage policies and the system configuration.
Note:
In the 10.1.3.1 implementation, Application Server Control does not support configuration of Oracle Access Manager.This section describes what you must have installed to use Oracle Access Manager. Oracle Access Manager components are version 10.1.4.
See Also:
Oracle Access Manager Installation Guide for installation instructions
At a high level, prerequisites include installing Oracle Access Manager and Oracle Application Server, and configuring the Access Manager SDK and your applications on OC4J.
Detailed requirements on the Oracle Access Manager side:
A suitable LDAP repository, such as Oracle Internet Directory (included in the Oracle Application Server 10.1.4 or 10.1.2 infrastructure).
A Web server, such as Oracle HTTP Server (included in the Oracle Application Server 10.1.3.x middle-tier infrastructure).
The Oracle Access Manager Identity Server and Access Server. When you install Oracle Access Manager, you will be asked to specify the LDAP repository you are using, which must be accessible for communication with Oracle Access Manager Identity Server and Access Server during runtime.
Oracle Access Manager WebGate, WebPass, and Policy Manager installed on the Web server. WebGate is the SSO interceptor and communicates with Access Server during runtime. WebPass communicates with Oracle Access Manager Identity Server. Policy Manager communicates with the LDAP repository. When you install WebGate and WebPass, you will be asked to specify the Access Server and Identity Server you are using.
Detailed requirements on the OC4J side:
Oracle Application Server 10.1.3.x middle-tier installation, with OC4J and Oracle HTTP Server, including the mod_oc4j Apache mod. Note that this is separate from the Web server you install on the Oracle Access Manager side, which may or may not be Oracle HTTP Server.
Using Oracle Access Manager requires Oracle HTTP Server; you cannot use standalone OC4J.
Oracle Access Manager WebGate installed on this Oracle HTTP Server.
Additional OC4J instances as needed. Typically, when using Oracle Access Manager SSO, multiple OC4J instances are used in the topology, so the Oracle HTTP Server instance must be configured to route and maintain multiple OC4J instances.
Access Manager SDK, one for each OC4J instance, on the same system as OC4J. The Access Manager SDK is installed independently and is required by OC4J at runtime to communicate with Access Server. Each OC4J instance communicates with an Access Manager SDK instance, which has been configured to communicate with an Access Server instance.
The next section, "Oracle Access Manager Architecture", shows how the Oracle Access Manager components fit with key components of the Oracle Application Server middle-tier infrastructure.
Figure 11-1 shows the Oracle Access Manager architecture.
Figure 11-1 Oracle Access Manager Architecture
There are three stages of configuration steps to use OC4J applications with Oracle Access Manager:
One-time configurations for the Oracle Access Manager Policy Manager installation. This includes setting up authentication schemes and configuring an Oracle Access Manager resource type. Refer to "Configuring Oracle Access Manager".
Configurations for each OC4J instance. This includes configuring each OC4J instance with an Access Manager SDK installation. Refer to "Configuring OC4J with the Access Manager SDK".
Configurations for your application. This includes web.xml settings, deployment-time settings, orion-application.xml settings (pre-deployment or post-deployment), and JAAS login module settings. Refer to "Configuring the Application".
Note:
Also ensure that the LDAP server you use has the accounts you will need, as discussed in "Creating Required Accounts in the LDAP Server".This section provides background on some Oracle Access Manager concepts that will be relevant later in this chapter:
In Oracle Access Manager, a resource type describes the kind of resource to be protected, including its associated operations. Operations associated with a resource are tied to its type. Before you can add resources to a policy domain, you must define their types and the operation or operations associated with them that you want to protect.
For example, by default Oracle Access Manager supports resource types that are named "HTTP" and "EJB". The HTTP resource type supports operations such as CONNECT, DELETE, GET, POST, PUT, and TRACE. The EJB resource type supports the operation EXECUTE, which executes a bean. For a custom resource type, you can specify a custom operation name.
To create a session to the Access Server, OC4J uses the Access Manager SDK, and the SDK expects some resource type and resource operation to be specified. For this reason, when you configure the Oracle Access Manager login module, you must configure a custom Oracle Access Manager resource type, including the following:
Desired name of the resource type (can be arbitrary)
Desired name of the operation (can be arbitrary)
You will specify just a single resource operation, but this will encompass whatever you want to execute against the protected resource.
URL of the protected resource
See Also:
Oracle Access Manager System Administration Guide for information about Oracle Access Manager resource types
In order to validate any user, Oracle Access Manager must be configured with an authentication scheme. An authentication scheme consists of plug-ins.
OC4J support for Oracle Access Manager uses the credential_mapping plug-in, which maps user credentials to profiles, and, where applicable, the validate_password plug-in, which validates user passwords. You must configure these plug-ins as shown later in this chapter.
Additionally, OC4J supports two modes of integrating end-user authentication (identity assertion) with Oracle Access Manager:
Use of the Oracle Access Manager SSO cookie, ObSSOCookie, discussed further in the next section, "About the Oracle Access Manager Single Sign-On Cookie"
Use of a user name and password that are passed in HTTP headers, discussed further in "About Using HTTP Header Variables for Authentication"
See Also:
Oracle Access Manager System Administration Guide for information about Oracle Access Manager plug-ins
Oracle Access Manager implements single-domain and multi-domain single sign-on through an encrypted session cookie called the ObSSOCookie. (This is one of two possible modes of end-user authentication, the other involving HTTP header variables as discussed in the next section.) WebGate sends this cookie to the user's browser upon successful authentication. This cookie can then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.
When a user requests access to a resource, the request flows from WebGate to the Access Server. Once the user is validated, the ObSSOCookie is set, and then passed to OC4J. With this single sign-on functionality, Oracle Access Manager uses the cookie for subsequent requests instead of prompting the user to supply authentication credentials.
OC4J uses the ObSSOCookie to connect to the Access Server and retrieve user roles.
Note:
ObSSOCookie is a session cookie by default, but can be made persistent.See Also:
Oracle Access Manager System Administration Guide for information about the ObSSOCookie
Oracle Access Manager supports the use of HTTP header variables for authentication, where a user name and password are passed in HTTP headers to assert an end user. (This is one of two possible modes of end-user authentication, the other being the use of the Oracle Access Manager ObSSOCookie as discussed in the preceding section.)
To use this mode, you must configure the Oracle Access Manager login module with this user name and password (as discussed in "Configure the Oracle Access Manager Login Module") for OC4J to use in accessing the Access Server.
Consider the 4K size limit of the HTTP header when you use HTTP header variables and cookies to pass information to downstream applications. This HTTP header size limit includes all cookies, server variables, and environment variables—that is, all of the content of the HTTP header. There is no constraint on the number of individual elements an HTTP header can contain if the content does not exceed the 4K limit. Therefore, when assessing the amount of available space in the HTTP header, take into account the byte size of the data used by Oracle Access Manager and other applications. For example, if Oracle Access Manager and other applications combine to use 1K in the HTTP header, you would have 3K for your data.
This section discusses one-time configurations to your Oracle Access Manager installation:
For single sign-on functionality, a form-based authentication scheme must be used in protecting your resources, due to limitations in the basic authentication scheme. (Some aspects of your configuration will have to use a no-password authentication, however, as discussed in "Configure Oracle Access Manager Basic Authentication".)
The steps here are to create and protect a login page for form-based authentication in Oracle Access Manager, for use by WebGate in protecting your resource. You will later configure your application to be protected by this form-based authentication.
Configure the credential_mapping Plug-In for Form-Based Authentication
Configure the validate_password Plug-In for Form-Based Authentication
See Also:
Discussion of how to configure form-based authentication in the Oracle Access Manager System Administration Guide, particularly the related appendix
Create a login page for form-based authentication. As will be pointed out, some of the parameters you set in this page correspond to settings you will make in Policy Manager and related plug-ins.
Put the login page under the OHS_HOME/document_root directory, typically ORACLE_HOME/Apache/Apache/htdocs, on the middle-tier system.
Here is a sample login page, login.html. Assume it is in the ORACLE_HOME/Apache/Apache/htdocs/login directory.
<html> <head> <title> COREid SSO Login Page</title> <body bgcolor="white"> <h1 align="center">COREid SSO Provider Example : Sign in</h1> <form method="POST" action="/coreid/access/test.html" > <table border="0" cellspacing="5"> <tr> <th align="right">Username:</th> <td align="left"><input type="text" name="usernamevar"></td> </tr> <tr> <th align="right">Password:</th> <td align="left"><input type="password" name="passwordvar"></td> </tr> <tr> <td align="right"><input type="submit" value="Log In"></td> <td align="left"><input type="reset"></td> </tr> </table> </form> </body> </html>
The action URL for the POST method can be arbitrary, but must match the action URL you specify when you configure authentication management in Policy Manager in the next step.
The variable for the user name (usernamevar here) must match what you specify in the Oracle Access Manager credential_mapping plug-in. The variable for the password (passwordvar here) must match what you specify in the Oracle Access Manager validate_password plug-in.
This step uses the Policy Manager to define form-based authentication. Navigate as follows in Policy Manager:
Access System Console > Access System Configuration > Authentication Management
List all authentication schemes, then choose to add a new scheme. In the General tab to define a new authentication scheme, makes entries such as the following:
Name: COREidSSOform Description: COREid SSO Form Based Level: 1 Challenge Method: Form Challenge Parameter: form: /login/login.html creds: usernamevar passwordvar action: /coreid/access/test.html passthrough: No SSL Required: No Challenge Redirect Enabled: Yes
You can choose any name and description; here "COREidSSOform" and "COREid SSO Form Based" are just examples. The challenge parameter specifies login/login.html as the form because that is the path relative to the Oracle HTTP Server document root where we created the login page in the previous step. Leave "Challenge Redirect" blank.
Note that the entries for "creds" here must match the variables specified for user and password in your login page in the previous step, and these variables are used in the credential_mapping plug-in and validate_password plug-in, respectively, for form-based authentication.
Also note that the action URL (/coreid/access/test.html here) can be arbitrary, but must match the action URL for the POST method in your login page. Protect this URL with the basic (no password) authentication scheme described in "Configure Oracle Access Manager Basic Authentication", following shortly.
Next, you must configure the Oracle Access Manager credential_mapping plug-in for form-based authentication in Policy Manager. This is to protect the login form.
Navigate to the appropriate page as follows:
Access System Console > Access System Configuration > Authentication Management
List all authentication schemes, then choose the form-based scheme, then go to the Plugins tab.
Modify the credential_mapping plug-in with entries such as the following:
obMappingBase="cn=users,dc=us,dc=oracle,dc=com",obMappingFilter="(&(&
(objectclass=inetorgperson)(uid=%usernamevar%))(|(!
(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))"
The value entered for uid (usernamevar here) must match the variable you specified for the user name in the login form, and when defining form-based authentication in Policy Manager, shown in previous steps.
This also corresponds to the value of the coreid.name.attribute option in the Oracle Access Manager login module configuration in OC4J.
See Also:
Oracle Access Manager System Administration Guide for more information about the credential_mapping plug-in
Now configure the Oracle Access Manager validate_password plug-in for form-based authentication in Policy Manager. This is to protect the login form.
Navigate as for the credential_mapping plug-in in the previous step. Modify the validate_password plug-in with an entry such as the following:
obCredentialPassword="passwordvar"
The value entered for obCredentialPassword (passwordvar here) must match the password variable specified in the login page, and when defining form-based authentication in Policy Manager (shown in previous steps).
This also corresponds to the value of the coreid.password.attribute option in the Oracle Access Manager login module configuration.
You must configure the Oracle Access Manager basic authentication scheme, which must not be password protected. (It will use only the credential_mapping plug-in, not the validate_password plug-in.) This scheme will be used to protect two resources:
A URL associated with the resource type that you configure, as discussed in "Configure and Protect the URL of the Configured Resource Type". The Oracle Access Manager login module will use this URL to communicate to the Access Server through the Access Manager SDK.
The action URL for the form page, noted in "Create a Login Form" and "Define Form-Based Authentication in Policy Manager". This is so submitted form requests can be intercepted by WebGate in order to enforce rules for submitted credentials.
(Your application itself, however, must be protected by form-based authentication, described in "Configure Oracle Access Manager Form-Based Authentication".)
These steps define basic authentication, without a password, to protect the resource.
This step uses the Policy Manager to configure basic authentication. Navigate as follows in Policy Manager:
Access System Console > Access System Configuration > Authentication Management
List all authentication schemes, then choose to add a new scheme. In the General tab to define a new authentication scheme, makes entries such as the following:
Name: COREidSSONoPwd Description: Authentication without Password Level: 1 Challenge Method: Basic Challenge Parameter: realm:NetPoint Basic Over LDAP SSL Required: No Challenge Redirect Enabled: Yes
You can choose any name and description; here "COREidSSONoPwd" and "Authentication without Password" are just examples. The challenge parameter entry indicated here is one of the choices available from a dropdown list. Leave "Challenge Redirect" blank.
Next, configure the Oracle Access Manager credential_mapping plug-in for basic authentication in Policy Manager. This is to protect your resource, but without a password so WebGate can intercept results.
Navigate to the appropriate page as follows:
Access System Console > Access System Configuration > Authentication Management
List all authentication schemes, then choose the basic scheme, then go to the Plugins tab.
Modify the credential_mapping plug-in with entries such as the following:
obMappingBase="cn=users,dc=us,dc=oracle,dc=com",obMappingFilter="(&(&
(objectclass=inetorgperson)(uid=%usernamevar%))(|(!
(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))"
These are the same entries as for the credential_mapping plug-in for form-based authentication. The value entered for uid (usernamevar here) must match the user name variable specified in the login form.
This also corresponds to the value of the coreid.name.attribute option in the Oracle Access Manager login module configuration.
See Also:
Oracle Access Manager System Administration Guide for more information about the credential_mapping plug-in
In Oracle Access Manager, a resource type describes the kind of resource to be protected, including its associated operations. Operations associated with a resource are tied to its type. You must configure an Oracle Access Manager resource type for your resource, and then protect your resource type, action URL, and application.
There are three parts to configuring the resource type for your resource, accomplished through Policy Manager and described below:
The Oracle Access Manager login module will need information for the resource type, as will be noted. OC4J uses the resource type to retrieve user information based on the Oracle Access Manager ObSSOCookie or the user name, using APIs of the Access Manager SDK.
Once these configuration steps are complete, the resource URL will be associated with the resource type and protected by the no-password basic authentication method you configured.
To configure the name and operation of the resource type in Policy Manager, navigate as follows:
Access System Console > Access System Configuration > Common Information Configuration > Resource Type Definitions
On the page that lists all resource types, choose to add a new resource type.
Make entries such as the following to define a new resource type:
Resource Name: myresourcetype Display Name: My Resource Type Display Name Resource Matching: Case Insensitive Resource Operation: myresourceoperation
You can choose any names for the resource type and resource operation, but you must use the same names for the coreid.resource.type and coreid.resource.operation option values in the Oracle Access Manager login module configuration.
To configure and protect the URL of your configured resource type in Policy Manager, navigate as follows:
Policy Manager > Create Policy Domains
Choose the link for your policy domain. In the Resources tab, use entries such as the following:
Resource Type: myresourcetype Host Identifiers: myhost URL Prefix: /myresourceurl Description: My Description
This configuration must be protected using a no-password scheme. Use the basic scheme that you configured in "Define Basic Authentication in Policy Manager".
Choose your resource type (myresourcetype in these examples) from the dropdown list, then choose the appropriate host name.
The URL prefix must start with a "/" and is the designated URL of the resource type. This must match the value of the coreid.resource.name option in the Oracle Access Manager login module configuration.
The description can be anything; "My Description" is just an example.
Note:
Do not confuse the URL specified here with the "action URL" specified when setting up authentication in earlier steps. The two are separate.After authentication, OC4J requires access to the user's roles in order to check for authorization. To enable this, you must set up an Oracle Access Manager "return action" that allows Oracle Access Manager to return the appropriate roles to OC4J for the user after successful authentication.
To set up the return action in Oracle Access Manager, navigate as follows:
Policy Manager > My Policy Domains > Select myresourcetype > Authorization Rules tab > Choose role name > Actions tab
Under the Authorization Success section, add the following entries (continuing the preceding example using myresourcetype):
Return Type: myresourcetype Return Name: myresourcetype Return Attribute: ObMyGroups
ObMyGroups is an action attribute defined in Oracle Access Manager for use in returning all the roles of an authenticated user.
Using Policy Manager, protect the action URL you specified in "Configure Oracle Access Manager Form-Based Authentication". Use similar steps as for protecting the resource type URL, as described in "Configure and Protect the URL of the Configured Resource Type".
This configuration must be under a no-password authentication scheme. Use the basic authentication scheme that you configured in "Configure Oracle Access Manager Basic Authentication".
Use "HTTP" as the resource type.
Specify the action URL (/coreid/access/test.html in the examples).
See Also:
For information about protecting resources:Oracle Access Manager System Administration Guide
This section describes configuration steps for each OC4J instance on the middle tier.
As a prerequisite to this, you must install WebGate on the Oracle HTTP Server instance in the middle tier. This Oracle HTTP Server instance, in turn, can (and typically does) support multiple OC4J instances.
This section covers the following steps:
Note:
Your middle-tier and OC4J installation can be on the same system as Oracle Access Manager, but would typically not be.See Also:
Oracle Access Manager Installation Guide for information about installing AccessGate/WebGate
Typically, when using Oracle Access Manager SSO, multiple OC4J instances are used in the topology, so the Oracle HTTP Server instance must be configured to route and maintain multiple OC4J instances:
Create new OC4J instances as desired, using the createinstance utility as described in the Oracle Containers for J2EE Configuration and Administration Guide.
Each OC4J instance should be tied to the Oracle HTTP Server instance. Each application deployed to an OC4J instance must be configured in the mod_oc4j configuration file, ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf, so that requests are properly routed to the OC4J instance. This should occur automatically when you create the OC4J instance.
You will need Oracle Access Manager SDK, one installation for each OC4J instance, on the same system as OC4J. The Access Manager SDK is required by OC4J at runtime to communicate with Access Server. OC4J must be given the Access Manager SDK location during startup (through the java.library.path property, as shown later in this chapter), so that it can initialize the SDK. Note this initialization occurs only if at least one application is using Oracle Access Manager as the security provider. Also note the following:
Create a separate Access Manager SDK installation for each OC4J instance, on the same system as OC4J. You can have multiple Access Manager SDK installations on the same system.
Configure each Access Manager SDK to work with the appropriate Access Server. From Access_SDK_Home/access/oblix/tools/configureAccessGate directory, run the command configureAccessGate. This utility requires the Access Server ID, AccessGate ID, and other related parameters.
Copy the Oracle Access Manager file jobaccess.jar from the Access Manager SDK to the OC4J path. You will find this file in the Access_SDK_Home/AccessServerSDK/oblix/lib directory. Create the directory ORACLE_HOME/j2ee/home/lib/ext (if it does not already exist) and copy the jobaccess.jar to that directory.
See Also:
Oracle Access Manager Developer Guide for information about installing the Access Manager SDK
Oracle Access Manager System Administration Guide for information about the configureAccessGate utility
You must configure the java.library.path property for each OC4J instance, in the ORACLE_HOME/opmn/conf/opmn.xml file, so that the OC4J instance has access to the Access Manager SDK at runtime. Set the property so that it points to the SDK location.
For example, on a Windows system:
-Djava.library.path=C:\CoreID\AccessSDK\AccessServerSDK\oblix\lib
This is shown in more detail in the next section, "Configuring opmn.xml for Oracle Access Manager".
See Also:
Oracle Process Manager and Notification Server Administrator's Guide for information about OPMN and the opmn.xml file
Where OC4J is managed by OPMN, add settings to opmn.xml for Oracle HTTP Server and OC4J, as follows, when you use Oracle Access Manager:
For OC4J, under the process types "home", "OC4J_SOA", and any other OC4J instance where applications will be deployed that use Oracle Access Manager, do the following:
Set the LD_ASSUME_KERNEL environment variable to the value "2.4.19".
Set the LD_LIBRARY_PATH environment variable to point to the AccessServerSDK library path.
Add the AccessServerSDK library path to java.library.path as a start parameter.
Then restart the OC4J instances.
For Oracle HTTP Server, under the process type "HTTP_Server", set LD_ASSUME_KERNEL to "2.4.19", then restart the Oracle HTTP Server instance.
Following is an opmn.xml example for the OC4J home instance. Repeat these settings for the OC4J_SOA instance and any other OC4J instances as appropriate:
<ias-component id="OC4J">
<process-type id="home" module-id="OC4J" status="enabled">
<environment>
<variable id="LD_ASSUME_KERNEL" value="2.4.19"/>
<variable id="LD_LIBRARY_PATH"
value="/your_asdk_home/AccessServerSDK/oblix/lib" append="true"/>
</environment>
<module-data>
<category id="start-parameters">
<data id="java-options" value="-server ...
-Djava.library.path=/your_asdk_home/AccessServerSDK/oblix/lib
... />
</category>
...
</module-data>
...
</process-type>
...
</ias-component>
And here is an example for Oracle HTTP Server:
<ias-component id="HTTP_Server">
<process-type id="HTTP_Server" module-id="OHS">
<environment>
<variable id="LD_ASSUME_KERNEL" value="2.4.19" />
</environment>
...
</process-type>
...
</ias-component>
In the LDAP directory server that you use (such as Oracle Internet Directory), the following accounts are required by OC4J and Application Server Control 10.1.3.x implementations:
oc4jadmin user
oc4j-administrators role, with member oc4jadmin
oc4j-app-administrators role
ascontrol_admin (administrative role for all SOA controls, including Application Server Control), with member oc4jadmin
ascontrol_appadmin (Application Server Control required role)
ascontrol_monitor (Application Server Control required role)
If you use Oracle Internet Directory, these accounts are created automatically when you associate the OC4J instance with the Oracle Internet Directory instance, as described in "Associate Oracle Internet Directory with OC4J". ("Required Accounts Created in Oracle Internet Directory" is a subsection of this.)
If you use an external LDAP provider, you must create accounts manually, as described in "Creating the Administrative User and Roles and Granting RMI Permission".
See Also:
Instructions in this section are geared toward a Web application, consisting of the following steps:
The first step in protecting your application is to protect appropriate URLs or URL prefixes through settings in the web.xml file, using standard J2EE features.
These are the same URLs that you will you protect through Oracle Access Manager configuration in "Protect the Application URLs in Oracle Access Manager".
In Oracle Application Server 10.1.3.x implementations, Application Server Control does not yet support Oracle Access Manager as a security provider. When you deploy your application using the Application Server Control Console, choose the file-based provider. This will be overridden through the configuration steps documented in this chapter.
To use Oracle Access Manager Single Sign-On as the authentication method for Web applications, set the auth-method attribute to "COREIDSSO" in the <jazn-web-app> element in the OC4J orion-application.xml file. You can do this as either a pre-deployment step (packaged in the EAR file) or a post-deployment step.
Notes:
You do not need an <auth-method> setting in the web.xml file. Any setting in web.xml would be overridden by the "COREIDSSO" setting in orion-application.xml.
The <jazn-web-app> element is also supported in the orion-web.xml file. In the event of conflict, orion-web.xml takes precedence over orion-application.xml for the particular Web application in question.
Here is a sample entry in orion-application.xml, where <jazn-web-app> is a subelement of the <jazn> element:
<orion-application ... >
...
<jazn provider="XML" >
<jazn-web-app auth-method="COREIDSSO"/>
...
</jazn>
...
</orion-application>
Use Policy Manager to protect your application URLs or URL prefixes through form-based authentication. These will be the same URLs as in "Protect the Application URLs in web.xml". Use the following navigation:
Policy Manager > Create Policy Domains
Then choose the appropriate public policy domain. You should protect each URL or URL prefix you protected in web.xml, as follows:
Use "HTTP" as the resource type.
Specify the URL (for example, /foo).
The configuration must be under the form-based authentication scheme that you defined in "Configure Oracle Access Manager Form-Based Authentication".
See Also:
For information about protecting resources:Oracle Access Manager System Administration Guide
For a Web application, the OC4J implementation to support Oracle Access Manager requires the login module CoreIDLoginModule, supplied by Oracle. The following template shows the general form of the configuration, in the system-jazn-data.xml file. Note the <class> and <control-flag> element settings. Table 11-1 following describes the available options, followed by an example. Additional examples of specific scenarios and their configurations are shown later in this chapter.
Note:
By convention, as with other custom login modules, the<jazn> setting provider="XML" is used with the Oracle Access Manager login module.See Also:
Table 9-5, "Login Module Control Flags" for information about <control-flag> settings
<application>
<name>yourappname</name>
<login-modules>
<login-module>
<class>
oracle.security.jazn.login.module.coreid.CoreIDLoginModule
</class>
<control-flag>required</control-flag>
<options>
...
</options>
</login-module>
</login-modules>
</application>
Table 11-1 Oracle Access Manager Login Module Options
| Option Name | Required/Optional | Option Value |
|---|---|---|
|
addAllRoles |
Required |
This flag should be set to |
|
coreid.resoure.type |
Required |
Name of the resource type you defined through Policy Manager. See Also: "About Oracle Access Manager Resource Types" and "Configure the Name and Operation of the Resource Type" |
|
coreid.resource.operation |
Required |
Name of the resource operation associated with the resource type specified in See Also: "Configure the Name and Operation of the Resource Type" |
|
coreid.resource.name |
Required |
The URL prefix associated with the resource type specified in See Also: "Configure and Protect the URL of the Configured Resource Type" |
|
coreid.name.attribute |
Required |
Variable for the user name for authentication, as defined in the See Also: "About Oracle Access Manager Authentication" and "Configure the credential_mapping Plug-In for Form-Based Authentication" |
|
coreid.password.attribute |
Required (except when using X.509 token or SAML authentication) |
Variable for the password for authentication, as defined in the See Also: "Configure the validate_password Plug-In for Form-Based Authentication" |
|
coreid.name.header |
Optional |
If you use HTTP header variables for authentication, this parameter is the user name that OC4J should use to authenticate against the Oracle Access Manager Access Server. See Also: "About Using HTTP Header Variables for Authentication" and "Web Application Using HTTP Header Variables through Oracle Access Manager" |
|
coreid.password.header |
Optional |
If you use HTTP header variables for authentication, this parameter is the password that OC4J should use with the user name specified in |
Note:
The values ofcoreid.resource.type, coreid.resource.operation, and coreid.resource.name are determined during one-time Oracle Access Manager configuration, as described in "Configure the Resource Type", and are the same for any application using the same installation of Oracle Access Manager. Each application must have appropriate settings for these property values in its configuration for the Oracle Access Manager login module, which you can accomplish using Application Server Control or the OracleAS JAAS Provider Admintool.The following sample corresponds to the example that runs throughout "Configure Oracle Access Manager Form-Based Authentication", "Configure Oracle Access Manager Basic Authentication", and "Configure the Resource Type":
<application>
<name>foo</name>
<login-modules>
<login-module>
<class>
oracle.security.jazn.login.module.coreid.CoreIDLoginModule
</class>
<control-flag>required</control-flag>
<options>
<option>
<name>addAllRoles</name>
<value>true</value>
</option>
<option>
<name>coreid.resource.type</name>
<value>myresourcetype</value>
</option>
<option>
<name>coreid.resource.operation</name>
<value>myresourceoperation</value>
</option>
<option>
<name>coreid.resource.name</name>
<value>/myresourceurl</value>
</option>
<option>
<name>coreid.name.attribute</name>
<value>usernamevar</value>
</option>
<option>
<name>coreid.password.attribute</name>
<value>passwordvar</value>
</option>
</options>
</login-module>
</login-modules>
</application>
(This uses all supported options for the Oracle Access Manager login module except for coreid.name.header and coreid.password.header. Examples for these are shown later in this chapter.)
After you have deployed your Web application, restarted OC4J, and restarted Oracle HTTP Server, run the application. This example assumes Oracle HTTP Server listens on port 6666:
http://www.example.com:6666/foo
WebGate will intercept this request and will check the authentication scheme for this URL. The configuration shown earlier in this chapter will result in the user being prompted with the login.html login form from "Create a Login Form". Then the following sequence will take place:
WebGate will capture the user name and password from the login form and communicate to Access Server.
Access Server will communicate to Oracle Internet Directory (or other LDAP repository that you use).
After the user is authenticated, the Oracle Access Manager SSO token will be returned to WebGate.
WebGate will set the ObSSOCookie and pass the cookie and other HTTP headers to mod_oc4j, which will route the request to the appropriate OC4J instance.
OC4J will take the cookie and validate it, or retrieve roles for the user associated with this cookie from Access Server using the Access Manager SDK configured on OC4J.
You must grant any necessary permissions to any Oracle Access Manager principals that require privileges in your application. For an EJB application, this includes granting RMIPermission "login" for EJB access.
This section covers the following topics:
Granting RMI Permission to an Oracle Access Manager Principal
Granting Required Permissions to Additional Oracle Access Manager Principals
Confirming Configured Realm Names for Oracle Access Manager Principals
When using Oracle Access Manager for an EJB application, it is necessary to grant RMI permission "login" to an Oracle Access Manager principal for EJB access.
The following example uses the OracleAS JAAS Provider Admintool to accomplish this, assuming the principal name orcladmin:
% java -jar jazn.jar -grantperm oracle.security.jazn.realm.CoreIDPrincipal \
orcladmin com.evermind.server.rmi.RMIPermission login
This example would result in the following configuration in the system-jazn-data.xml file.
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jazn.realm.CoreIDPrincipal</class>
<name>orcladmin</name>
</principal>
</principals>
</grantee>
...
<permissions>
<permission>
<class>com.evermind.server.rmi.RMIPermission</class>
<name>login</name>
</permission>
...
</permissions>
...
</grant>
...
</jazn-policy>
Important:
Also refer to "Confirming Configured Realm Names for Oracle Access Manager Principals".When using Oracle Access Manager, authentication occurs at the Oracle Access Manager end, but JAAS authorization occurs at the OC4J end. (Other levels of authorization may occur at the Oracle Access Manager end.) For JAAS authorization in your application to be successful, the appropriate permissions must be granted to any Oracle Access Manager principals that are populated into your application subjects after authentication, and these grants must be stored in the system-jazn-data.xml file.
For this discussion, assume a principal BPMSystemAdmin requires the ServerPermission "server". The following example uses the OracleAS JAAS Provider Admintool to accomplish this:
% java -jar jazn.jar -grantperm oracle.security.jazn.realm.CoreIDPrincipal \
BPMSystemAdmin com.collaxa.security.ServerPermission server
This example would result in the following configuration in the system-jazn-data.xml file.
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jazn.realm.CoreIDPrincipal</class>
<name>BPMSystemAdmin</name>
</principal>
</principals>
</grantee>
...
<permissions>
<permission>
<class>com.collaxa.security.ServerPermission</class>
<name>server</name>
<actions>all</actions>
</permission>
...
</permissions>
...
</grant>
...
</jazn-policy>
Important:
Ensure that the permission class is in the classpath before you attempt to grant the permission.
Also refer to "Confirming Configured Realm Names for Oracle Access Manager Principals".
Here is a sample configuration for the BPMSystemAdmin role:
<role>
<name>BPMSystemAdmin</name>
<guid>3E9D3A5037A311DBBFA2B1BC62ED9FBC</guid>
<members>
<member>
<type>user</type>
<name>bpeladmin</name>
</member>
<member>
<type>user</type>
<name>oc4jadmin</name>
</member>
</members>
</role>
Notes:
The use of OC4J JAAS mode is supported for an application that uses Oracle Access Manager, in case that is required by your application in checking authorizations with respect to the permissions you have granted. Refer to "Introduction to JAAS Mode" and "Configuring and Using JAAS Mode" to gain an understanding of when and how to use this mode.
For authorization to work properly, also confirm that role mapping is set up appropriately, to correctly map deployment roles to J2EE logical roles. Refer to "Mapping Security Roles" for additional information.
In permissions configuration for Oracle Access Manager principals, each configured principal name must exactly match the principal name, including any realm name, as it comes over from Oracle Access Manager when the principal is populated into a subject.
For example, if BPMSystemAdmin is in the abc realm in Oracle Access Manager, then the principal name in system-jazn-data.xml must be exactly as follows:
<grantee>
<principals>
<principal>
<class>oracle.security.jazn.realm.CoreIDPrincipal</class>
<name>abc/BPMSystemAdmin</name>
</principal>
</principals>
</grantee>
Important:
When using Oracle Access Manager, do not attempt to use the Admintool addrealm option, which would result in incorrect realm information in the configuration. (This command is intended for only the file-based provider.)
If you encounter any difficulty, ensure that only the appropriate realm information is included in any principal names for permission grants in system-jazn-data.xml.
This section discusses special considerations when you use Oracle Access Manager to protect Oracle Application Server SOA applications such as Application Server Control and OWSM. The following topics are covered:
Configure Logout for Oracle Application Server SOA Applications
Troubleshooting Login to Oracle Application Server SOA Applications
For logout to work properly for Oracle Application Server SOA applications protected by Oracle Access Manager, complete the following steps (assuming Oracle HTTP Server is the Web server for Policy Manager):
Create a shared logout page for all the applications. Assuming the logout page is logout.html, you can accomplish this by copying logout.html to the Oracle HTTP Server Apache/Apache/htdocs directory.
Configure SSO logout to use the logout page "/logout.html". This registers this URL as the logout URL with Policy Manager. To accomplish this, navigate as follows in Policy Manager:
Access System Console > Access System Configuration > AccessGate Configuration > WebGate Configuration
Set LogOutURLs to: /logout.html
Make sure the logout page is not protected by WebGate, or is protected using the "none" authentication scheme.
Restart the Oracle HTTP Server instance that Policy Manager uses.
In the <jazn> element of the OC4J jazn.xml file, set the property custom.sso.url.logout to point to the logout page URL, such as:
<jazn ... > <property name="custom.sso.url.logout" value="/logout.html" /> ... </jazn>
Restart the OC4J instance.
Also ensure that the login page and logout page are in the same cookie domain, or that the cookies set during login and logout map to a shared domain.
If you try to log in to an Oracle Application Server SOA application (for example, using http://www.example.com:7778/ccore/index.html for OWSM), and the login hangs on the form login page after you enter your credentials, one possible cause is that there is a time-synch mismatch between the server running the SOA application (such as OWSM) and the server running Oracle Access Manager. In this case, WebGate will fail to successfully create a session for the user. If you experience this, the administrator should confirm that both systems are synchronized.
This section discusses the following Oracle Access Manager usages for Web applications and EJBs:
You can optionally configure a Web application to use HTTP header variables for authentication. The header variable for user name corresponds to the coreid.name.header option in the Oracle Access Manager login module configuration. The header variable for password corresponds to the coreid.password.header option.
You must execute the following steps to use these header variables:
Use Policy Manager to enable the credential_mapping and validate_password plug-ins.
See Also:
"Configure the credential_mapping Plug-In for Form-Based Authentication" and "Configure the validate_password Plug-In for Form-Based Authentication"
Oracle Access Manager System Administration Guide for information about using HTTP header variables
Include option settings for coreid.name.header and (as appropriate) coreid.password.header in the Oracle Access Manager login module configuration in system-jazn-data.xml. In the following example, password authentication is used. Assume the desired HTTP header variables are myhttpuservar and myhttppwdvar:
<options>
...
<option>
<name>coreid.name.header</name>
<value>myhttpuservar</value>
</option>
<option>
<name>coreid.password.header</name>
<value>myhttppwdvar</value>
</option>
...
</options>
Note:
When using HTTP header variables, be aware that option settings forcoreid.name.attribute and coreid.password.attribute are still required, in addition to settings for coreid.name.header and coreid.password.header.Define appropriate security constraints in your standard Web application configuration, and set auth-method="COREIDSSO" in orion-application.xml as shown in "Configure Oracle Access Manager SSO in orion-application.xml".
When no HTTP header variables are provided for a secure Web application, the Oracle Access Manager ObSSOCookie is used to retrieve authentication information. By default, this cookie contains the cookie in the HTTP header.
You must execute the following steps to use the cookie:
Include option settings for coreid.name.attribute and (as appropriate) coreid.password.attribute in the Oracle Access Manager login module configuration in system-jazn-data.xml. In the following example, password authentication is used. Assume the user name and password variables you defined for the credential_mapping and validate_password plug-ins are usernamevar and passwordvar:
<options>
...
<option>
<name>coreid.name.attribute</name>
<value>usernamevar</value>
</option>
<option>
<name>coreid.password.attribute</name>
<value>passwordvar</value>
</option>
...
</options>
Define appropriate security constraints in your standard Web application configuration, and set auth-method="COREIDSSO" in orion-application.xml as shown in "Configure Oracle Access Manager SSO in orion-application.xml".
For EJB authentication, OC4J gets the user name and password from the EJB context and passes them to the Oracle Access Manager login module. The same user name and password are used to authenticate against Oracle Access Manager. The EJB scenario requires both the credential_mapping plug-in and the validate_password plug-in, discussed earlier in this chapter. The user name and password variables you define for the plug-ins must be reflected in option settings for the Oracle Access Manager login module, as discussed in "Configure Oracle Access Manager Form-Based Authentication".
The client must send the user name and password for authenticating itself before it can access the EJB.
Configure the Oracle Access Manager login module. Assume Oracle Access Manager authentication variables are as follows:
myejbappname is the name of the EJB application.
myejbusernamevar is the variable name for the EJB user name, as you define in the credential_mapping plug-in.
myejbpwdvar is the variable name for the EJB user password, as you define in the validate_password plug-in.
<application> <name>myejbappname</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>myejbusernamevar</value> </option> <option> <name>coreid.password.attribute</name> <value>myejbpwdvar</value> </option> </options> </login-module> </login-modules> </application>
Note:
In the current release there is no direct support for a scenario where Oracle Access ManagerObSSOCookie is sent instead of the user name and password for authentication.See Also:
"Configure the Resource Type" for information about coreid.resource.type, coreid.resource.operation, and coreid.resource.name
Web services can use Oracle Access Manager for authenticating Web service clients. With respect to Oracle Access Manager, OC4J supports username token authentication, X.509 token authentication, and SAML token authentication, as follows:
Username token: OC4J extracts the user name and password, and uses them to authenticate against Oracle Access Manager.
X.509 token: OC4J uses the CN value of the X.509 entry to authenticate against Oracle Access Manager.
SAML token: OC4J uses the subject name to authenticate against Oracle Access Manager.
The following usages are shown below:
Web Service with Username Token Authentication for Oracle Access Manager
Web Service with X.509 Token Authentication for Oracle Access Manager
Web Service with SAML Token Authentication for Oracle Access Manager
Note:
In the current release there is no direct support for a scenario where the Oracle Access ManagerObSSOCookie is sent instead of the user name and password for authentication.See Also:
Oracle Application Server Web Services Security Guide for general information about username token, X.509 token, and SAML token authentication
A username token client uses the user name and password for authentication. You must configure variables for the user name and password through the Oracle Access Manager credential_mapping and validate_password plug-ins, with corresponding settings for the coreid.name.attribute and coreid.password.attribute options in the Oracle Access Manager login module configuration, as discussed in "Configure Oracle Access Manager Form-Based Authentication".
Configure the login module as follows, assuming these settings:
UsernameAppName is the name of the Web service application using username token authentication.
UsernameNamevar is the variable name for the user name, as you define in the credential_mapping plug-in.
UsernamePwdvar is the variable name for the user password, as you define in the validate_password plug-in.
<application> <name>UsernameAppName</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>UsernameNamevar</value> </option> <option> <name>coreid.password.attribute</name> <value>UsernamePwdvar</value> </option> </options> </login-module> </login-modules> </application>
See Also:
"Configure the Resource Type" for information about coreid.resource.type, coreid.resource.operation, and coreid.resource.name
An X.509 client uses the CN value from the X.509 entry for authentication. You must configure a variable for the CN user name through the Oracle Access Manager credential_mapping plug-in, with a corresponding setting for the coreid.name.attribute option in the Oracle Access Manager login module configuration, as discussed in "Configure Oracle Access Manager Form-Based Authentication".
Do not configure the Oracle Access Manager validate_password plug-in or set the login module coreid.password.attribute option when X.509 token authentication is used.
Configure the login module as follows, assuming these settings:
X509AppName is the name of the Web service application using X.509 token authentication.
cn_name_var is the variable name for the CN user name, as you define in the credential_mapping plug-in.
<application> <name>X509AppName</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>cn_name_var</value> </option> </options> </login-module> </login-modules> </application>
See Also:
"Configure the Resource Type" for information about coreid.resource.type, coreid.resource.operation, and coreid.resource.name
For a SAML client, OC4J determines the subject name, and you must configure a variable name for SAML subject authentication through the Oracle Access Manager credential_mapping plug-in. This credential_mapping setting must be reflected in the setting of the coreid.name.attribute option in the Oracle Access Manager login module configuration, as discussed in "Configure Oracle Access Manager Form-Based Authentication". OC4J passes the subject name and credential_mapping variable name to Oracle Access Manager for authentication.
Do not configure the Oracle Access Manager validate_password plug-in or set the login module coreid.password.attribute option when SAML authentication is used.
Configure the login module as shown below, assuming these settings:
SAMLAppName is the name of the Web service application using SAML token authentication.
subject_name_var is the variable for the subject name, as you define in the credential_mapping plug-in.
In the SAML scenario, there is also a SAML login module, SAMLLoginModule, that you must configure along with the CoreIDLoginModule login module, as follows. This example uses www.example.com for the issuer name.
Important:
TheSAMLLoginModule configuration must precede the CoreIDLoginModule configuration in system-jazn-data.xml.<application> <name>SAMLAppName</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.saml.SAMLLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>issuer.name.1</name> <value>www.example.com</value> </option> </options> </login-module> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>subject_name_var</value> </option> </options> </login-module> </login-modules> </application>
See Also:
"Configure the Resource Type" for information about coreid.resource.type, coreid.resource.operation, and coreid.resource.name
Oracle Application Server Web Services Security Guide for information about the SAMLLoginModule
Table 11-2 provides some troubleshooting tips for your Oracle Access Manager setup and configuration.
Table 11-2 Oracle Access Manager Troubleshooting
| Problem | Cause/Solution |
|---|---|
|
The application is configured to use Oracle Access Manager SSO. When you try to access the application, Access Server crashes and restarts. |
This will happen if you have configured the incorrect search base in Oracle Internet Directory, or the group name is not properly created. |
|
When you try to access the Oracle Access Manager SSO application, it throws a Class Not Found exception. |
Confirm you copied the Oracle Access Manager file |
|
When you try to access the Oracle Access Manager SSO application, it gives an internal server error. |
Confirm that the Access Manager SDK installed on the OC4J server is configured to use the appropriate Access Server, as discussed in "Configure the Access Manager SDK to Each OC4J Instance". Also confirm that OC4J is running. |
|
When you try to access the Oracle Access Manager SSO application, it does not appear in the login page. |
Confirm you have enabled your authentication scheme with proper settings, using Policy Manager, as discussed in "Configure Oracle Access Manager Form-Based Authentication". |
|
When you try to access the Oracle Access Manager SSO application, the login page keeps coming back. |
Confirm that the form-based authentication scheme is enabled, that the form variable names (for user and password) in your login page are the same as you configured in the Oracle Access Manager form-based authentication scheme, and that the credential mapping scheme and password validation scheme are configured for the form-based authentication scheme. Refer to "Configure Oracle Access Manager Form-Based Authentication". |
|
You have configured the application to use Oracle Access Manager, but you always get an "unauthorized" or "unauthenticated" error. |
Confirm that the Oracle Access Manager login module is correctly configured for this application in |
|
You have configured the application to use Oracle Access Manager, but you get an internal server error. |
Confirm that the LDAP server (Oracle Internet Directory, for example) that is configured with the Oracle Access Manager Identity Server is running and accessible. |
|
You have configured the application to use Oracle Access Manager SSO, but when you attempt to access it, after you enter the user name and password, the application hangs. |
Confirm that the action URL used in the form page is protected with an authentication scheme without password, such as the basic scheme. (Protecting the action URL with a password-protected authentication scheme results in an execution loop.) See "Create a Login Form". |
|
 Copyright © 2003, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|