12 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

The Oracle Access Manager 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 12-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 12-1 Policy Components: Relationship to an Application Domain

Policy Components in an Application Domain
Description of "Figure 12-1 Policy Components: Relationship to an Application Domain"

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 13, "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.

With Oracle Access Manager 11g (11.1.1.5) command buttons to create/edit/delete a resource type are disabled. Oracle provided resource types include the following. For HTTP type resources, include a host identifier. For non-HTTP resource types, use the type name:

  • HTTP

  • TokenServiceRP

  • wl_authen

HTTP: The default resource type 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.

wl_authen: Resources for representing WebLogic Authentication schemes. A non-HTTP resource type, wl_authen, is available to use with resources deployed in a WebLogic container. Resources of type wl_authen, require a custom Access Client. The protected resource is accessed using its URL on the Oracle WebLogic Server.

TokenServiceRP: Resources for representing Token Service Relying Party.

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.

About the Resource Type Page

In the Oracle Access Manager Console, resource types are organized with other Components under the Policy Configuration tab, as shown in Figure 12-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 12-2 Default wl_authen Resource Type Definition

Resource Type Definition
Description of "Figure 12-2 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

The TokenServiceRP resource type is used to represent the Token Service Relying Party, as shown in Figure 12-3. For more information, see "Managing TokenServiceRP Type Resources".

Figure 12-3 TokenServiceRP

TokenServiceRP Resource Type
Description of "Figure 12-3 TokenServiceRP"

Table 12-1 describes the elements in each resource type definition.

Table 12-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.

Searching for a Specific Resource Type

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

See Also:

"Conducting Policy Element Searches Using the Console"

To search for a resource type

  1. Activate the Policy Configuration tab, then click the Search tab.

  2. From the search type list, choose Resource Type, enter the name of the Resource Type you want to find (with or without a wild card (*)), and click Search. For example:

    h*

    Alternatively: Go to the desired Application Domain, open the Resources node to display controls for that domain, choose a Resource Type from the list, and click Search.

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

    • Edit or View: 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.

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

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

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 Oracle Access Manager 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.

For instance, a user accessing aseng-wiki, would enter:

http://corp-wiki.uk.mycompany.com/mywikipage

Here, "mywikipage" is the resource URL and "corp-wiki.uk.mycompany.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

You can install a Webgate on a Web server that contains multiple Web site and domain names. The Webgate must reside in a location that enables it to protect all of the Web sites on that server.

Note:

The information here is the same for both 11g and 10g Webgates.

The virtual Web hosting feature of many Web servers enables you to support multiple domain names and IP addresses that each resolve to their unique subdirectories on a single virtual server. For example, you can host abc.com and def.com on the same virtual server, each with its own domain name and unique site content. You can have name-based or IP-based virtual hosting.

A virtual host referees 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 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.

Placing a Webgate Behind a Reverse Proxy

You can use OAM 10g Webgates with reverse proxies for OAM 11g. This topic discusses benefits and pitfalls of this strategy.

Benefits:

  • All Web content can be protected from a single logical component as long as all requests go through the proxy.

    This is true even for platforms that are not supported by Oracle Access Manager. If you have different types of Web servers (for example, iPlanet, Apache, and so on) on different platforms (for example, Windows XP, Linux, and so on), all content on these servers can be protected. A reverse proxy can be a workaround for unsupported Web servers, eliminating the need to write custom Access Clients for unsupported Web servers and on platforms that do not have Webgate support, for example, MacOS.

  • A reverse proxy offers architecture flexibility.

    Reverse proxies can allow deployments to expose an application that is available on the intranet to the extranet. Or applications that are available on the extranet can be exposed to the intranet. This can be done without any changes to the application that is already deployed.

  • You only need to install a separate Webgate on the reverse proxy, rather than on every Web server.

    This allows for a single management point and can help with manageability of the system. You can manage the security of all of the Web servers through the reverse proxy without establishing a footprint on the other Web Servers.

Pitfalls: The main pitfall of using a proxy is the extra work involved in setup. If you deploy the Webgate on a Web server that is behind a reverse proxy, the following are configuration requirements:

  • Ensure that any Web server that uses the reverse proxy for authentication only accepts requests from the reverse proxies.

    This will also require that Webgates deployed on this Web server be configured to not enforce IP validation for requests from the reverse proxy server that front-ends the Webgate. This is done by configuring the known IP addresses of the reverse proxy server or servers in the IP Validation list. Note that while you can achieve the same effect by turning IP validation off for the Webgate, this is not a recommended approach due to security risks.Ensuring that the Web server only accepts requests from reverse proxies is typically done by adding an ACL statement in the server. This prevents users from bypassing the reverse proxy and directly accessing restricted content.

  • Update the virtual hosts that are configured in the Policy Manager so that the Access System intercepts requests that are sent to the reverse proxy.

  • Prevent people from circumventing the proxy by entering URLs that point directly to the back-end system.

    You can prevent this problem through the use of Web Server Access Control Lists or firewall filters.

  • Since all user requests are processed by the proxy, you must deploy enough proxy servers to enable the system to handle the load.

  • Redirect all existing URLs to the host name and port number of the reverse proxy server.

    This often requires configuring the reverse proxy to perform content inspection and rewriting to prevent any absolute HTML links, for instance, to prevent broken link. This is achievable with most reverse proxies, and this is something you can configure independently of the Access System,.

  • It is a best practice that URL links exposed to the front-ended applications rely on only relative URLs (../../sub-path/resource) rather than absolute URLs (http://hostname.domain:[port]/path/resource).

    Absolute URLs can break links on the end user's browser when deployed behind a reverse proxy.

Configuring Virtual Hosting for Non-Apache Web Servers

Ensure that the Virtual Host box is checked on the 10g Webgate registration page.

On most Web servers, other than Apache-based servers, you must set the Preferred Host value to HOST_HTTP_HEADER. This ensures that, when user's browser sends a request, the Webgate sets the value of the Preferred 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.

In the Preferred Host field of the expanded 10g Webgate registration page, enter the following:

HOST_HTTP_HEADER.

IIS Virtual Hosting: From the IIS console, you must configure each virtual Web site to contain the following fields:

  • Host Header Name

  • IP address

  • Port

See Also:

Associating a Webgate for Apache with Virtual Hosts, Directories, or Files

Ensure that the Virtual Host box is checked on the 10g Webgate registration page.

On Apache-based Web servers (Apache, Apache 2, IBM HTTP Server, Oracle HTTP Server, and so on), the Preferred 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 must 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.

When using an Apache-based reverse proxy for single sign-on, in the Web server configuration file (httpd.config, for example) file you specify the Web sites to run on the Apache server. The settings can be global across all Web sites or local to a Web site. You can restrict the Oracle Access Manager loading references in the httpd.config file to be associated with a specified site, with virtual hosts, specific directories or even files.

To associate the Webgate with specific targets, you move the following directives the the http.conf file:

AuthType Oblix
require valid-user

You can put these directives in a block that tells Apache to use Webgate for every request. You can also move the directives to a block that limits when the Webgate is called. The following is an example of putting the LocationMatch directive after a VirtualHost directive:

  DocumentRoot /usr/local/apache/htdocs/myserver    
  ServerName myserver.example.net    
  AuthType Oblix       
  require valid-user

After you move the LocationMatch block to the VirtualHost directive, the Webgate will only work for that virtual host. You can add the LocationMatch block to as many virtual hosts as you want. The following examples shows how you could protect one virtual server:

ServerAdmin webmaster@example.net
DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv"
ServerName apps.example.com
    ProxyRequests On
    SSLEngine on
    SSLCACertificateFile Z:/Apps/sslcert_myapps_ptcweb32/intermediateca.cer
    SSLCertificateFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.cer
    SSLCertificateKeyFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.key
    ErrorLog logs/proxysite1_log
    CustomLog logs/proxysite1_log common
    ProxyPass /https://apps.example.com/
    ProxyPassReverse /https://apps.example.com/
    ProxyPass /bkcentral https://apps.example.com/bkcentral
    ProxyPassReverse /bkcentral https://apps.example.com/bkcentral
    ProxyPass /NR https://apps.example.com/NR
    ProxyPassReverse /NR https://apps.example.com/NR
    
      AuthType Oblix
      require valid-user
    
#*** BEGIN Oracle Access Manager Webgate Specific **** 
 
LoadModule obWebgateModule Z:/apps/Oracle/WebComponent/access/oblix/apps/webgate/bin/webgate.dll
WebgateInstalldir Z:/apps/Oracle/WebComponent/access
WebgateMode PEER
 
 SetHandler obwebgateerr
 
SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache none
 
SSLLog logs/SSL.log
SSLLogLevel info
# You can later change "info" to "warn" if everything is OK

About the Host Identifier Page

A host identifier is automatically created when an Agent (and application) are registered using either the Oracle Access Manager 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 Oracle Access Manager 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 12-4 illustrates a typical Host Identifier configuration page in the 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 12-4 Host Identifier Page

Host Identifier Configuration Page
Description of "Figure 12-4 Host Identifier Page"

Table 12-2 describes the host identifier definition.

Table 12-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 Administrator credentials can use the following procedure to create a host identifier definition manually. This is needed if an application and resources were manually added to a host that has no mapped host identifier. When you choose Auto Create Policies when registering an Agent, this is done automatically.

Note:

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

See Also:

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 Administrator credentials can perform the following task to search for a specific host identifier.

See Also:

"About Policy Configuration Search Controls"

To search for a host identifier

  1. Activate the Policy Configuration tab, and then click the Search tab.

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

  3. In the text field, enter your search criteria (with or without a wild card (*)). For example:

    my_h*

  4. Click the Search button to initiate the search.

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

    • Edit or View: Click the Edit button in the tool bar (or double-click the name in the results table) to display the configuration page.

    • Delete: Click the Delete button in the tool bar to remove the selected item in the results table; confirm removal in the Confirmation window.

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

    • Reconfigure Table: 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 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 12-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 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 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 include a defined authentication module (standard or custom, as described in "Managing Authentication Modules").

When you register a partner (either using the 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 KerberosScheme, the copy is named copyofKerberosScheme.

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

Figure 12-5 Default LDAPScheme Page

Authentication Schemes Page
Description of "Figure 12-5 Default LDAPScheme Page"

Table 12-3 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 12-3 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: Level 0 is unprotected. Only unprotected resources can be added to an Authentication Policy that uses an authentication scheme at protection level 0. For more information, see Table 13-1, "Resource Definition Elements".

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)

  • LDAPNoPasswordAuthModule

  • Kerberos Plugin (under Authentication Modules, Custom Authetication Module)

  • LDAP Plugin (under Authentication Modules, Custom Authetication Module

  • X509 Plugin (under the X509 Authentication Modules node)

See also "Managing Authentication Modules".

Challenge Parameters

Supported challenge parameters are discussed in "About Challenge Parameters for Authentication Schemes"

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 12-3. 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 12-4 identifies the pre-configured authentication schemes available with Oracle Access Manager 11g and some specific details of each. For more information about challenge parameters, see Table 12-5.

Table 12-4 Pre-configured Authentication Schemes

Scheme Name Specifications Purpose

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

Leaves unprotected specific Oracle Access Manager URLs and allows users to access such 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.

Also: When a resource is protected by AnonymousScheme, it is not displayed in a session search.

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.

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

Primarily used for clients that don't support URL redirect or cookies.

Challenge Parameters: CookieLessMode=true

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.

FAAuthScheme
Authentication Level: 2
Challenge Method: FORM
Authentication Module: LDAP
Context: customWar
Context Value: /fusion_apps

Protects Fusion Applications.

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

Context Type: default
Context Value: /oam

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

Context Type: external

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

Context Type: default
Context Value: /oam

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.

Challenge Parameters:

oaamPostAuth=true

oaamPreAuth=true

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.

OAMAdminConsoleScheme
Authentication Level: 2
Challenge Method: FORM
Authentication Module: LDAP

Context Type: default
Context Value: /oam

Authentication scheme for OAM Administration Console.

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

Context Type: External

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

Challenge Parameters: TAPPartnerId=OIFDAPPartner

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

Context Type: default
Context Value: /oam

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.

TAPScheme
Authentication Level: 2
Challenge Method: DAP
Authentication Module: DAP

Context Type: External

To use TAPScheme for IDM product resources in the IAM Suite application domain, Protected HigherLevel Policy, the following configuration must be done in addition to changing the Authentication Scheme.

  1. From the IAM Suite application domain, Protected HigherLevel Policy, remove IAMSuiteAgent:/oamTAPAuthenticate.

  2. Create a new Authentication Policy in the IAM Suite application domain, that uses LDAPScheme.

  3. Protect IAMSuiteAgent:/oamTAPAuthenticate using the newly created policy.

Challenge Parameters: TAPPartnerId=TAPPartnerName

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 keystore 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 12-3). 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 Oracle Access Manager Console. This integration replaces OSSO 10g with OAM11g, with no changes from the Oracle Identity Federation side

The DAP challenge mechanism delegates authentication to a third party (Oracle Identity Federation in this case). The challenge_url points to the Oracle Identity Federation Server URL. When a resource is protected by this scheme, the OAM Server redirects to the Oracle Identity Federation Server URL for credential collection. OAM Server does not perform the credential collection or validation in this case. Oracle Identity Federation collects the credentials, authenticates the user against its identity store and returns an assertion token to the OAM Server consisting of the username. Oracle Access Manager receives and decrypts this token, checks whether the user is a valid user in the default 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 Oracle Identity Federation 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 Challenge Parameters for Authentication Schemes

Challenge parameters are short text strings consumed and interpreted by Webgates and Credential Collector modules to operate in the manner indicated by those values.

Here is an example of the default challenge parameter, which is interpreted by Webgate to use HttpOnly property for the cookies that it uses:

ssoCookie=httponly

Table 12-5 identifies the pre-configured schemes with challenge parameters. For more information on the schemes themselves, see Table 12-4.

Table 12-5 Challenge Parameters in Pre-configured Schemes

Pre-configured Schemes Challenge Parameter

BasicSessionlessScheme

CookieLessMode=true

Primarily used for clients that don't support URL redirect or cookies.

OAAMBasic

oaamPostAuth=true

oaamPreAuth=true

Protects OAAM-related resources. These parameters should be used when basic integration with OAAM is required.

OIFScheme

TAPPartnerId=OIFDAPPartner

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

TapScheme

TAPPartnerId=TAPPartnerName

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

  • LDAPNoPasswordAuthModule

  • Custom Authentication Modules: This type of module relies on custom plug-ins developed using the Oracle Access Manager Authentication Extensibility Java API. This type of module can use one or more custom plug-ins. With multiple plug-ins you can orchestrate each one to perform an authentication function and, depending on success or failure, call another authentication plug-in.

See Also:

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 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 (Table 12-3):

    1. Name

    2. Description

    3. Authentication Level

    4. Challenge Method

    5. Challenge Redirect URL

    6. Authentication Module

    7. Challenge Parameters

    8. Challenge URL

  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 Administrator credentials can perform the following task to search for a specific authentication scheme.

See Also:

"About Policy Configuration Search Controls"

To search for an authentication scheme

  1. Activate the Policy Configuration tab, and then click the Search tab.

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

  3. In the text field, enter the desired scheme name (with or without wild card *). For example:

    OA*

  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 Administrator credentials can use the following procedure to view or modify an existing authentication 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 view or change.

  3. Edit:

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

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

    3. Dismiss the Confirmation window.

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

  5. Close the page when you finish.

Deleting an Authentication Scheme

Users with valid 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.

Configuring Challenge Parameters for Encrypted Cookies

This section provides the following topics:

About ssoCookie Challenge Parameters for Encrypted Cookies

In addition to the OAM Server cookie (OAM_ID), Oracle Access Manager implements single sign-on through an encrypted cookie:

  • 11g Webgate, One per agent: OAMAuthnCookie_<host:port>_<random number> set by Webgate using the authentication token received from the OAM Server after successful authentication

    Note: A valid OAMAuthnCookie is required for a session.

  • 10g Webgate, One ObSSOCookie for all 10g Webgates.

Oracle Access Manager provides the ssoCookie challenge parameter that you can use within any authentication scheme to control how Webgates set the flags of the encrypted cookie. For example:

  • Securing Encrypted Cookie: Ensures that the encrypted cookie is sent only over an SSL connection and prevents the encrypted cookie from being sent back to a non-secure Web server.

  • Persisting Encrypted Cookie: Allows the user to log in for a time period rather than a single session. Persistent cookie functionality works with Internet Explorer and Mozilla browsers.

Syntax between the parameter and values differs slightly depending upon your Webgate releases, as follows:

11g Webgate ssoCookie=

10g Webgate ssoCookie:

Multiple values must be separated by a semicolon (;). For example:

11g Webgate ssoCookie=<value1>;<value2>;...

10g Webgate ssoCookie:<value1>;<value2>>;...

The following example specifies sending the encrypted cookie over only an SSL connection and allows access to the encrypted cookie through client side scripts:

11g Webgate ssoCookie=Secure;disablehttponly

10g Webgate ssoCookie:Secure;disablehttponly

Note:

The value of the challenge parameter is case-sensitive. Be sure to enter an uppercase C in ssoCookie, and uppercase S in Secure.

Table 12-5 describes specific challenge parameters that control how Webgates set encrypted cookie flags for single sign-on.

Table 12-6 Challenge Parameters for Encrypted Cookies

Syntax for 11g Webgate and OAMAuthnCookie Syntax for 10g Webgate and ObSSOCookie Description 
ssoCookie=

ssoCookie:

Parameter that controls flags for encrypted cookies.

 
ssoCookie=httponly

ssoCookie:httponly

Ensures that the encrypted cookie is not accessible to client side scripts such as JavaScript.

Default: Enabled

 
ssoCookie=disablehttponly

ssoCookie:disablehttponly

Explicitly disables httponly functionality, making the encrypted cookie accessible to client side scripts.

Once explicitly disabled, you must use the default value (httponly) to enable it.

 
ssoCookie=Secure

ssoCookie:Secure

Ensures that the encrypted cookie is sent only when the resource is accessed through HTTPS. A secure cookie is required only when a browser is visiting a server using HTTPS..

 
ssoCookie=max-age=time-in-seconds

ssoCookie:max-age=time-in-seconds

Creates a persistent cookie in Internet Explorer and Mozilla browsers, rather than one that lasts for a single session.

Specifies the time interval in-seconds when the cookie expires. For example, to set the cookie to expire in 30 days (2592000 seconds):

max-age=2592000

Configuring Challenge Parameters for Encrypted Cookie Security

The challenge parameter is case-sensitive. Be sure to enter an uppercase C in ssoCookie, and uppercase S in Secure.

See Also:

"About ssoCookie Challenge Parameters for Encrypted Cookies"

To secure the encrypted cookie

  1. Create an authentication scheme, as described in "Creating an Authentication Scheme".

  2. In the Challenge Parameter field, specify the following to secure the encrypted cookie:

    11g Webgate ssoCookie=Secure

    10g Webgate ssoCookie:Secure

  3. Confirm that the OAM Servers and clients (OAM Agents) are communicate securely across the Access Protocol channel, as described in Appendix E.

Setting Challenge Parameters for Encrypted Cookie Persistence

The challenge parameter is case-sensitive. Be sure to enter an uppercase C in ssoCookie.

See Also:

"About ssoCookie Challenge Parameters for Encrypted Cookies"

To define encrypted cookie persistence

  1. Define an authentication scheme, as described in "Creating an Authentication Scheme".

  2. In the challenge parameter for this scheme, add the following:

    11g Webgate ssoCookie=max-age=time-in-seconds

    10g Webgate ssoCookie:max-age=time-in-seconds