10 COREid Access Security Provider

Overview of Oracle COREid Access and Identity

Oracle COREid Access and Identity 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 OracleAS Single Sign-On), personalization, and user profile management in heterogeneous application environments across a variety of application servers, legacy applications, and databases. COREid 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, COREid 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 COREid Access and Identity 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 COREid Access and Identity instance, allowing centralized single sign-on and auditing functionality, as well as more robust authentication options.

• COREid offers superior identity administration through workflow, fine-grained attribute control, and delegation of administration.

• COREid supports access control based on dynamic groups, with members based on a given identity profile.

• COREid allows realtime access and identity integration, with runtime changes made through COREid being automatically populated into the Access Server cache to eliminate security loopholes.

In the OC4J 10.1.3 implementation, OracleAS JAAS Provider supports Oracle COREid Access and Identity integration through a custom login module and a special authentication method setting.

Oracle COREid Access and Identity 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 COREid Access 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 a COREid server.

• COREid 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.

• Access Manager writes policy data to Oracle Internet Directory, and updates the Access Server with policy modifications. It includes an Access System Console that enables administrators to manage policies and the system configuration.

COREid Prerequisites

This section describes what you must have installed to use Oracle COREid Access and Identity. Oracle COREid Access and Identity components are version 7.0.4.

At a high level, prerequisites include installing Oracle COREid Access and Identity and Oracle Application Server, and configuring the Access SDK and your applications on OC4J.

Detailed requirements on the COREid side:

1. A suitable LDAP repository, such as Oracle Internet Directory (included in the Oracle Application Server 10.1.2 infrastructure).

2. A Web server, such as Oracle HTTP Server (included in the Oracle Application Server 10.1.3 middle-tier infrastructure).

3. The COREid Identity Server and Access Server. When you install Oracle COREid Access and Identity, you will be asked to specify the LDAP repository you are using, which must be accessible for communication with COREid Identity Server and Access Server during runtime.

4. COREid WebGate, WebPass, and Access Manager installed on the Web server. WebGate is the SSO interceptor and communicates with Access Server during runtime. WebPass communicates with COREid Identity Server. Access Manager communicates with the LDAP repository. When you install WebGate and WebPass, you will be asked to specify the Access Server and COREid Identity Server you are using.

Detailed requirements on the OC4J side:

1. Oracle Application Server 10.1.3 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 COREid side, which may or may not be Oracle HTTP Server.

   Using the COREid Access security provider requires Oracle HTTP Server; you cannot use standalone OC4J.

2. COREid WebGate installed on this Oracle HTTP Server.

3. Additional OC4J instances as needed. Typically, when using COREid 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.

4. COREid Access SDK, one for each OC4J instance, on the same system as OC4J. The Access SDK is required by OC4J at runtime to communicate with Access Server.

The next section, "COREid Architecture", shows how the Oracle COREid Access and Identity components fit with key components of the Oracle Application Server middle-tier infrastructure.

COREid Architecture

Figure 10-1 shows the Oracle COREid Access and Identity architecture.

Figure 10-1 COREid Architecture

Description of "Figure 10-1 COREid Architecture"

Top-Level Summary of Configuration Stages

There are three stages of configuration steps to use OC4J applications with the COREid Access security provider:

1. One-time configurations for the COREid installation. This includes setting up authentication schemes and configuring a COREid resource type. Refer to "Configuring COREid Access".

2. Configurations for each OC4J instance. This includes configuring each OC4J instance with an Access SDK installation. Refer to "Configuring OC4J with the Access SDK".

3. Configurations for your application. This includes web.xml settings, deployment-time settings, orion-application.xml settings (pre- or post-deployment), and JAAS login module settings. Refer to "Configuring the Application".

Running the Access Manager

Several of the configuration steps documented later in this chapter involve running the COREid Access Manager. Run it with a URL such as the following, then log in:

http://host:port/access/oblix

This will put you at the Access System Console, used frequently in this chapter.

About COREid Resource Types

In Oracle COREid Access and Identity, 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 COREid Access and Identity 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 SDK, and the SDK expects some resource type and resource operation to be specified. For this reason, when you configure the COREid login module, you must configure a custom COREid 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

About COREid Authentication

In order to validate any user, COREid must be configured with an authentication scheme. An authentication scheme consists of plug-ins.

OC4J support for Oracle COREid Access uses the COREid 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 COREid Access:

• Use of the COREid SSO cookie, ObSSOCookie, discussed further in the next section, "About the COREid 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"

About the COREid Single Sign-On Cookie

Oracle COREid Access 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, COREid uses the cookie for subsequent requests instead of prompting the user to supply authentication credentials.

OC4J uses the ObSSOCookie to connect to the COREid Access Server and retrieve user roles.

About Using HTTP Header Variables for Authentication

COREid 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 COREid ObSSOCookie as discussed in the preceding section.)

To use this mode, you must configure the COREid login module with this user name and password (as discussed in "Configure the COREid JAAS Login Module") for OC4J to use in accessing the COREid 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 COREid and other applications. For example, if COREid and other applications combine to use 1K in the HTTP header, you would have 3K for your data.

Configure COREid Form-Based Authentication

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 COREid Basic Authentication".)

The steps here are to create and protect a login page for form-based authentication in Oracle COREid Access and Identity, for use by WebGate in protecting your resource. You will later configure your application to be protected by this form-based authentication.

1. Create a Login Form

2. Define Form-Based Authentication in Access Manager

3. Configure the credential_mapping Plug-In for Form-Based Authentication

4. Configure the validate_password Plug-In for Form-Based Authentication

<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>

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

obMappingBase="cn=users,dc=us,dc=oracle,dc=com",obMappingFilter="(&(&
(objectclass=inetorgperson)(uid=%usernamevar%))(|(!
(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))"

obCredentialPassword="passwordvar"

Configure COREid Basic Authentication

You must configure the COREid 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 COREid login module will use this URL to communicate to the Access Server through the Access SDK.

• The action URL for the form page, noted in "Create a Login Form" and "Define Form-Based Authentication in Access 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 COREid Form-Based Authentication".)

These steps define basic authentication, without a password, to protect the resource.

1. Define Basic Authentication in Access Manager

2. Configure the credential_mapping Plug-In for Basic Authentication

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

obMappingBase="cn=users,dc=us,dc=oracle,dc=com",obMappingFilter="(&(&
(objectclass=inetorgperson)(uid=%usernamevar%))(|(!
(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))"

Configure the Resource Type

In Oracle COREid Access and Identity, 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 COREid Access and Identity 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 Access Manager and described below:

1. Configure the Name and Operation of the Resource Type

2. Configure and Protect the URL of the Configured Resource Type

3. Configure the Return Action Attributes

The COREid 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 COREid Access and Identity ObSSOCookie or the user name, using APIs of the Access 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.

Resource Name:        myresourcetype
Display Name:         My Resource Type Display Name
Resource Matching:    Case Insensitive 
Resource Operation:   myresourceoperation

Resource Type:      myresourcetype
Host Identifiers:   myhost
URL Prefix:         /myresourceurl
Description:        My Description

Return Type:      myresourcetype
Return Name:      myresourcetype
Return Attribute: ObMyGroups

Protect the Action URL

Using Access Manager, protect the action URL you specified in "Configure COREid 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 COREid Basic Authentication".

• Use "HTTP" as the resource type.

• Specify the action URL (/coreid/access/test.html in the examples).

Create OC4J Instances as Needed

Typically, when using COREid 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:

1. Create new OC4J instances as desired, using the createinstance utility as described in the Oracle Containers for J2EE Configuration and Administration Guide.

2. 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.

Configure the Access SDK to Each OC4J Instance

You will need COREid Access SDK, one installation for each OC4J instance, on the same system as OC4J. The Access SDK is required by OC4J at runtime to communicate with Access Server. OC4J must be given the Access 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 COREid Access as the security provider. Also note the following:

1. Create a separate Access SDK installation for each OC4J instance, on the same system as OC4J. You can have multiple Access SDK installations on the same system.

2. Configure each Access SDK to work with the appropriate Access Server. From the 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.

3. Copy the COREid file jobaccess.jar from the Access 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.

Configure the Access SDK Library Path for Each OC4J Instance

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 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

Protect the Application URLs in web.xml

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 COREid configuration in "Protect the Application URLs in COREid Access".

Settings for Application Deployment

In the Oracle Application Server 10.1.3 implementation, Application Server Control does not yet support COREid Access 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.

Configure COREid SSO in orion-application.xml

To use COREid 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.

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>

Protect the Application URLs in COREid Access

Use Access 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:

Access 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:

1. Use "HTTP" as the resource type.

2. Specify the URL (for example, /foo).

3. The configuration must be under the form-based authentication scheme that you defined in "Configure COREid Form-Based Authentication".

Configure the COREid JAAS Login Module

For a Web application, the OC4J implementation to support Oracle COREid Access and Identity 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 10-1 describes the available options. Examples of specific scenarios and their configurations are shown later in this chapter.

<application>
   <name>yourappname</name>
   <login-modules>
      <login-module>
         <class>
            oracle.security.jazn.login.module.coreid.CoreIDLoginModule
         </class>
         <control-flag>required</control-flag>
         <options>
            <option>
               <name>option1name</name>
               <value>option1value</value>
            </option>
            <option>
               <name>option2name</name>
               <value>option2value</value>
            </option>

            ...

         </options>
      </login-module>
   </login-modules>
</application>

The following sample corresponds to the example that runs throughout "Configure COREid Form-Based Authentication", "Configure COREid 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 COREid login module except for coreid.name.header and coreid.password.header. Examples for these are shown later in this chapter.)

Test the Application

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:

1. WebGate will capture the user name and password from the login form and communicate to Access Server.

2. Access Server will communicate to Oracle Internet Directory (or other repository that you use).

3. After the user is authenticated, the COREid SSO token will be returned to WebGate.

4. 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.

5. OC4J will take the cookie and validate it, or retrieve roles for the user associated with this cookie from Access Server using the Access SDK configured on OC4J.

Web Application Using HTTP Header Variables through COREid

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 COREid 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:

1. Configure HTTP Header Variables in Access Manager

2. Configure HTTP Header Variables for the COREid Login Module

3. Secure the Web Application

<options>
   ...
   <option>
      <name>coreid.name.header</name>
      <value>myhttpuservar</value>
   </option>
   <option>
      <name>coreid.password.header</name>
      <value>myhttppwdvar</value>
   </option>
   ...
</options>

Web Application Using the COREid ObSSOCookie

When no HTTP header variables are provided for a secure Web application, the COREid 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:

1. Configure User Name and Password for the COREid Login Module

2. Secure the Web Application

<options>
   ...
   <option>
      <name>coreid.name.attribute</name>
      <value>usernamevar</value>
   </option>
   <option>
      <name>coreid.password.attribute</name>
      <value>passwordvar</value>
   </option>
   ...
</options>

EJB Application Using COREid

For EJB authentication, OC4J gets the user name and password from the EJB context and passes them to the COREid login module. The same user name and password are used to authenticate against Oracle COREid Access and Identity. 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 COREid login module, as discussed in "Configure COREid Form-Based Authentication".

The client must send the user name and password for authenticating itself before it can access the EJB.

Configure the COREid login module, where COREid Access 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>

Web Service with Username Token Authentication for COREid

A username token client uses the user name and password for authentication. You must configure variables for the user name and password through the COREid credential_mapping and validate_password plug-ins, with corresponding settings for the coreid.name.attribute and coreid.password.attribute options in the COREid login module configuration, as discussed in "Configure COREid Form-Based Authentication".

Configure the COREid login module as follows, where:

• 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>

Web Service with X.509 Token Authentication for COREid

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 COREid credential_mapping plug-in, with a corresponding setting for the coreid.name.attribute option in the COREid login module configuration, as discussed in "Configure COREid Form-Based Authentication".

You do not configure the COREid validate_password plug-in or set the login module coreid.password.attribute option when X.509 token authentication is used.

Configure the COREid login module as follows, where:

• 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>

Web Service with SAML Token Authentication for COREid

For a SAML client, OC4J determines the subject name, and you must configure a variable name for SAML subject authentication through the COREid credential_mapping plug-in. This credential_mapping setting must be reflected in the setting of the coreid.name.attribute option in the COREid login module configuration, as discussed in "Configure COREid Form-Based Authentication". OC4J passes the subject name and credential_mapping variable name to COREid for authentication.

You do not configure the COREid validate_password plug-in or set the login module coreid.password.attribute option when SAML authentication is used.

Configure the COREid login module as shown below, where:

• 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 COREid login module, as follows. This example uses www.example.com for the issuer name.

<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>