8 Managing Policy Components

Shared policy components can be used in any OAM policy. This chapter describes how administrators can manage policy components.

This chapter includes the following topics:

Prerequisites

An OAM Administration Console and at least one OAM Server must be installed and running within a WebLogic Server domain.

Oracle recommends that you review the following topics before performing activities in this chapter.

Introduction to Managing Policy Components

This section introduces the Oracle Access Manager 11g policy model and the global components within it.

The Oracle Access Manager 11g policy model provides both authentication and authorization services within the context of an OAM application domain. The policy model relies on external user identity stores and on authentication modules, which are a part of the overall system configuration.

Note:

Earlier releases of Oracle Access Manager provided authentication and authorization services within the context of an OAM policy domain. OracleAS SSO 10g provides only authentication.

Figure 8-1 illustrates the different elements within the policy model for Oracle Access Manager 11g. The top-level construct of the Oracle Access Manager 11g policy model is the OAM application domain. Additional information follows the figure.

Figure 8-1 Policy Components: Relationship to an Application Domain

Oracle Access Manager 11g Policy Model

Policy Components: Global authentication schemes, resource types, and host identifiers that can be used in any application domain. Managing policy components is described throughout this chapter

Application Domains: A logical container for resources (or sets of resources), and the associated authentication and authorization policies that dictate who can access specific resources. The size and number of application domains is up to the administrator. For details, see Chapter 9, "Managing Policies to Protect Resources and Enable SSO".

Managing Resource Types

This section includes the following topics:

About Resource Types and Their Use

When adding a resource to an application domain, administrators must choose from a list of defined Resource Types. then enter a specific URL. For HTTP type resources, include a host identifier. For non-HTTP resource types, use the type name.

The default resource type, HTTP, is used with HTTP and HTTPS protocols. Operations associated with the HTTP resource type need not be defined by an administrator. Instead, policies developed and applied to the resource apply to all operations.

When adding an HTTP type resource to an application domain, administrators must choose from a list of existing host identifiers and add the resource URL.

Administrators can define a resource type for non-HTTP resources. Non-HTTP resource types have no associated host identifier. When adding non-HTTP resources to an application domain, administrators must enter the type name into the Resource URL field as a pointer. The name cannot match any host Identifier (and vice versa). This is not a relative HTTP URL.

For instance, a non-HTTP resource type named wl_authen is available to use with resources deployed in a WebLogic container. Resources of type wl_authen, require a custom AccessGate. The protected resource is accessed using its URL on the Oracle WebLogic Server.

About the Resource Type Page

In the OAM Administration Console, resource types are organized with other Components under the Policy Configuration tab, as shown in Figure 8-2. The navigation tree on the left shows two default resource types: HTTP for internet protocols and wl_authen for resources deployed in a WebLogic container.

Figure 8-2 The Default wl_authen Resource Type Definition

Resource Type Definition
Description of "Figure 8-2 The Default wl_authen Resource Type Definition"

The HTTP resource type is used for Web applications protected by Oracle Access Manager 11g.

The wl_authen resource type is used for Fusion Middleware application scenarios in combination with in Oracle Access Manager 11g and one of the following OAM Authentication Provider configurations, as described in the Oracle Fusion Middleware Application Security Guide.

  • Authenticator

  • Identity Asserter with Oracle Web Services Manager

Table 8-1 describes the elements in the resource type definition.

Table 8-1 Resource Type Definition

Element Description

Name

Required. A unique name of up to 30 alpha or numeric characters.

Note: A non-HTTP Resource Type name cannot match a Host Identifier (and vice versa).

Description

Optional. Use this field to describe the purpose of this resource type using up to 200 alpha or numeric characters.

For example: Resources representing WebLogic Authentication schemes.

Following topics describe how to create, modify, and delete a resource type.

Creating a Non-HTTP Resource Type

Users with valid OAM Administrator credentials can use the following procedure to create a new resource type definition for non-HTTP resources, as explained in "About Resource Types and Their Use".

In this case, there is no host identifier associated with the resource type. Instead, you must enter a name into the field. Any resource type with name other than HTTP is considered non-HTTP.

See Also:

About the Resource Type Page

To create a non-HTTP resource type

  1. From the Policy Configuration tab, navigation tree, Shared Components node, click Resource Type, then click the Create command button in the tool bar.

  2. Fill in fields on the Resource Type page to identify this new type:

    1. Name:

    2. Description (optional)

  3. Click Apply to submit the new resource type (or close the page without applying changes).

  4. Close the Confirmation window.

  5. Close the Resource Type page.

Searching for a Specific Resource Type

Users with valid OAM Administrator credentials can use the following procedure to locate a non-HTTP resource type.

To search for a resource type

  1. Activate the Policy Configuration tab.

  2. From the search type list, choose Resource Type to define your search.

  3. In the text field, enter the exact name of the instance you want to find. For example:

    my_resource_type

  4. Click the Search button to initiate the search.

  5. Click the Search Results tab to display the results table, and then:

    • Edit: Click the Edit button in the tool bar to display the configuration page.

    • Delete: Click the Delete button in the tool bar to remove the instance; confirm removal in the Confirmation window.

    • Detach: Click Detach in the tool bar to expand the table to a full page.

    • View: Select a View menu item to alter the appearance of the results table.

  6. Click the Browse tab to return to the navigation tree when you finish with the Search results.

Deleting Resource Types

Users with valid OAM Administrator credentials can use the following procedure to remove a non-HTTP resource type only. A validation error occurs if you attempt to delete a resource type that is being used by a resource in an application domain.

Prerequisites

Each resource in an application domain has an assigned type. If you intend to delete the assigned resource type you must first modify the resource definition in an application domain that uses this resource type

Note:

You cannot remove default resource types HTTP or wl_authen.

To remove a resource type

  1. From the Policy Configuration tab, Shared Components node, double-click the name of the Resource Type to confirm the definition, and then close the page.

  2. Click the name in the navigation tree, click the Delete button in the tool bar, and confirm removal in the Confirmation window.

  3. Confirm that the Resource Type is removed.

Managing Host Identifiers

This section describes host identifiers and their use as well as how to create, modify, or remove a host identifier. Topics here include:

About Host Identifiers

Policies protect resources on computer hosts. Within Oracle Access Manager, the computer host is specified independently using a host identifier.

Based on a defined host identifier, administrators can add specific resources to an application domain and apply policies to protect those resources.

Registered Agents protect all requests that match the addressing methods defined for the host identifier used in a policy. A request sent to any address on the list is mapped to the official host name and OAM can apply the policies that protect the resource and OAM can apply the policies that protect the resource.

A host identifier is automatically created when an Agent (and application) are registered using either the OAM Administration Console or the remote registration tool. Administrators can manually add a host identifier if an application and resources exist on a host that does not have a mapped host identifier. Also, administrators can modify an existing host identifier to add in the new host name variations. For instance, adding another proxy Web server with a different host name requires a new host name variation.

For more information, see:

Host Identifier Usage

At design time, the host identifier can be used while defining which resources belong to a specific application domain. Resources are scoped using their host identifier (HTTP) or type (non-HTTP). This combination uniquely identifies them across Oracle Access Manager.

Note:

Each resource should be unique across all application domains; each resource and host identifier combination must be unique across all application domains.

Runtime Usage

At run time, Web server host information in the access query from an OAM agent is mapped to a host identifier and associated with the resource that is being accessed by a user. The OAM agent obtains the Web server host information in one of two ways:

  • If the Preferred Host parameter is configured for virtual Web hosting support (see"About Virtual Web Hosting"), Web server host information for the given request is obtained from the Web server.

  • If the Preferred Host parameter directly specifies the Web server host information, it is always used irrespective of the Web server's own host information.

This allows for the Resources to be specified in terms of logical host names in their Host Identifiers, instead of the host names matching the present deployment of the Web server.

A user accessing aseng-wiki, would enter:

http://aseng-wiki.us.oracle.com/mywikipage

Here, "mywikipage" is the resource URL and "aseng-wiki.us.oracle.com" is the host. Matching this host and port (port is 80) provides the host identifier.

Preferred Host

Web server host information is generally acquired by setting the Preferred Host string of the OAM Agent. If the Agent is actively protecting multiple virtual hosts, this string can be set to server_name to ensure that the actual request hostname is correctly picked up from the Web server's request object. For more information, see "About Virtual Web Hosting"

Authenticating Hosts and Challenge Redirect in Authentication Schemes

When a user attempts to access a protected resource URL, she is redirected to the server specified in the Challenge Redirect field of the authentication scheme. If the authentication challenge is to be processed by another host, the name of that host must be defined to be available in the Host Identifiers list. For example, if a user is redirected to an SSL-enabled server for authentication, that server must be defined as a host identifier.

Note:

If you enter a host name in the Challenge Redirect field of an authentication scheme, it must be defined as a Host Identifier.

Host Identifier Guidelines

Each host identifier can be defined to represent one or more Web server hosts. Following are several important guidelines for host identifiers:

  • Each host name must be unique.

  • Each host name:port pair must be unique.

  • Each host name:port pair must belong to only one host identifier.

  • Each host name:port pair must match the end user's entry exactly.

  • A Host Identifier name cannot match a non-HTTP Resource Type name (and vice versa).

  • Each resource and host identifier combination must be unique across all application domains.

For more information, see "Host Identifier Variations".

Host Identifier Variations

Host identifiers are used to simplify the identification of a Web server host by defining all possible hostname variations. Host identifiers consist of a list of all URL addressing methods. A host identifier must be configured for each Web site or virtual Web site that you want to protect with Oracle Access Manager.

You can identify Web server hosts to Oracle Access Manager in various ways, for example, by providing a computer name or an IP address. The following are examples of how the same host can be addressed:

  • site.com

  • site.com:80

  • www.site.com

  • www.site.com:80

  • 216.200.159.58

  • 216.200.159.58:80

About Virtual Web Hosting

A virtual host referees to the situation where the same host has multiple sites being served either based on multiple NIC cards (IP based) or multiple names (for example, abc.com and def.com resolving to same IP).

Consider a use case where you have two virtual hosts configured on an OHS Server acting as reverse proxy to OAM Server, as follows:

  • One virtual host is configured in two-way SSL mode

  • One virtual host configured in non-SSL mode

Suppose there are two resources protected with different authentication schemes and application domains:

  • /resource1 is protected by a X509Scheme with a Challenge URL (to define the credential collection URL) of https://sslvhost:port/

    When the user accesses /resource1 he is redirected to the OHS Server on the SSL port for authentication and is asked for the X.509 Certificate.

  • /resource2 is protected by a LDAPScheme on the second virtual host with a Challenge Redirect of http://host:port/

    When user accesses /resource2 he is redirected to second virtual host which is in non-SSL mode (or in one way SSL mode if required). The Login form for LDAP authentication is displayed.

Note:

Your deployment can support X.509 and Form authentication with 10g mod_osso. However, mod_osso can be configured for only one SSO Server. In this case, the Agent redirects to Oracle Access Manager on the non-SSL virtual host. The credential collector checks the Authentication Scheme's Challenge URL parameter for the resource and redirects back to the HTTPS virtual host for X509 authentication.

To support virtual Web hosting, you must specify a specific value, described in the following paragraphs, in the Preferred HTTP host field of the OAM Agent registration. The following summarizes configuration for virtual servers:

  • To support virtual hosts on most Web servers other than Apache-based servers, you must set the Preferred HTTP Host value to HOST_HTTP_HEADER.

    If you specify this value, when user's browser sends a request, the WebGate sets the value of the Preferred HTTP Host to the host value in the request. For example, suppose a user enters the string myweb2 in a URL:

    http://myweb2

    On the Web server, if one of the Web sites has a host named myweb2, the request is served by the matching virtual site.

  • On Apache-based servers, for example, Apache, Apache 2, IBM HTTP Server, Oracle HTTP Server, and so on, the Preferred HTTP Host value must be set to SERVER_NAME.

Note:

The SERVER_NAME value is not supported for any host other than an Apache-based server. If you set this value for a non-Apache-based server, users will be unable to access any resources that are protected by WebGate on that Web server. Users will, instead, receive an error that the WebGate configuration is incorrect.

The "ServerName" directive needs to be explicitly set with 7777 along with the hostName. This is irrespective of the "Listen" directive is set correctly. The Server sometimes requires this value explicitly to identify itself, most often it can identify itself automatically.

About the Host Identifier Page

A host identifier is automatically created when an Agent (and application) are registered using either the OAM Administration Console or the remote registration tool. In the application domain that is registered with the Agent, the host identifier is used automatically.

Administrators can use the console to create and manage host identifiers. Within the OAM Administration Console, host identifiers are organized under Shared Components, on the Policy Configuration tab navigation tree. Administrators can manually create a new host identifier definition, modify a definition, delete a definition, or copy an existing definition to use as a template. The name of the copy is based on the original definition name. For example, if you copy a definition named host3, the copy is named copy of host3.

Figure 8-3 illustrates a typical Host Identifier configuration page in the Administration Console, where you enter the canonical name for the host, and every other name by which the same host can be addressed by users.

Note:

Each host identifier must be unique. You cannot use the same host name and port in any other host identifier definition.

Figure 8-3 Host Identifier Page

Host Identifier Configuration Page

Table 8-2 describes the host identifier definition.

Table 8-2 Host Identifier Definition

Property Description

Name

A unique name for this definition. Use only upper- and lower-case alpha characters. No punctuation or special characters are allowed.

Description

The optional description, up to 200 characters, that explains the use of this configuration.

Operations

Creating a Host Identifier

Users with valid OAM Administrator credentials can use the following procedure to create a host identifier definition. This is needed if an application and resources were manually added to a host that has no mapped host identifier.

Note:

If you copy an existing definition to use as a template, you must modify all unique identifiers in the copy.

See Also:

"About Host Identifiers"

To manually create a Host Identifier

  1. From the Policy Configuration tab, navigation tree, expand Shared Components.

  2. Click Host Identifiers, then click the Create command button in the tool bar.

    Alternatively: Expand the Host Identifiers node, double-click the name of a definition to use as a template, then click the Duplicate button to create a copy named copyofname.

  3. On the Host Identifier page, fill in the:

    1. Name

    2. Description

    3. Operations: Add (or remove) host name and port variations in the Operations list.

      Add: Click + and enter a new host name and port combination.

      Remove: Click a host name, then click the Delete button to remove it.

  4. Repeat step 3c as needed to identify all variations of this host that users can access.

  5. Click Apply to submit the new definition (or close the page without applying changes).

  6. Close the Confirmation window, and confirm the new definition is listed in the navigation tree.

Searching for a Host Identifier Definition

Users with valid OAM Administrator credentials can perform the following task to search for a specific host identifier.

See Also:

"About Search Controls"

To search for a host identifier

  1. Activate the Policy Configuration tab.

  2. From the search type list, choose Host Identifiers to define your search.

  3. In the text field, enter the exact name of the instance you want to find. For example:

    my_host_identifier

  4. Click the Search button to initiate the search.

  5. Click the Search Results tab to display the results table, and then:

    • Edit: Click the Edit button in the tool bar to display the configuration page.

    • Delete: Click the Delete button in the tool bar to remove the instance; confirm removal in the Confirmation window.

    • Detach: Click Detach in the tool bar to expand the table to a full page.

    • View: Select a View menu item to alter the appearance of the results table.

  6. Click the Browse tab to return to the navigation tree when you finish with the Search results.

Viewing or Editing a Host Identifier Definition

Users with valid OAM Administrator credentials can use the following procedure to modify a host identifier definition. This can include adding, changing, or removing individual host identifiers from the definition. For instance, when adding another proxy Web server with a different host name, you might need to modify an existing host identifier definition to add the new host name variation.

Prerequisite: Inventory application domains that refer to the host identifier and

Note:

After viewing settings, you can either close the page or modify settings as needed.

See Also:

"About the Host Identifier Page"

To view or modify a Host Identifier

  1. From the Policy Configuration tab, navigation tree, expand:

    1. Shared Components node

    2. Host Identifiers node

  2. Double-click the desired definition name.

  3. View the Host Identifier page, and modify information as needed (see Table 8-2):

    1. Name

    2. Description

    3. Operations: Add to or remove host name and port variations in the Operations list.

      Click + to add a new host name and port combination.

      Click an existing host name and click the Delete button to remove it.

  4. Repeat step 3c as needed to add or remove variations.

  5. Click Apply to submit the changes (or close the page without applying changes).

  6. Dismiss the Confirmation window, and close the page when you finish.

Deleting a Host Identifier Definition

Users with valid OAM Administrator credentials can use the following procedure to delete an entire host identifier definition. A validation error occurs if you attempt to delete the host identifier that is being used in a resource.

Prerequisites

Each resource in an application domain is associated with a specific host identifier. If you intend to delete a host identifier you must first modify any resource definitions in an application domain that uses this host identifier

See Also:

"Viewing or Editing a Host Identifier Definition" if you want to remove a single host identifier from an existing definition.

To delete a Host Identifier

  1. From the Policy Configuration tab, navigation tree, expand the:

    1. Shared Components node

    2. Host Identifiers node

  2. Optional: In the list, double-click the desired name to view the definition, and then close the page.

  3. In the navigation tree, click the desired definition name.

  4. Click the Delete button in the tool bar, and confirm removal in the Confirmation window.

  5. Check the navigation tree to confirm that the definition was removed.

Managing Authentication Modules

In Oracle Access Manager 11g, each authentication scheme requires an authentication module. This section describes the pre-configured authentication modules that are provided and describes how administrators can define a custom module. It is divided into the following topics:

About Default Authentication Modules Pages

In the Oracle Access Manager Administration Console, pre-configured authentication modules are organized with other system-level components under the System Configuration tab.

Only the following pre-configured authentication module types are allowed in an authentication scheme. However, you can create new modules of an existing type to use in authentication schemes. For more information, see:

See Also:

Kerberos Authentication Module

The pre-configured Kerberos authentication module is illustrated in Figure 8-4. Additional details follow the figure.

Figure 8-4 Pre-configured Kerberos Authentication Module

Pre-configured Kerberos Authentication Module

Table 8-3 describes the definition of the Kerberos authentication module. You can use the existing, pre-configured Kerberos authentication module or create one of your own.

Table 8-3 Kerberos Authentication Module Definition

Element Description

Name

The unique ID of this module, which can include upper and lower case alpha characters as well as numbers and spaces.

Key Tab File

The path to the encrypted, local, on-disk copy of the host's key, required to authenticate to the key distribution center (KDC). For example: /etc/krb5.keytab.

The KDC authenticates the requesting user and confirms that the user is authorized for access to the requested service. If the authenticated user meets all prescribed conditions, the KDC issues a ticket permitting access based on a server key. The client receives the ticket and submits it to the appropriate server. The server can verify the submitted ticket and grant access to the user submitting it.

The key tab file should be readable only by root, and should exist only on the machine's local disk. It should not be part of any backup, unless access to the backup data is secured as tightly as access to the machine's root password itself.

Principal

Identifies the HTTP host for the principal in the Kerberos database, which enables generation of a keytab for a host.

Krb Config File

Identifies the path to the configuration file that controls certain aspects of the Kerberos installation. A krb5.conf file must exist in the /etc directory on each UNIX node that is running Kerberos.

krb5.conf contains configuration information required by the Kerberos V5 library (the default Kerberos realm and the location of the Kerberos key distribution centers for known realms).

LDAP Authentication Modules

The pre-configured LDAP authentication module is illustrated in Figure 8-4. Additional details follow the figure.

Figure 8-5 Pre-Configured LDAP Authentication Module

Pre-Configured LDAP Authentication Module

Table 8-4 describes the elements in an LDAP authentication module. The same elements are also used in LDAPNoPasswordAuthnModule.

Table 8-4 LDAP Authentication Module Definition

Element Description

Name

A unique name for this module.

User Identity Store

The primary user identity store that contains the user credentials required for authentication by this module. The LDAP store must be registered with OAM 11g to appear in this list.

See Also: "Managing User Identity Store and OAM Administrator Registrations".

X509 Authentication Module

Oracle Access Manager provides a pre-configured X509 authentication module as a default. Administrators can also create new X509 authentication modules. In cryptographic terms, X.509 is a standard for digital public key certificates used for single sign-on (SSO). X.509 specifies standard formats for public key certificates, certificate revocation lists, and attribute certificates among other things.

With X.509 digital certificates you can assume a strict hierarchical system of certificate authorities (CAs) issuing the certificates. In the X.509 system, a CA issues a certificate that binds a public key to a particular Distinguished Name, or to an Alternative Name such as an e-mail address or a DNS-entry.

The trusted root certificates of an enterprise can be distributed to all employees so that they can use the company PKI system. Certain Web browsers provide pre-installed root certificates to ensure that SSL certificates work immediately.

Oracle Access Manager uses the Online Certificate Status Protocol (OCSP) Internet protocol to maintain the security of a server and other network resources. OCSP is used for obtaining the revocation status of an X.509 digital certificate. OCSP specifies the communication syntax used between the server containing the certificate status and the client application that is informed of that status.

When a user attempts to access a server, OCSP sends a request for certificate status information. OCSP discloses to the requester that a particular network host used a particular certificate at a particular time. The server returns a response of "current", "expired," or "unknown." OCSP allows users with expired certificates a configurable grace period, during which they can access servers for the specified period before renewing.

OCSP messages are encoded in ASN.1 and are usually transmitted over HTTP. The request and response characteristic of OCSP has led to the term "OCSP responders" when referring to OCSP servers. With Oracle Access Manager, the computer hosting the OAM Administration Console is the OCSP responder.

An OCSP responder can return a signed response signifying that the certificate specified in the request is 'good', 'revoked' or 'unknown'. If OCSP cannot process the request, it can return an error code.

Figure 8-6 Pre-Configured X509 Authentication Module

Pre-Configured X509 Authentication Module

Table 8-5 describes the requirements of the X509 authentication module.

Table 8-5 X509 Authentication Module Definition

Element Description

Name

Identifies this module definition with a unique name.

Match LDAP attribute

Defines the LDAP distinguished name attribute to be used. For example: cn.

X509 Cert Attribute

Defines the certificate attribute to be used to bind the public key. For example: SUBJECT.cn.

Cert Validation Enabled

Enables (or disables when not checked) X.509 Certificate validation.

OCSP Enabled

Enables (or disables when not checked) the Online Certificate Status Protocol.

Note: OCSP Server Alias, OCSP Responder URL and OCSP Responder Timeout are required only when OCSP Enabled is selected.

OCSP Server Alias

An aliased name for the OSCSP Responder--a mapping between the aliased name and the actual instance name or the IP address of the OSCSP Responder instance.

OCSP Responder URL

Provides the URL of the Online Certificate Status Protocol responder.

OCSP Responder Timeout

Specifies the grace period for users with expired certificates, which enables them to access OAM Servers for a limited time before renewing the certificate.

Creating a New Authentication Module

Users with valid OAM Administrator credentials can use the following procedure to create a new authentication module of an existing type. You cannot duplicate a pre-configured module to use as a template.

Note:

You cannot duplicate a pre-configured module to use as a template.

See Also:

About Default Authentication Modules Pages

To create a new authentication module

  1. From System Configuration tab, navigation tree, expand the Authentication Modules node.

  2. From the navigation tree, click the desired module type.

  3. Click the Create button in the tool bar.

  4. Add details for the new authentication module:

  5. Click Apply to submit the new definition and close the Confirmation window (or close the page without applying changes).

  6. Check the navigation tree to confirm the entry, and then close the page when you finish.

  7. Add the authentication module to one or more authentication schemes, as described in "Creating an Authentication Scheme".

Searching for a Specific Authentication Module

Users with valid OAM Administrator credentials can perform the following procedure to search for specific authentication module using the Administration Console.

Prerequisites

The authentication module must be registered in the Oracle Access Manager Administration Console.

See Also:

About Default Authentication Modules Pages

To locate a specific authentication module

  1. Activate the System Configuration tab.

  2. From the search type list, choose one of the following module types to define your search, either:

    • LDAP Authentication Modules

    • X509 Authentication Modules

    • Kerberos Authentication Modules

  3. In the text field, enter the exact name of the instance you want to find. For example:

    my_authn_module

  4. Click the Search button to initiate the search.

  5. Click the Search Results tab to display the results table, and then:

    • Edit: Click the Edit button in the tool bar to display the configuration page.

    • Delete: Click the Delete button in the tool bar to remove the instance; confirm removal in the Confirmation window.

    • Detach: Click Detach in the tool bar to expand the table to a full page.

    • View: Select a View menu item to alter the appearance of the results table.

  6. Click the Browse tab to return to the navigation tree when you finish with the Search results.

Viewing or Editing Authentication Modules

Users with valid OAM Administrator credentials can use the following procedure to modify an existing authentication module. This includes changing the name of an existing module as well as changing other attributes.

Prerequisites

Modify each authentication scheme that references the module you will change, to use another authentication module.

See Also:

About Default Authentication Modules Pages

To view or edit an authentication module

  1. Change to another authentication module in each authentication scheme that references this module.

  2. From the System Configuration tab, navigation tree, expand the:

    1. Authentication Modules node

    2. Expand the module type node

  3. Double-click the desired module name to display the configuration.

  4. Optional: Close the page if you were simply viewing it.

  5. On the Authentication Modules page, modify information as needed:

  6. Click Apply to submit the changes and close the Confirmation window (or close the page without applying changes).

  7. Add the updated authentication module to authentication schemes, as described in "Creating an Authentication Scheme".

Deleting an Authentication Module

Users with valid OAM Administrator credentials can use the following procedure to delete an authentication module.

Prerequisites

In each authentication scheme that references this module, specify another authentication module.

To delete an authentication module

  1. In each authentication scheme that references this module, specify another authentication module.

  2. From the System Configuration tab, navigation tree, expand the:

    1. Authentication Modules node

    2. Expand the module type node

  3. Optional: Double-click the module name to display the configuration and then close the window.

  4. Click the desired module name and then click the Delete button.

  5. Confirm removal (or dismiss the confirmation window to retain the module).

Managing Authentication Schemes

This section is divided into the following topics:

About the Authentication Schemes Page

Access to a resource or group of resources can be governed by a single authentication process known as an authentication scheme. An authentication scheme is a named component that defines the challenge mechanism required to authenticate a user. Each authentication scheme must also included a defined authentication module.

When you register a partner (either using the Administration Console or the remote registration tool), the application domain that is created is seeded with a policy that uses the authentication scheme that is set as the default scheme. You can choose any of the existing authentication schemes as the default for use during policy creation.

You can also create a new authentication scheme, copy an existing definition to use as a template, modify a definition, or delete the definition. The copy uses a default name that is based on the original. For example, if you copy the scheme named KerbScheme, the copy is named copyofKerbScheme.

All authentication schemes include the same elements with differing values. Figure 8-7 shows the default LDAPScheme page as an example. The Authentication Schemes navigation tree lists other default schemes that are delivered.

Figure 8-7 Default LDAPScheme Page

Authentication Schemes Page

Table 8-6 provides information about each of the elements and values in any authentication scheme. Use the Set as Default button to make this the default scheme.

Table 8-6 Authentication Scheme Definition

Element Description

Name

The unique name for this scheme, which appears in the navigation tree.

See Also:"Pre-configured Authentication Schemes"

Description

The optional description, up to 200 characters, that explains the use of this scheme.

Authentication Level

The trust level of the authentication scheme. This reflects the challenge method and degree of trust used to protect transport of credentials from the user.

The trust level is expressed as an integer value between 0 (no trust) and 99 (highest level of trust).

Note: After a user is authenticated for a resource at a specified level, the user is automatically authenticated for other resources in the same application domain or in different application domains, if the resources have the same or a lower trust level as the original resource.

See Also: "About Multi-Level Authentication".

Default

A non-editable box that is checked when the Set as Default button is clicked.

Challenge Method

One challenge method must be selected from those available:

  • Form

  • Basic (LDAP)

  • X509 (Certificate)

  • WNA (Windows Native Authentication)

  • None

  • DAP

  • OAM10g

See Also: "About Challenge Methods"

Challenge Redirect URL

URL of a server specified in the Challenge Redirect field if you want user requests to be redirected to another server for processing.

See Also: "About Host Identifiers".

Authentication Module

The pre-configured authentication module to be used to challenge the user for credentials.

  • LDAP (under the LDAP Authentication Modules node)

  • X509 Module 1 (under the X509 Authentication Modules node)

  • Kerberos (under the Kerberos Authentication Modules node)

See also "About Default Authentication Modules Pages".

For schemes using Challenge Method FORM, X509, or DAP

Only Schemes with the Challenge Method of FORM, X509, or DAP include these additional elements. Other schemes use defaults that require no change.

Challenge URL

The URL the credential collector will redirect to for credential collection.

For a FORM based, out of the box authentication scheme (LDAPScheme and LDAPNoPasswordValidationScheme), the default Challenge URL is "/pages/login.jsp". The context type and context values are used to build the final URL.

Context Type

Used to build the final URL for the credential collector based on the following possible values:

  • default: The Context Value is used to construct the final URL to forward to for credential collection. For example: with a challenge URL of "/pages/login.jsp" and a context value of /oam, the server forwards to "/oam/pages/login.jsp" for credential collection.

  • customWar: If a customized credential collector page "customlogin.jsp" is deployed in a WAR file (with context root, "custom") within the same domain, it should be used to collect credentials. Then set the following values to have server forward to the WEB application page "/custom/customlogin.jsp" to collect credentials:


    challenge_url = "/customlogin.jsp"
    contextType="customWar"
    contextValue="/contextroot of custom application"

  • customHtml: A custom html credential collector page. This file can be placed in a location that is accessible to the application. Set the following values to have the server forward to the custom servlet provided to read the html file and render the page:


    challenge_url = "/CustomReadServlet"
    contextType="customHtml"
    contextValue="html file location"

  • external: If the login page is external, the file can be placed in a location that is accessible to the application. Set the following values to have the server redirect to the challenge URL (the fully-qualified URL of the external credential collector page) for credential collection. The username and password are collected by the external form (HTML or jsp) and submitted to the OAM Server:


    challenge_url = "/http://host:port/externallogin.jsp"
    contextType="external"
    contextValue=Not applicable

    See Also: "About Custom Login Pages"

Context Value

Used to build the final URL for the credential collector. The default value is /oam.

About Custom Login Pages

Only Schemes with the Challenge Method of FORM, X509, or DAP include additional elements described at the end of Table 8-6. All custom login pages must meet the following requirements:

  • Custom login pages require exactly two form fields (username and password). Oracle Access Manager supports authentication forms with two fields only.

  • CustomWar and external context types, require logic within the custom login page to perform the following two tasks:

    • Send back the request ID the page received from the Oracle Access Manager server. For example: String reqId = request.getParameter("request_id"); <input type="hidden" name="request_id" value="<%=reqId%>">

    • Submit back to the OAM Server the end point, "/oam/server/auth_cred_submit". For example: <form action="/oam/server/auth_cred_submit"> or "http://oamserverhost:port/oam/server/auth_cred_submit".

For more information, see the following topics:

Pre-configured Authentication Schemes

Table 8-7 identifies the pre-configured authentication schemes available with Oracle Access Manager 11g and some specific details of each.

Table 8-7 Pre-configured Authentication Schemes

Scheme Name Specifications Purpose

AnonymousScheme
Authentication Level: 0
Challenge Method: None
Authentication Module: AnonymousModule

Unprotects specific Oracle Access Manager URLs and allows users to access URLs without a challenge. Users are not challenged and do not need to enter their credentials.

Note: Authentication Level 0 is for public pages. Oracle recommends that you do not use Level: 0 in a custom authentication scheme.

BasicScheme
Authentication Level: 1
Challenge Method: Basic
Authentication Module: LDAP

Protects Oracle Access Manager-related resources (URLs) for most directory types.

Note: Authentication Level 1 is only one step higher than 0 public pages. Oracle recommends that you do not use Level: 1 in a custom authentication scheme.

KerbScheme
Authentication Level: 2
Challenge Method: WNA
Authentication Module: Kerberos

Protects Oracle Access Manager-related resources (URLs) for most directory types based on a Windows Native Authentication challenge method and valid WNA credentials in Active Director.y

LDAPNoPasswordValidationScheme
Authentication Level: 2
Challenge Method: Form
Authentication Module: LDAPNoPasswordAuthModule

Note: LDAPNoPasswordAuthModule is similar to the DAP (asserter) mechanism.

See Also OAM10gScheme, later in this table.

Protects Oracle Access Manager-related resources (URLs) for most directory types based on a form challenge method.

Used with the Identity Asserter for SSO when you have resources in a WebLogic Container. For details, see the Oracle Fusion Middleware Application Security Guide.

LDAPScheme
Authentication Level: 2
Challenge Method: Form
Authentication Module: LDAP

Protects Oracle Access Manager-related resources (URLs) for most directory types based on a form challenge method.

OAAMAdvanced
Authentication Level: 2
Challenge Method: Form
Authentication Module: LDAP

Protects OAAM-related resources with an external context type. This authentication scheme is used when complete integration with OAAM is required. A WebGate must front ending the partner.

OAAMBasic
Authentication Level: 2
Challenge Method: Form
Authentication Module: LDAP

Protects OAAM-related resources with a default context type. This scheme should be used when basic integration with OAAM is required. Here, advanced features like OTP are not supported. This is more of an integration when mod_osso is used as the agent.

OAM10gScheme
Authentication Level: 2
Challenge Method: OAM10g
Authentication Module: LDAPNoPasswordAuthModule

Note: The challenge mechanism OAM10g is similar to that of DAP (asserter) mechanism. The OAM10g mechanism is used specifically for OAM10g coexistence with OSSO and should not be used with any other scheme.

See Also LDAPNoPasswordValidationScheme, earlier in this table.

Facilitates integration and coexistence with OAM 10g. In the coexistence mode, OAM 10g is the authenticator and OAM 11g is the asserter. This scheme uses a new challenge mechanism: OAM10G.

OIFScheme
Authentication Level: 1
Challenge Method: DAP
Authentication Module: DAP

This scheme delegates authentication to OIF, after which, OIF sends back a token that is asserted by the OAM Server.

The Delegated Authentication Protocol (DAP) challenge method is used to delegate authentication to a third-party (OIF in this case).

OIMScheme
Authentication Level: 1
Challenge Method: Form
Authentication Module: LDAP

Protects Oracle Identity Manager-related resources with a default context type.

Note: When integrating OAM and OIM, OAM downgrades the user's authentication level when any of the following is detected:


password expiry
forced password change
challenge setup not done

This enables the user to access the pages only after performing necessary operations in the identity management (OIM) page to which the user is redirected.

At Level 1, only public and OIM pages for the required operations can be accessed.

Note: Authentication Level 1 is only one step higher than 0 public pages. Oracle recommends that you do not use Level: 1 in a custom authentication scheme.

X509Scheme
Authentication Level: 2
Challenge Method: X509
Authentication Module: X509

This authentication scheme is a certificate-based user identification method. To use this method, a certificate must be installed on the user's browser and the Web server must be SSL-enabled.

About Challenge Methods

Authentication involves determining what credentials a user must supply when requesting access to a resource, gathering credentials over HTTP, and returning an HTTP response that is based on the results of credential validation. Oracle Access Manager 11g provides the following credential challenge methods for use in an authentication scheme:

  • Form

  • Basic

  • X509

  • WNA

  • None

  • DAP

  • OAM10g

Form

This authentication challenge uses an HTML form with one or more text input fields for user credentials. In a typical form-based challenge, users enter a user name and password in two text boxes on the form. The most common credential choices are user name and password; however, you can use any user attributes: for example, user name, password, and domain.

A Submit button posts the content of the form. When the user clicks the Submit button, the form data is posted to the Web server. OAM and OSSO Agents intercept and process the form data. Upon validation of the user credentials collected in the form, the user is authenticated.

Note:

This challenge method relies on an LDAP Authentication Module and the user identity store associated with that module.

You might want to use form-based authentication challenge for reasons such as:

  • A consistent user experience: Using form-based login and a standardized logout means that the user experience for login and logout features will be consistent across browsers.

  • A Custom Form: You can apply your organization's look and feel in the authentication process.

    For example, a custom form can include a company logo and a welcome message instead of the standard user name and password window used in Basic authentication.

  • Additional Information: You can gather additional information at the time of login.

  • Additional Functionality: You can provide additional functionality with the login procedure, such as a link to a page for lost password management.

Basic

This built-in Web server challenge mechanism requires a user to enter her login ID and password. The credentials supplied are compared to the user's definition in the LDAP directory server.

Note:

A Basic challenge relies on an LDAP Authentication Module and the user identity store associated with that module.

X509

With the X509 certificate challenge method, a user's browser must supply an X.509 digital certificate over SSL to the OAM Server through the Agent to perform authentication.

Note:

X509 is the challenge method for the X509Scheme. The user's organization can determine how to obtain a certificate.

The X.509 client certificate must be verified against the trusted CAs in the key store used by OAM Proxy and OAM Servers to ensure the validity of X.509 Client certificate for authentication.

The following attributes of the X.509 certificate can be validated against the user identity store associated with OAM 11g:

  • SubjectDN

  • SubjectUniqueID

  • Mail

  • CN

To acquire the user entry, the X509 Authentication Module takes the attribute name of the X.509 certificate to be validated and the LDAP attribute against which the search will be launched. The expected result is the single user entry matching the criteria. If the search returns no user entry, or more than one entry, authentication fails. Authentication scheme parameters are located in oam-policy.xml.

Note:

For X509 authentication, Administrators must configure the Oracle HTTP Server as a reverse proxy (or a server with the wl-proxy plug-in). The Oracle HTTP Server must be configured in two way SSL Mode to acquire X.509 certificate for authentication. Oracle HTTP Server can also be configured for CRL verification.

The online certificate status protocol (OCSP) capabilities are also provided. Any certificate passed for X.509 certificate-based authentication is validated using an OCSP request. Administrators can configure the system to communicate with one or more OCSP servers to retrieve the certificate status.

The X509 Authentication Module configuration for the OCSP responder URL indicates whether OCSP validation is to be done. The value, if specified, indicates the URL for validation of the X.509 client certificate using OCSP. No value indicates no OCSP validation.

WNA

Uses Windows Native Authentication with Active Directory, and the Kerberos Authentication Module.

Note:

The KerbScheme relies on the WNA challenge method and Kerberos Authentication Module.

See Also:

Oracle Fusion Middleware Integration Guide for Oracle Access Managerfor details about integration Windows Native Authentication

None

The challenge method of None means that users are not challenged and do not need to enter their credentials. This is used in the AnonymousScheme authentication scheme, which allows users to access Oracle Access Manager-specific URLs that you do not want to protect.

DAP

The Delegated Authentication Protocol (DAP) challenge method is new and required for OIFScheme (Oracle Identity Federation integration) with the DAP authentication module and external context type (Table 8-6). The DAP challenge mechanism indicates that OAM does an assertion of the token that it receives, which differs from the standard challenge "FORM" mechanism with the external option.

DAPModule is a new assertion module, though it is specialized for this one application and does not appear in the list of Authentication Modules in the OAM Administration Console. This integration replaces OSSO 10g with OAM11g, with no changes from the OIF side

The DAP challenge mechanism delegates authentication to a third party (OIF in this case). The challenge_url points to the OIF Server URL. When a resource is protected by this scheme, the OAM Server redirects to the OIF Server URL for credential collection. OAM Server does not perform the credential collection or validation in this case. OIF collects the credentials, authenticates the user against its identity store and returns an assertion token to the OAM Server consisting of the username. OAM receives and decrypts this token, checks whether the user is a valid user in the primary identity store for OAM. If the user is valid, OAM gives access to the resource.

The DAPToken is encrypted and decrypted with a key that is shared between OAM and OIF. The DAPToken is built from the OAM side.

The OIF Administration EM Console provides a way to generate the keystore containing the encryption keys that will be used to secure communications between the OAM 11g and OIF. OAM provides a WLST command (registerOIFDAPPartner), that takes the keystore location generated by the OIF store and retrieves the keys and stores it on the OAM side.

OAM10g

This challenge method is required for OAM10gScheme with the LDAPNoPasswordAuthModule to facilitate trust when you have OAM 10g protecting a domain that also includes an OSSO 10g integrated classic application (Portal, Disco, and so on). This new mechanism is created for OAM 10g coexistence.

OSSO10g is protected with OAM10g through WebGate, so that OAM10g always acts as the authentication/authorization provider.

Facilitating Integration: The OSSO 10g integrated classic applications can be upgraded to OAM 11g, which then acts only as an asserter. OAM 11g creates the tokens that mod_osso can consume so that access can be provided to these applications. The mod_osso applications are protected by the new "OAM10gScheme". There is a WebGate front ending the OAM 11g Server and configured against the OAM 10g Access Server.

Setup: When the resource is accessed, WebGate intercepts the request and sends it to the OAM 10g Access Server for authentication. OAM 10g collects the credentials, validates it against its identity store, and sets the username as a header variable (OAM_REMOTE_USER). The request now goes to the OAM 11g Server which uses the OAM10gScheme to locate the username in the header variable. OAM 11g retrieves the header variable and asserts the presence of the user against the primary identity store. If present, the required cookies (OAM_ID) are generated and redirected to the resource.

About Authentication Modules

In Oracle Access Manager 11g, each authentication scheme requires an authentication module. Administrators can create a new authentication module of an existing type. However, several default authentication modules are available for immediate use:

  • LDAP: This module matches the credentials (username and password) of the user who requests a resource to a user definition stored in an LDAP directory server. An LDAP module is required for Basic and Form challenge methods.

  • X509: Similar to LDAP with additional properties that indicate which attribute of the client's X.509 certificate should be validated against the user attribute in LDAP.

  • Kerberos Module: A credential mapping module that matches the credentials (username and password) of the user who requests a resource to the encrypted "ticket".

See Also:

"Managing Authentication Modules"

About Multi-Level Authentication

Every authentication scheme requires a strength level. The lower this number, the less stringent the scheme. A higher level number indicates a more secure authentication mechanism:

  • LDAPScheme authLevel=1

  • KerbScheme authLevel=2

Note:

Multi-level authentication does not affect, negate, or alter X.509 certificate authentication.

SSO capability enables users to access more than one protected resource or application with a single sign in. After a successful user authentication at a specific level, the user can access one or more resources protected by one or more application domains. However, the authentication schemes used by the application domains must be at the same level (or lower). When a user accesses a resource protected with an authentication level that is greater than the level of his current SSO token, he is re-authenticated. In the step-up case, the user maintains his current level of access even if failing the challenge presented for the higher level. This is "additional authentication".

Note:

A user who is authenticated to access resources at level 3, is eligible to access resources protected at levels less than or equal to 3. However, if the user is authenticated to access resources at level 2 and then attempts to access resources protected by level 3, the user is asked to re-authenticate (this is known as step-up authentication).

Oracle Access Manager 11g policies allow different resources of the same application to be protected with different authentication levels. However, the mod_osso plug-in does not support two resources on the same application with a different trust level.

Note:

mod_osso delegates authentication to OAM. Oracle recommends that mod_osso-protected resources be protected with OAM authentication levels.

In such cases, the application must enforce the Level and send the Dynamic Directive to mod_osso for re-authentication. On receiving the Dynamic Directive, mod_osso will redirect to Oracle Access Manager for re-authentication at the appropriate level.

For more information, see:

About Agents and Multi-Level Authentication

Registered agents detect the authentication level as follows:

Both agent types redirect the user the OAM server to authenticate again. The challenge is presented according to the level of the authentication scheme configured in the policy for the resource.

Detection of Insufficient Authentication Level by OAM Agent

When the user requests a resource that is protected with a higher level authentication scheme, the following process occurs.

Process overview: OAM Agent detects insufficient user session level

  1. The OAM Agent sends the request to the OAM Proxy to obtain the scheme details for the protected resource.

  2. The OAM Agent sends the request for session information to the OAM Proxy.

  3. The OAM Proxy returns details of the ObSSOCookie, including the authenticated level of the ObSSOCookie.

  4. The OAM Agent compares the level of ObSSOCookie with that of the authentication scheme.

    • If insufficient, the agent invokes the authentication process again.

    • If sufficient, the access is granted access.

No check of the authentication level is made on the server side.

Request Flow for Multi-Level Authentication with OSSO Agent (mod_osso 10g)

In contrast to OAM Agents, all the resources protected by mod_osso on a host (or virtual host) are protected at the same level.

With mod_osso, multi-level authentication applies when user is already authenticated using one mod_osso host (or virtual host) at Level 2 and then tries to access another mod_osso protected host (or virtual host) at level 3.

Process overview: OSSO Agent multi-level authentication flow

  1. The user tries to access a resource protected by mod_osso on host1 at level 2.

  2. The OSSO Agent sends the request to the OAM Proxy to obtain the authentication scheme details for the protected resource.

  3. The OAM_ID cookie for SSO Server and a host based cookie "HOST_port" for host1 are set and contain authentication level information.

  4. After authentication, the user tries to access a resource on host2 that is protected with a higher level of authentication.

  5. The user is redirected to the OAM Server for authentication because this is the first time accessing host2.

  6. The OAM Server (OSSO Proxy) receives the OAM_ID cookie which has an insufficient level to access the resource on host2.

    • If the level is insufficient, the OAM Server (OSSO Proxy) triggers re-authentication.

    • If the level is sufficient, the access is granted access.

Creating an Authentication Scheme

Users with valid OAM Administrator credentials can use the following procedure to add a new authentication scheme for use in an application domain.

Prerequisites

The authentication module must be defined and ready to use.

See Also:

"About the Authentication Schemes Page"

To create an authentication scheme

  1. From the Policy Configuration tab, navigation tree, expand the Shared Components node.

  2. Click the Authentication Schemes node, then click the Create button in the tool bar.

  3. Fill in the fresh Authentication Scheme page, as described in Table 8-6:

    1. Name

    2. Description

    3. Authentication Level

    4. Default

    5. Challenge Method

    6. Challenge Redirect

    7. Authentication Module

  4. Click Apply to submit the new scheme (or close the page without applying changes).

  5. Dismiss the Confirmation window.

  6. Optional: Click the Set as Default button to automatically use this with new application domains, then close the Confirmation window.

  7. In the navigation tree, confirm the new scheme is listed, and then close the page

Searching for a Authentication Scheme

Users with valid OAM Administrator credentials can perform the following task to search for a specific authentication scheme.

See Also:

"About Search Controls"

To search for an authentication scheme

  1. Activate the Policy Configuration tab.

  2. From the search type list, choose Authentication Schemes to define your search.

  3. In the text field, enter the exact name of the instance you want to find. For example:

    my_AuthnScheme

  4. Click the Search button to initiate the search.

  5. Click the Search Results tab to display the results table, and then:

    • Edit: Click the Edit button in the tool bar to display the configuration page.

    • Delete: Click the Delete button in the tool bar to remove the instance; confirm removal in the Confirmation window.

    • Detach: Click Detach in the tool bar to expand the table to a full page.

    • View: Select a View menu item to alter the appearance of the results table.

  6. Click the Browse tab to return to the navigation tree when you finish with the Search results.

Viewing or Editing a Authentication Scheme

Users with valid OAM Administrator credentials can use the following procedure to view or modify an existing authentication scheme.

Prerequisites

Review any application domain using this authentication scheme and specify a different scheme.

See Also:

"About the Authentication Schemes Page"

To view or modify an authentication scheme

  1. From the Policy Configuration tab, navigation tree, expand the:

    1. Shared Components node

    2. Authentication Schemes node

  2. Double-click the name of the scheme to change.

  3. On the Authentication Scheme page, modify values as needed (Table 8-6).

  4. Click Apply to submit the changes (or close the page without applying changes).

  5. Dismiss the Confirmation window.

  6. Optional: Click the Set as Default button to automatically use this with new application domains, then close the Confirmation window.

  7. Close the page when you finish.

Deleting an Authentication Scheme

Users with valid OAM Administrator credentials can use the following procedure to delete an existing authentication scheme.

Prerequisites

Review any application domain using this authentication scheme and specify a different scheme.

See Also:

"About the Authentication Schemes Page"

To delete an authentication scheme

  1. From the Policy Configuration tab, navigation tree, expand the:

    1. Shared Components node

    2. Authentication Schemes node

  2. Optional: Double-click the name of the scheme to confirm it is the one to delete, then close the page.

  3. In the navigation tree, click the name of the scheme and then click the Delete button in the tool bar.

  4. Confirm removal (or dismiss the Confirmation window).

  5. In the navigation tree, confirm the instance has been removed.