| Oracle® Access Manager Access Administration Guide 10g (10.1.4.0.1) Part Number B25990-01 |
|
|
View PDF |
| Oracle® Access Manager Access Administration Guide 10g (10.1.4.0.1) Part Number B25990-01 |
|
|
View PDF |
The Access System enables you to protect your resources with policy domains, which contain rules that determine who can access them. Policy domains include authentication rules. Authentication is the process of proving that a user is who he or she claims to be. For the Access System, how authentication of users is to be performed is specified by the content of authentication schemes, which are included in authentication rules. Policy domains can include policies, which are used for specific resources to define finer-grained protection for those resources. Policies can also contain authentication rules.
Policy domains and policies also include authorization rules and expressions, and audit rules, which are described in other chapters of this guide. After you have created your policy domains by identifying their resources, you can define their schemes, rules, and expressions. You can create the authentication rules, authorization rules and expressions, and audit rules for a policy domain in any order.
This chapter explains authentication schemes and authentication rules. It also explains actions, which you can associate with the possible outcomes for authentication rules. The chapter explains how to create, use, and manage these schemes, rules, and actions.
This chapter contains the following topics:
You can use the Access System to define authentication schemes and authentication rules to establish ways in which to authenticate users requesting access to the resources of your policy domains. To authenticate a user, you obtain and process information about the user to verify that the user is who he or she claims to be.
Before you read this chapter, read the following:
Chapter 3, "Configuring WebGates and Access Servers".
This chapter describes how to configure AccessGates and Access Servers, which you must do before the policy domains you create can take effect.
Chapter 4, "Protecting Resources with Policy Domains".
This chapter describes policy domains, policies, resources, and the Master Audit Rule.
Chapter 6, "Configuring User Authorization".
This chapter describes creating authorization schemes, rules, and expressions.
To configure authentication, you create the following components:
Authentication Schemes: An authentication scheme includes the method used to challenge the user for credentials. It also includes one or more steps consisting of one or more plug-ins used to perform different parts of the authentication process.
Authentication Plug-Ins: The Access System provides default plug-ins that implement certain methods used to challenge the user for credentials. The Access System also provides a credential mapping plug-in to map credentials obtained from a user requesting access to a resource to a user profile in the LDAP directory. You can use these plug-ins alone, you can replace them with custom ones, or you can use them in combination with custom ones.
Authentication Rules: Authentication rules include authentication schemes. For each policy domain, you provide one default authentication rule. You can also create one authentication rule for each of a policy domain's policies.
You can use the Access System to obtain user information to authenticate users under the following conditions:
If you store all of your user information in one branch of a single directory.
If you store all of your user information in more than one directory (using the same schema)
If you have divided storage of your user profile information logically across different branches of your directory, each with its own search base.
Searching a Single Directory: You can use authentication to search a single location (a single search base of a single directory). For example, an organization may want to limit to a single directory the search for user information required for authentication. If the information is not found in that directory, the user cannot be authenticated and the search terminates.
Searching Two Directories of the Same Type: You can use chained authentication to search two or more directories of the same type managed by the same Oracle Access Manager system.
Searching Two Directories Consecutively: An organization may use two directories of the same type to store information about its employees. The organization may want each directory to be searched until information about a user is found. If the information is found in the first directory, the organization may want to terminate the search process. If the information is not found in the first directory, the organization may want to continue the process and search the next directory. Alternatively, the organization may want to end the search if the user information is not found in the first directory, depending on the user's status.
Searching One Directory or Another Based on Conditions: The same organization may want to create another chained authentication scheme used to search one or another directory. The scheme may specify that one directory is to be searched if the user is an employee and that another directory is to be searched if the user is a vendor. For each condition, if the user information is not found in the first directory, the scheme specifies that a third directory is to be searched before the authentication process is terminated.
Searching Different Branches of the Same Directory: You can use chained authentication to search different branches of the same directory for user profile information. An organization may store some user profiles in one branch, some in another, and some in yet another. The third branch of the directory may contain legacy data. The organization may search the third branch for a user profile only if the information for the user cannot be found in the other two branches. For this purpose, the organization can configure an authentication scheme whose steps contain plug-ins to begin from the first search base, map the user's credentials to a user profile, and, if it is found, process the credentials, then terminate the search. If the user profile is not found in the first branch, the scheme's steps can direct the search to the next search base, and so on, until the user profile is found, or not.
An authentication scheme specifies how authentication is to be performed for users requesting access to a resource protected by the authentication rule that contains the scheme. A simple authentication scheme can contain a single step. For chained authentication, an authentication scheme contains multiple steps linked together to produce different behaviors depending on certain conditions.
Authentication schemes include four main components:
To describe an authentication scheme, you configure its general information. This information includes data such as the method to be used to challenge the user for credentials authenticating his or her identity and the security level the scheme provides. For details, see "Defining and Managing Authentication Schemes" .
The plug-ins you add to an authentication scheme are fundamental to it. You can use plug-ins provided by the Access System and custom plug-ins. Only the plug-ins you add to a scheme can be used for any of its steps. For details, see "Plug-Ins for Authentication" .
An authentication scheme can include one or more steps, each of which must include at least one plug-in. A step provides a way to create a discrete group of plug-ins executed in order of their position in the step. To connect the steps of a chained authentication scheme, you specify the step to be executed next, depending on the outcome of the present step. A different step may be executed next if the present step fails or if it succeeds. You can repeat a step in an authentication scheme. You can stop the authentication process after a step. For details, see "About Authentication Steps" .
Authentication flows are the possible execution paths through the steps of an authentication scheme. For a single-step scheme, the authentication flow consists of execution of the plug-ins of the step. For details, see "About Authentication Flows" .
During Policy Manager setup, the following authentication schemes are configured automatically:
Oracle Access and Identity: Used to protect Oracle Access Manager-related resources (URLs) for most directory types.
Oracle Access and Identity for AD Forest: This is only set up if you installed the Oracle Access Manager system in an Active Directory configuration; used to protect Oracle Access Manager-related resources (URLs) for Active Directory.
Anonymous: Used to unprotect specific Oracle Access Manager URLs.
The Anonymous authentication method allows users to access Oracle Access Manager-specific URLs that you do not want to protect with the Access System, for example, Web pages for self registration and lost password management.
During setup you may also have configured two authentication schemes based on configuration information in your user directory:
Basic Over LDAP: This built-in Web server challenge mechanism requires the user to enter their login ID and password.
The credentials supplied are compared to the user's profile in the LDAP directory server.
Client Certificate: This is a certificate-based user identification method.
To use this method, a certificate must be installed on your browser and the Web server must be SSL-enabled.
Every authentication scheme must contain a challenge method and a way to map the credentials provided by the user to the corresponding user profile stored in the directory. Creating an authentication scheme includes defining how the scheme challenges the user for credentials, maps the information, verifies it, and so forth. For example, a scheme's challenge method may require users to provide passwords or it may require users to provide certificates attesting to their identity.
An authentication scheme can also contain plug-ins that do additional processing, such as search multiple directories based on conditions and perform tasks based on the outcome of other processes.After you create an authentication scheme, you can add plug-ins to the scheme and then configure the scheme's steps and their execution order.
Only Master Access Administrators can create authentication schemes. See "Delegating Policy Domain Administration".
Task overview: Defining and managing authentication schemes
Review a list of existing authentication schemes to ensure that the one you want to create is not already defined. See "Listing Authentication Schemes" .
The following is a summary of tasks for defining a new authentication scheme:
Provide general information about the scheme to define it, which includes specifying the scheme's challenge method (General page). See "Defining and Managing Authentication Schemes".
Add to the scheme the plug-ins and their parameters to be used for any of the scheme's steps (Plugin page). See "Adding and Managing Plug-Ins" .
Among the plug-ins you add are ones to perform required tasks—such as mapping a user's credentials to a user profile—and optional ones to perform tasks specific to your environment. You can select from among the plug-ins provided by the Access System and any custom ones you have created.
Create one or more steps for the scheme, and name each step (Steps page). See "Configuring and Managing Steps" .
Add plug-ins to the named step (Steps page).
You add plug-ins to a named step when you create the step. You select plug-ins for a step from among those you added to the scheme.
Define the authentication flows—the flows of control through the scheme's steps (Authentication Flows page). See "About Authentication Flows".
Test the authentication flow and verify it to ensure it does not contain any loops called cycles, which could cause endless, repeated execution of the same plug-ins (Authentication Flows page).
If an authentication flow contains cycles, correct the flow (Authentication Flow page).
Enable or disable the scheme, as described in "Enabling and Disabling Authentication Schemes".
Modify the scheme as needed. See "Modifying an Authentication Scheme" .
View the scheme, as described in "Viewing an Authentication Scheme Configuration".
Remove obsolete authentication schemes. See "Deleting a Authentication Scheme".
Set up a scheme when using multiple searchbases (also known as disjoint domains or realms). See "Configuring an Authentication Scheme when Using Multiple Searchbases".
The rest of this section discusses the following topics:
Configuring an Authentication Scheme when Using Multiple Searchbases
Configuring an Authentication Scheme That Persists Over Multiple Sessions
Before you create an authentication scheme, list the existing ones to ensure that the one you want to create is not already defined. When you list authentication schemes, the list shows any new authentication schemes and any authentication schemes created for versions of Oracle Access Manager prior to version 6.5. Pre-existing schemes are converted to authentication schemes containing a single default step.
|
Note: Once you modify a pre-existing scheme, it cannot be used for systems prior to version 6.5. |
To view a list of authentication schemes
From the Access System Console, click Access System Configuration, then click Authentication Management.
View the Authentication Management: List All Authentication Schemes page that appears.
This page displays a message stating there are no authentication schemes configured, if that is the case.
An authentication scheme is defined and identified by information you specify using the General tab's Define an Authentication Scheme page. Before you define an authentication scheme, you need to determine the following:
A name for the scheme and a brief description of what it does.
An authentication scheme must have a name that is unique among all authentication schemes you create. Delegated Access Administrators who create authentication rules containing the scheme, will select a scheme from among existing schemes. Providing a brief description of each scheme makes it easier for them to do so.
The security level of the authentication scheme.
The security level of the scheme reflects the kind of challenge method and degree of security used to protect transport of credentials from the user. The security level is expressed as an integer.
The security level of a scheme also affects the single sign-on user capability. After an end user is authenticated for a resource at a specified level, the user is automatically authenticated for other resources within the same policy domain or in different policy domains, if the resources have the same or a lower security level as the original resource. For details about how to change the level, see "Changing the Security Level of an Authentication Scheme".
The type of challenge and its parameters to be used to obtain the user's credentials
The challenge method specifies how authentication is to be performed and the information required to authenticate the user. Each authentication scheme can have only one challenge method. Authentication is successful if the user credentials obtained in response to a challenge match only one DN in the directory—not more than one or none.
Usually a challenge parameter provides WebGate with additional information to perform an authentication, often used to prompt the user for information. Challenge parameters are entered in name:value format.
Whether users must be authenticated using a server enabled for Secure Sockets Layer (SSL).
For information about single sign-on, see Chapter 7, "Configuring Single Sign-On".
The URL of a server specified as the Challenge Redirect, if you want user requests to be redirected to another server for processing.
Authentication schemes may require redirection of the request to another URL to properly carry out the authentication. For example, redirection is used when an authentication request for a resource is made over HTTP but the authentication scheme requires the authentication to be made over HTTPS (secure HTTP). WebGate sends the redirect to the user's browser telling it to request a URL defined by the authentication scheme. After authentication is completed, WebGate redirects the browser back to the original requested resource.
Also, redirection is required to perform multi-domain single sign-on (SSO). For information describing how challenge redirects are used for multi-domain single sign-on, see "Multi-Domain Single Sign-On".
Whether the scheme should be enabled.
This page includes a radio button that you can set to enable or an authentication scheme. For details about enabling and disabling a scheme, see "Enabling and Disabling Authentication Schemes" .
Whether the Access Server's cache should be updated automatically with new information and changes you make to the scheme
This page includes a checkbox that you can select to specify that the cache should be updated.
To create an authentication scheme
From the landing page from the Access System, click the Access System Console link.
If you are working with the Policy Manager, click the Access System Console link at the top of the page.
From the Access System Console, click the Access System Configuration tab, then click the Authentication Management link in the left navigation pane.
On the List All Authentication Schemes page, click Add.
The Define a new authentication scheme page appears with the General tab selected, as illustrated in the following screen shot.
In the Name field, specify a name for the authentication scheme.
Each authentication scheme must have a unique name.
In the Description field, provide a brief description of the scheme.
For instance, you might explain the purpose of the scheme and its behavior.
In the Level field, enter an integer corresponding to the level of security of the scheme.
In the Challenge Method field, click the radio button for the authentication scheme challenge method you want to use (each authentication scheme can have only one challenge method see "About Challenge Methods" :
If you selected Form, Basic, or Ext for the challenge method, specify a Challenge Parameter.
For the basic Challenge Method, type a short text string to be used as a hint to help end users remember their user names and passwords for the requested resource.
Here is an example of the text string for an LDAP directory:
realm:LDAP username + password
If you selected the Form challenge method, you are required to provide the following parameters in the Challenge Parameter fields.
| Challenge Parameter | Description |
|---|---|
| form: | Indicates where the HTML form is located relative to the host's document directory.
For example, form:/login.html. |
| creds: | Lists all fields used for login in the HTML form. The parameter creds is a space-separated list.
For example: Note: You can specify the creds parameter for the other types of challenge method. |
| action: | The URL that the HTML form is posting to. |
| passthrough: | This parameter value determines whether the WebGate redirects the browser back to the original requested resource or passes the login credentials on to another program.
The Access System assumes that the URL given for the form in the authentication scheme is on the same machine as WebGate. Possible values are yes or no:
|
Determine whether you want the end user authenticated through an SSL-enabled server.
If you click Yes, the request is routed to the HTTPS server you specify in the Challenge Redirect field.
In the Challenge Redirect field, enter the URL of another server to which you want to redirect this request if authentication does not take place on the original server.
Use the host URL of the designated primary authentication server. For example:
https://www.yourcompany.com
Select the radio button to enable or disable the authentication scheme.
Click Save (or Cancel):
If you click Save, the Details for an Authentication Scheme display page appears. This page displays the information you entered for the new authentication scheme.
If you click Cancel, the configuration is not saved and the page listing all authentication schemes is displayed again.
You must include a challenge method in every authentication scheme you define. For your authentication schemes, you can use a predefined challenge method, provided by the Access System, or a custom one.
The Access System supports the following five challenge methods:
Anonymous: Users are not prompted to provide any credential information. This method allows access to Identity System-specific resources (URLs) that you do not want to protect with the Access System, for example, Self Registration.
Basic: Users must enter a user name and password in a window supplied by the Web server. This method can be redirected to SSL. See "Basic and Client Certificates" for details.
Client Cert (X509Cert): X.509 digital certificates over SSL. A user's browser must supply a certificate. See "Basic and Client Certificates" for details.
Form: This method is similar to the basic challenge method, but users enter information in the custom HTML form. You can choose the information users must provide in the form that you create. For details about form-based authentication for redirecting users to another site, see "Form-Based Authentication" .
Ext: An external challenge method (outside Oracle Access Manager) is used. Enables you to use your own authentication challenge method.
If you use Ext, you must provide the challenge parameter: creds. This parameter is a space-separated list of server variables set by the external challenge method. See the Oracle Access Manager Customization Guide for more information.
Basic and Client Certificates
Oracle Access Manager supports client certificate authentication using public key encryption cryptography and X.509 certificates. The client certificate challenge method uses the Secure Sockets Layer version 3 (SSLv3) certificate authentication protocol built into browsers and Web servers. Authenticating users with a client certificate requires the client to establish an SSL connection with a Web server that has been configured to process client certificates.
For both Basic and X.509, you can configure an AccessGate to handle unauthenticated requests received over a non-SSL connection.
|
Note: Basic authentication fails with non-ASCII login credentials. Non-ASCII user credentials are supported in only form-based authentication, as described in "Form-Based Authentication" . |
For the client certificate challenge method, you configure the AccessGate to redirect the user's browser to another server to establish an SSL connection, as mentioned previously. After the AccessGate authenticates the certificate, it redirects the user's browser back to the original URL.
Schemes Configured During Installation
If the Master Administrator selected a challenge method during installation of the Access System, the Access System configures authentication schemes automatically. The following authentication schemes provided by the Access System include a single step.
Basic: The user must type the user name and password in a window supplied by the server.
The user name and password are verified against the user's User Profile in the LDAP directory.
|
Note: If you are using the Access System-provided schemes, you must be sure the obMappingFilter of the plug-in parameter is set correctly for your directory and environment. For details, see Table 5-2. |
Client Certificate: The user must supply a digital certificate to the policy domain to complete authentication.
Oracle Access Manager supports X.509 certificates. The user's organization can determine how to obtain a certificate.
Anonymous: This method is used to unprotect specific Identity System URLs.
Users are not prompted to provide any credential information. This method allows access to Identity System-specific resources (URLs) that you do not want to protect with the Access System, for example, Self Registration and Lost Password Management.
This authentication scheme maps the credential_mapping to Anonymous User.
Oracle Access and Identity: Protects Oracle Access Manager-related resources (URLs).
When configuring challenge parameters for this type of scheme, you can only use ASCII characters.
Oracle Access and Identity for AD Forest—Protects Oracle Access Manager-related resources (URLs) for AD Forest.
This authentication scheme is only present if you configured your system to work with Active Directory.
See the Oracle Access Manager Installation Guide for information about configuration of these schemes during the installation process.
You can modify the content of an existing authentication scheme. Also, as you create an authentication scheme, you can modify any part of it.
In pre-10.4.1 versions of Oracle Access Manager, before you modified a scheme, you needed to ensure that it was not included in the authentication rules of any active policy domains, and you needed to disable the scheme. These actions are now unnecessary.
Existing authentication schemes are compatible with prior releases of Oracle Access Manager. However, if you modify an older authentication scheme, it will run on version 6.5 and later Access Servers but not on earlier versions of the Access Server.
The following procedure describes how to modify an existing scheme.
To modify the contents of an authentication scheme
Ensure that the scheme is not included in the authentication rules of any active policy domains.
See "Enabling and Disabling Authentication Schemes" for details.
Go to the landing page for the Access System and click the Access System Console link.
If you are working with the Policy Manager, click the link for the Access System Console at the top of the page.
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme you want to modify.
The Details for Authentication Scheme page appears. From this page, you can select other tabs, such as Plugins, Steps, Authentication Flow.
Click Modify.
The Modifying Authentication Scheme page appears, as illustrated in the following screen shot. You can modify the scheme's general information from this page.
If you are modifying the Oracle Access and Identity authentication scheme, you must enter ASCII characters in the Challenge Parameter field.
To modify other parts of the scheme
Select the tab for that part.
Click Modify on the page which appears.
Follow the configuration process for that page.
Click Save.
If needed, enable the scheme.
Authentication schemes must be enabled to be available for use in a rule. If a disabled scheme is used in action domains or policies, the resource is not protected.
After you create authentication schemes, you can view their contents.
To view the configuration for an authentication scheme
From the landing page for the Access System, click the Access System Console link.
If you are working with the Policy Manager, click the Access System Console link at the top of the page.
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme you want to see.
The Details for an Authentication Scheme page appears.
An authentication scheme cannot be deleted if it is in use by a policy.
To delete an authentication scheme
Launch the Access System, select Access System Console, then Access System Configuration.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Select the check box for the authentication scheme that you want to delete.
To delete more than one scheme, select the check box for each scheme.
Click Delete.
If you have multiple searchbases in your directory—also called disjoint domains or multiple realms, depending on your directory type—you need to configure an authentication scheme that enables searches for users with identical user IDs who reside in the separate searchbases (the disjoint domains).
For additional information on multiple directory searchbases (or disjoint domains, or realms), see the Oracle Access Manager Identity and Common Administration Guide.
To configure an authentication scheme for multiple searchbases (also known as disjoint domains or realms)
On Active Directory, add the plug-in for Oracle Access and Identity AD Forest to your authentication scheme.
See "Adding a Plug-In to an Authentication Scheme" for details.
For other platforms, create a custom authentication scheme similar to the following:
obMappingBase="%domain%",obMappingFilter="(&(& (objectclass=objectclassname)( loginattribute=%userid%))(|(! (obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))",obdomain="domain"
where objectclassname is the name of the Person object class, for example gensiteorgperson and loginattribute is the name of the login attribute for the Person object class, for example, genuserid. The %domain% and %userid% elements extract the user's domain and user ID.
For example:
credential_mapping obMappingBase="%domain%",obMappingFilter="(&(& (objectclass=gensiteorgperson)(genuserid=%userid%))(|(! (obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))",obdomain="domain"
Modify this plug-in:
Change the object class to your user object class.
Change the genuserid to your login attribute configured on your user object class.
In the authentication action that you define upon successful authentication using this scheme, you need to set the following values:
Type: HEADERVAR
|
Note: This must be done for both the default identity and access policy domains. |
Name: HTTP_OBLIX_UID
Return Attribute: obuniqueid
See "Setting Authentication Actions" for details.
|
Note: This must be done for both the default identity and access policy domains. |
In addition, you need to make the following configuration file changes:
Change the value of whichAttrIsLogin to ObUniqueID in:
PolicyManager_install_dir/access/oblix/apps/common/bin/ globalparams.xml
Change the value of whichAttrIsLogin to ObUniqueID.
Make the same change in the following file:
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
The Define an Authentication Scheme page of the General tab includes a radio button which you can set to enable or disable an authentication scheme.
When you create an authentication scheme, the scheme is disabled until you enable it. It is good practice to enable an authentication scheme only after you complete its configuration.
Before you disable a scheme, determine if the scheme is used in authentication rules of any active policy domains. If a scheme is disabled:
It is not available for use in authentication rules.
Resources previously protected by the scheme are no longer available to users requesting access to them.
The following error message is reported when an attempt is made to access resources protected by an authentication rule containing a disabled authentication scheme:
The authentication scheme SchemeID is invalid or has been disabled
After you modify an authentication scheme and enable the scheme, Delegated Access Administrators can use it again in authentication rules for their policy domains or policies.
To enable or disable an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
In the List All Authentication Schemes page, click the scheme you want to enable or disable.
The Details for Authentication Scheme page appears.
Click Modify.
The Modifying Authentication Scheme page appears, as follows:
Select the appropriate radio button to enable or disable the authentication scheme.
Click Save.
You can modify the content of an existing authentication scheme.
To modify a new authentication scheme as you define it, select the tab and modify the information on its pages.
Authentication schemes must be enabled to be available for use in a rule. If a disabled scheme is used in action domains or policies, the resource is not protected.
|
Note: Existing authentication schemes are compatible with prior releases of the Access System. However, if you modify an older authentication scheme, it will run on version 6.5 and later Access Servers but not on earlier versions of the Access Server. |
To modify the content of an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme you want to modify.
The Details for an Authentication Scheme page appears. From this page, you can select other tabs, such as Plugins, Steps, Authentication Flow.
Click Modify.
The Modifying Authentication Scheme page appears. You can modify the scheme's general information from this page.
To modify other parts of the scheme:
Select the tab for that part.
Click Modify on the page which appears.
Follow the configuration process for that page.
Click Save.
After you create authentication schemes, you can view their contents.
To view the configuration for an authentication scheme
Launch the Access System, select Access System Console, then Access System Configuration.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme you want to see.
The Details for an Authentication Scheme page appears.
An authentication scheme cannot be deleted if it is being used by a policy. Remove it from the policy before deleting it.
To delete an authentication scheme
Launch the Access System, select Access System Console, then Access System Configuration.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Select the check box for the authentication scheme that you want to delete.
To delete more than one scheme, select the check box for each scheme.
Click Delete.
The Access System implements single sign-on through an encrypted cookie called the ObSSOCookie. See "Configuring Single Sign-On" for details.
You can specify a challenge parameter that ensures the ObSSOCookie is only sent over an SSL connection and prevents the cookie from being sent back to a non-secure Web server.
Create an authentication scheme. See "Defining and Managing Authentication Schemes" for details.
In the Challenge Parameter field, add another field and specify the following:
ssoCookie:secure
|
Note: The Challenge Parameter is case-sensitive. Be sure to enter an uppercase C in ssoCookie. |
In the SSL Required field, click Yes to ensure the end user is authenticated through an SSL-enabled server.
You can configure an authentication scheme that allows the user to log in for a period of time rather than a single session. To do this, you adding the challenge parameter ssoCookie:max-age in the authentication scheme. This creates a persistent cookie in some browsers, rather than one that lasts for a single session. In version 10.1.4, the persistent cookie functionality works with the Mozilla browser.
To define a persistent cookie in the authentication scheme
Define an authentication scheme, as described in "Defining a New Authentication Scheme" on page 5-6.
In the challenge parameter for this scheme, add the following:
ssoCookie:max-age=time-in seconds
Where time-in-seconds represents the time interval when the cookie expires. For example, a setting of ssoCookie:max-age=2592000 sets the cookie to expire in 30 days (2592000 seconds).
An authentication plug-in is an executable shared library which participates in the user authentication process. Plug-ins are the engines of an authentication scheme. They implement challenge methods, map user credentials to user profile entries in a directory, process user credentials, perform custom tasks related to the authentication process, and so on.
The steps of an authentication scheme include one or more plug-ins. Before you can add plug-ins to a step, you must add them to the authentication scheme. You must add to the authentication scheme all of the plug-ins to be used for any of its steps.
Authentication schemes contain the following two types of plug-ins:
Access System-Provided Plug-Ins
Custom plug-ins
The rest of this section discusses the following topics:
The Access System provides plug-ins to implement the challenge methods it supports by default. These plug-ins include a credential mapping plug-in. Every authentication scheme must include a credential mapping plug-in that maps user credentials to a user profile in the directory. You can use the Access System-provided plug-in for this purpose, or you can replace it with a custom one that implements the same behavior. See "Access System Plug-Ins for Authentication Challenge Methods" for details about these plug-ins and their parameters.
You include plug-ins in a step. If execution of a plug-in provided by the Access System fails, the step that contains the plug-in fails. For details about steps and plug-ins, see "About Authentication Steps" .
In addition to replacing Access System-provided plug-ins with custom ones, you can create custom plug-ins to serve other purposes related to your authentication process. If you use more than one directory to store user profile information, you can create custom plug-ins to be used to search each directory. Also, if you store user profile information for one department in one branch of a directory and user profile information for another department in another branch of the same directory, you may want to search the branches consecutively depending on certain conditions. You can create custom plug-ins for this purpose.
If execution of a custom plug-in fails, the outcome depends on the step to be executed next as determined by the authentication flow of the authentication scheme and the return code returned by the plug-in.
For information describing how to create plug-ins to be used for authentication, see the chapter on the authentication plug-in API in the Oracle Access Manager Developer Guide.
For information about authentication flows, see "About Authentication Flows".
If you create a custom plug-in, the Access Server expects your custom plug-in to return one of the following four status codes:
ObAnPluginStatusContinue
ObAnPluginStatusAllowed
ObAnPluginStatusDenied
ObAnPluginStatusAbort
For details explaining what these return codes means and how the Access Server interprets them and responds to them, see the chapter on the authentication plug-in API in the Oracle Access Manager Developer Guide.
When you add a plug-in to an authentication scheme, the Access Server transparently assigns that plug-in an identifier. The Access System manages these numbers internally. You cannot change them or delete them.
Because the Access System uses identifiers to keep track of plug-ins, the execution order of plug-ins is not dependent on their position exclusively, and a single plug-in can be reused in the following ways:
It can be used in combination with other plug-ins to form a step.
It can be used more than once within a step. A step can contain multiple instances of the plug-in with different parameters.
It can be used for different steps of the same authentication scheme.
You can use the plug-ins you create for any number of authentication schemes, but for each authentication scheme, you must rename the plug-in so that its name is unique across authentication schemes.
You can write a custom plug-in to change the security level of an authentication scheme. In some cases, you may want to increase the security level of an authentication scheme depending on certain conditions. You may want the security level of an authentication scheme to depend on the application the user logged in from. For example, if Active Directory and a reverse proxy are among the sources your users can log in from, you may want to set one authentication security level to be used for users who log in from Active Directory and another security level to be used for users who log in from the reverse proxy.
Your code could determine the source from which the user logged in, and it could set the authentication scheme security level accordingly. It could check the current value of the ObAuthentSchemeLevel variable maintained by the Access Server in the credential list for the scheme. Your plug-in could change the security level, setting the variable value to a security level that depends on the requirements you have established for login from the application. To set the security level, you modify the value of ObAuthentSchemeLevel variable. If you do not change this value, the Access Server uses the security level already set for the authentication scheme through the user interface.
You can use the following code in your plug-in to open the credentials list file, check the ObAuthentSchemeLevel variable value, and set it to the security level you want to use for an application.
schemeLevel = pFnBlock->GetCredFn(pInfo->Creds,
"ObAuthentSchemeLevel");
if (schemeLevel ! = NULL) {
schemeLevelAsInt = atoi(schemeLevel);
schemeLevelAsInt +=10
iota(schemeLevelAsInt, buff, 10);
pFnBlock->SetCredFn(pInfo->Creds,
"ObAuthentSchemeLevel", buff);
Table 5-1 shows the predefined challenge methods and the plug-ins that support them. For each challenge method that contains more than one plug-in, the order in which the plug-ins are executed is identified.
You can use these plug-ins in their defined order (as shown in the table) within one or more steps of your authentication scheme; you can use any of them with other plug-ins of your own that provide the required functionality of the plug-ins they replace; or you can provide all of your own custom plug-ins to implement the required ones for the authentication schemes.
Table 5-1 Access System Predefined Challenge Methods and Plug-Ins
| Challenge Method | Plug-Ins and Order of Execution |
|---|---|
|
None |
|
|
Basic |
|
|
Client Certificate |
|
|
|
Note: Oracle recommends that all authentication schemes use the credential_mapping plug-in even if you select None as the challenge method. However, this is not a requirement. See "Credential Mapping Plug-In" for required parameters. |
Here is a description of the plug-ins provided by the Access System in support of the challenge methods it defines.
credential_mapping: This plug-in maps the user's userID to a valid distinguished name (DN) in the directory. You can configure the attribute to which the userID is mapped. The most common attribute it is mapped to is uid. However, it is possible for a customer to map the userID to a profile attribute other than uid by changing the obMappingFilter parameter.
A credential mapping plug-in is required for every authentication scheme. You can use the credential_mapping plug-in provided by the Access System for an LDAP directory server for this purpose, or you can provide your own plug-in. See "Credential Mapping Plug-In" for details.
validate_password: This plug-in is used to validate the user's password against the LDAP data source. It addresses the Form and Basic challenge methods. See "Validate Password Plug-In" for details.
selection_filter: This plug-in further validates the authentication credentials with some criteria. It addresses credentials provided by the user and does not use backend data sources. It addresses all of the challenge methods.
cert_decode: The plug-in validates the certificate and does not use a data source. It addresses the Client Certificate (Cert) challenge method. See "Certificate Decode Plug-In" for details.
NT/Win2000: This plug-in addresses Form and Basic challenge methods for Microsoft Windows 2000 systems. See "Windows NT/2000 Plug-In" for details.
SecurID: This plug-in addresses the Form challenge method for SecurID.
For each of the Access System-provided plug-ins described in this section, a table is provided which includes information about the plug-in, its parameters, and how it is used.
The following explanations apply to these tables:
Parameters for all plug-ins are case-sensitive. You must enter them exactly as they are shown in the tables.
Parameters not labeled as mandatory in the tables are optional.
Your authentication scheme must provide the functionality implemented by the credential mapping plug-in. It must map the user's credentials to information in the LDAP directory server. If you do not use the Access System-provided credential_mapping plug-in, you must create a custom plug-in that performs the same task. Table 5-2 gives the parameters you use for the credential mapping plug-in.
There are two parameters important to credential mapping that you must support if you provide your own plug-ins. Both are required:
obMappingBase: The search base against which the search for user credentials begins
ObMappingFilter: The search criteria for the filter
Both parameters are used to map to the user's credentials to a Distinguished Name (DN) in the directory.
Table 5-2 Credential Mapping Parameters
You can add the obuseraccountcontrol parameter to the obMappingFilter parameter used for the credential mapping plug-in. This makes it possible to filter two categories of users:
Users who have been added to your directory server, but who have not been activated in the Identity System.
Users who have been deactivated from the Identity System, but who are still in your directory server.
Here is an example of an obuseraccountcontrol term to filter out the two categories of users:
(|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED))
If obuseraccountcontrol is ACTIVATED, or there is no value, then inactive users are filtered out. The obuseraccountcontrol parameter must be used with the obMappingFilter parameter. It cannot be specified without obMappingFilter.
The validate_password plug-in validates the user's password against the specified directory server for the authentication scheme. For validate_password, the Access Server uses the same directory server against which it performed the credential_mapping plug-in with a successful outcome.
Here is an example of settings for the validate_password plug-in:
validate_password obCredentialPassword="password", obAnonUser="cn=anonymous, o=Company, c=US"
Table 5-3 describes the validate password plug-in.
Table 5-3 Validate Password Plug-In
| Name | validate_password |
|---|---|
|
Purpose |
Validates the user-provided password against the user's password in the directory. |
|
Result |
If the user-entered password matches the password in that user's directory entry, authentication continues. If not, the plug-in fails. |
Table 5-4 describes the parameters for the Validate Password plug-in.
Table 5-4 Validate Password Plugins
The certificate decode plug-in extracts the components of the certificate subject's and issuer's Distinguished Name (DN). For each component, the plug-in inserts a credential with a certSubject or certIssuer prefix. For instance, if your certificates have a subject name such as givenName=somename, the plug-in adds the credential certSubject.givenName=somename to the credential list.
Table 5-5 describes the certificate decode plug-in.
Table 5-5 Certificate Decode Plug-in
| Name | cert_decode |
|---|---|
|
Purpose |
PurposeDecodes the certificate and extracts the elements of the certificate's subject and issuer DN. This plug-in can be used with the X.509 Cert challenge method. |
|
Result |
If the decoding is successful, the elements of the certificate's subject and issuer DN are added to the list of credentials. If not, authentication fails. |
|
Parameters |
None |
If your certificate is stored in the browser, you can view the certificate details.
The following table lists the OIDs of the attributes that are supported by the Access Server with the corresponding suffix used to retrieve the attribute.
Table 5-6 OIDs Supported by the Access Server
| OID | Component lookup name |
|---|---|
|
2.4.5.3 |
CN |
|
2.5.4.4 |
SN |
|
2.5.4.5 |
Serial Number |
|
2.5.4.6 |
C |
|
2.5.4.7 |
L |
|
2.5.4.8 |
ST |
|
2.5.4.9 |
Street Address |
|
2.5.4.10 |
O |
|
2.5.4.11 |
OU |
|
2.5.4.12 |
Title |
|
2.5.4.13 |
Description |
|
2.5.4.14 |
Search Guide |
|
2.5.4.15 |
Business Category |
|
2.5.4.16 |
Postal Address |
|
2.5.4.17 |
Postal Code |
|
2.5.4.18 |
Post OfficeBox |
|
2.5.4.19 |
Physical Delivery Office Name |
|
2.5.4.20 |
Telephone Number |
|
2.5.4.21 |
Telex Number |
|
2.5.4.22 |
Telex Terminal Identifier |
|
2.5.4.23 |
Facsimile Telephone Number |
|
2.5.4.24 |
x121 Address |
|
2.5.4.25 |
International ISDN Number |
|
2.5.4.26 |
Registered Address |
|
2.5.4.27 |
Destination Indicator |
|
2.5.4.28 |
Preferred Delivery Method |
|
2.5.4.29 |
Presentation Address |
|
2.5.4.30 |
Supported Application Context |
|
2.5.4.31 |
Member |
|
2.5.4.32 |
Owner |
|
2.5.4.33 |
Role Occupant |
|
2.5.4.34 |
See Also |
|
2.5.4.35 |
User Password |
|
2.5.4.36 |
User Certificate |
|
2.5.4.37 |
CA Certificate |
|
2.5.4.38 |
Authority Revocation List |
|
2.5.4.39 |
Certificate Revocation List |
|
2.5.4.40 |
Cross Certificate Pair |
|
2.5.4.41 |
Name |
|
2.5.4.42 |
Given Name |
|
2.5.4.43 |
Initials |
|
2.5.4.44 |
Generation Qualifier |
|
2.5.4.45 |
Unique Identifier |
|
2.5.4.46 |
DN Qualifier |
|
2.5.4.47 |
Enhanced Search Code |
|
2.5.4.48 |
Protocol Information |
|
2.5.4.49 |
Distinguished Name |
|
2.5.4.50 |
Unique Member |
|
2.5.4.51 |
House Identifier |
|
2.5.4.52 |
Supported Algorithms |
|
2.5.4.53 |
Delta Revocation List |
|
2.5.4.58 |
Certificate Attribute |
|
2.5.4.65 |
Pseudonym |
|
1.2.840.113549.1.9.1 |
E |
|
0.9.2342.19200300.100.1.1 |
UID |
Notice that most of the names are space separated. The following is an excerpt of code used to retrieve these values from an authentication plug-in:
sn = pFnBlock->GetCredFn(pInfo->Creds, "cerSubject.Serial Number");
To view the certificate details
Open up an IE browser.
In Tools menu click Internet Options.
Click the Content Tab.
Click the Certificates button.
Double-click your certificate.
Click the Details tab.
Click the Subject line.
By default, the directory server validates user passwords. To increase performance, you can use the Access Server to validate passwords after the first time they are validated by the directory server.
For this purpose, you must:
Include the validate_password plug-in in an authentication scheme
Set the plug-in's obCredValidationByAS parameter to true
When the obCredValidationByAS parameter is set to true, the Access Server caches an MD5 hash of a user's password after it is validated by the directory server.
The next time the user attempts to access a resource within the same policy domain, the user's password is compared with the cached password. If the two match, the given password is validated and the user is granted access to the requested resource.
Another parameter, obPwdHashTTL, controls the length of time the Access Server validates passwords. The default is 1800 seconds (30 minutes). You can change this value. When the specified length of time elapses, the password validation function returns to the directory server.
Here is an example of settings for these parameters that allow the Access Server to validate passwords for 100 seconds:
validate_password obCredentialPassword="password",, obCredValidationByAS="true", obAnonUser="cn=anonymous, o=Company, c=US", obPwdHashTTL="100"
The steps of an authentication scheme include one or more plug-ins. Before you can add plug-ins to a step, you must add to the authentication scheme all of the plug-ins to be used for any of its steps.
For information about defining plug-ins, see "Plug-Ins for Authentication" (UNKNOWN STEP NUMBER) .
The first time you add plug-ins to an authentication scheme, the Access System creates a default step that includes all of them. If you are using an authentication scheme from a release prior to the version 6.5 Access System, the Access Server creates a default step for the authentication scheme containing all of its plug-ins.
The rest of this section discusses the following topics:
You can list an authentication scheme's plug-ins at any time. For example, you may want to list the plug-ins to see ones already added to that scheme before you add others. The plug-ins list displays the names and parameters of the plug-ins already added to the authentication scheme. The list may include any Access System-provided and custom plug-ins previously added to the scheme.
|
Note: It is possible to have more than one credential_mapping plug-in in a scheme. |
To view the list of plug-ins for an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The List All Authentication Schemes page appears.
In the List All Authentication Schemes page, click the scheme for which you want to display a list of plug-ins.
Select the Plugins tab.
The plug-ins for an Authentication Scheme page appears, as illustrated in the following screen shot.
When you add a plug-in to an authentication scheme, you specify the name of the plug-in and its parameters. You can add the same plug-in more than once to an authentication scheme if each instance of the plug-in has different parameters. Each instance of a plug-in with unique parameters appears as a separate plug-in in the list.
Use the following task to add a plug-in to an authentication scheme, whether you are adding it to a new scheme or an existing one.
To add plug-ins to an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the link for an authentication scheme.
The Details for an Authentication Scheme page appears.
Click Modify.
The Details for Authentication Scheme page appears.
Select the Plugins tab to display the plug-ins for this authentication scheme.
Click Modify
The Plugins for Authentication Scheme page appears, as illustrated in the following screen shot.
Click Add.
The Plugins for Authentication Scheme page appears, as illustrated in the following screen shot. This page includes a list and a text box for selecting and defining the plug-in to be added. You either select a Access System-provided plug-in or enter the name of the custom plug-in in the Plugin Name box.
A credential mapping plug-in is required for every authentication scheme. You can select the Access System-provided plug-in, or you can select a custom one that implements the same behavior. You either select a plug-in from the right-most Plugin Name text box or enter the name of a custom plug-in in the text box.
For details describing the credential_mapping plug-in, including requirements your custom plug-in must meet if you provide a replacement, see "Credential Mapping Plug-In" . Each parameter can have multiple values.
To add more plug-ins, click the Add button after you finish adding the previous one. Repeat this step for each plug-in that you want to add.
Click Save to save the plug-ins you configured (or click Cancel to exit the page without saving the plug-ins).
Note that the authentication schemes that use the plug-ins must be enabled to be available for use in a rule. If a disabled scheme is used in action domains or policies, the resource is not protected.
You can remove a plug-in from an authentication scheme, but you must first remove the plug-in from any steps of the scheme that include it.
To delete plug-ins from an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Select the name of the authentication scheme whose plug-in you want to delete.
The Define an Authentication Scheme page appears.
Click Modify.
Select the Plugins tab to display the plug-ins for this authentication scheme.
Click Modify.
The Plugins for Authentication Scheme page appears.
Select the plug-in that you want to delete by checking the box before the name of the plug-in. To delete more than one plug-in, select each of them.
Click the Delete button at the bottom of the list to delete the selected plug-ins from the authentication scheme.
Click Save.
When a user requests access to a resource protected by an authentication rule, the rule's authentication scheme determines the way in which authentication is to be performed. For chained authentication schemes, this process includes obtaining user credentials and mapping those credentials to a user profile. A chained authentication scheme can be designed to do this and more. For example, instead of limiting the search for a user profile to one directory, a chained authentication scheme can support attempts to map the credentials to a user profile in one directory, another directory, or yet another directory consecutively, until the information is found. It can also include additional processes indirectly related to the authentication process.
Process overview: A simple chained authentication scheme
The rest of this section discusses the following topics:
Here is an overview of the process you use to set up chained authentication for a policy domain. This process assumes that the policy domain exists and that the plug-ins to be used have already been defined.
You use the Access System Console for all of the following steps except the last one—creating an authentication rule. To create an authentication rule for a policy domain, you use the Policy Manager.
Task overview: Defining and using a chained authentication scheme
Define a chained authentication scheme, as described in "Defining and Managing Authentication Schemes".
Before you can create an authentication scheme containing one or more steps, you must first define the scheme. This process includes specifying the challenge method to be used.
Add to the chained authentication scheme all of the plug-ins to be used for its steps, as described in "Adding and Managing Plug-Ins" .
For example:
Select a plug-in to be added from among the ones the Access System provides by default, or specify existing custom plug-ins.
Specify the parameters for each plug-in as you add it to the scheme. You can add more than one instance of a plug-in to a scheme, each with its own set of parameters.
Repeat this process for as many plug-ins as you want to add to the scheme.
|
Note: When you add plug-ins to an authentication scheme, the Policy Manager creates a default step and adds them to it. |
Add the steps of the authentication scheme, as described in "Configuring and Managing Steps".
Before you create a step, consider its purpose within the authentication scheme and in relation to other steps of the scheme.
Planning for the steps of a scheme and the scheme's flows are interdependent processes. You can use steps to isolate plug-ins into groups. You can then connect those groups of plug-ins—that is, connect their steps—in different ways, creating different authentication flows.
Here is how to add a step to an authentication scheme:
Give the step a meaningful name. Well-chosen names are helpful if you rearrange the steps of a scheme.
Add plug-ins to the step.
Arrange the plug-ins in the order in which you want them executed.
Take into account how the result of a plug-in affects the result of a step for:
The Access System
If any Access System-provided plug-in fails, the step fails.
Custom plug-ins
For details, see "Return Codes for Plug-Ins".
Add as many steps as are necessary to complete the authentication process for your environment.
Create the authentication flows of the chained authentication scheme, as described in "About Authentication Flows".
Plan the authentication flows of a scheme. Before you configure a scheme's authentication flows, take the time to plot the actions you want to occur for each step.
Here is how to create a scheme's authentication flows:
Determine which step you want to be executed first. Mark it the initiating step.
Configure the links for the step:
Determine the next step to be executed if the plug-ins of a step cause the step to fail.
Determine the next step to be executed if the plug-ins of a step cause the step to succeed.
Verify the flows of the chained authentication scheme, as described in "About Authentication Flows".
Test the way you configured the flows—that is, the connections between the steps creating flows—to ensure that there are no cycles.
Correct the flows of the chained authentication scheme, if necessary, as described in "About Authentication Flows".
Enable the authentication scheme after you are satisfied with its configuration, as described in "Enabling and Disabling Authentication Schemes" .
Create an authentication rule which includes the chained authentication scheme for the policy domain, as described in "Authentication Rules".
Specify actions for the authentication rule to be taken if authentication fails or if it succeeds based on the rule. For details, see "Authentication Actions" .
An authentication scheme includes one or more steps whose execution order is determined dynamically. Execution of the steps of an authentication scheme begins with the one chosen as the starting, or initiating, one. From the starting step and for each succeeding step, the step to be executed next is determined by the result of the preceding step.
Each step of an authentication scheme contains one or more plug-ins. Plug-ins within a step are executed in the order in which you position them.
At any time, you can change
The connections between the steps of an authentication scheme.
The order of a step's plug-ins.
Within a step, if any Access System-provided plug-in fails, the Access Server treats the step as if it failed and stops execution of the step at that point.
For information describing how the Access Server responds to a step containing a custom plug-in based on the execution result of that plug-in, see"Return Codes for Plug-Ins" .
Figure 5-1 illustrates a prototype for a sample authentication scheme.
Table 5-7 summarizes the step components.
Table 5-7 Aspects of a Step
| Component | Summary |
|---|---|
|
Step Name |
A step is a discrete entity. Each step must have a unique name. |
|
A plug-in provides an authentication scheme's functionality. A step can contain one or more plug-ins, but it must contain at least one. The parameters a plug-in can take are specified when the plug-in is added to the scheme, not when it is added to a step. |
|
|
Number of Steps |
An authentication scheme can contain any number of steps, but it must contain at least one. |
|
Connections Between Steps |
Steps are connected to form one or more flows of an authentication chain. Because steps are discrete, they can be combined in any order. Connections between steps are established by defining possible authentication flows—or flows of execution—through the authentication chain. See "About Authentication Flows" for details. |
|
Execution of Steps |
Steps are executed in the order in which they occur in a flow of the authentication chain. The plug-ins of steps are executed in the order in which they are positioned in a step's list of plug-ins. The order of plug-ins in a list can be changed. Execution of one step's plug-ins is followed by execution of those of the next step in the authentication flow. |
Many authentication schemes are simple enough to require only a single step. In such a case, the step must contain all of the plug-ins required to transact the purpose of the scheme. Because it is the only step in the authentication scheme, the authentication scheme's flow consists of execution of the step's plug-ins.
You can use the Policy Manager's authentication feature to create a single step that provides all of the functionality you may require to obtain user credentials, map them to an entry in the directory server, authenticate the user, and so forth.
It is easy to create and manage an authentication scheme with a single step, and it makes good sense to include all plug-ins in a single step in many cases. For example, a single-step authentication scheme is useful if a group of plug-ins are meant to be executed consecutively and, in the event of failure, you do not care which plug-in causes the step to fail.
You may want to separate plug-ins into steps because the plug-ins form a set meant to be executed together. Also, combining the plug-ins in a step enables you to use that step in a scheme more than once. You may want to configure it as the next step to be executed for one step if that step fails, and as the next step to be executed for another step if that step succeeds.
You may also find it necessary to separate plug-ins into discrete steps even if two plug-ins form a couple logically. For example, you may want to take this approach if you must know which of two plug-ins caused the authentication process to fail.
There are many cases for which you may want to separate closely related plug-ins into discrete steps. Use of the password management feature offers an example of one case. An organization uses password management to control user access. Based on the number of attempts specified in the password policy, it gives a user a certain number of opportunities to enter the correct password. If authentication fails, the administrator must know why. The administrator must be able to distinguish between the following two events:
Whether authentication fails because there is no entry for the user in the directories checked.
Whether authentication fails because the user entered the wrong password each time for the three allowed attempts.
For example, an organization uses two different parts of its directory to store user profile information for its human resources department and for its marketing department. The organization wants to be able to search across both branches of the directory for user profile information to authenticate users. The organization wants the search to begin with the search base for the human resources information and if the user profile information is not found there, continue with the search base for the marketing department.
Search Base A
Includes entries for all human resources department members.
Examples:
cn=Maurice Breton
cn=Alice Smith
Search Base B
Includes entries for all marketing department members.
Example:
cn=Sonal Kalra
cn=Robert Jang
The organization defines the following chained authentication steps:
Step 1: Credential mapping
Success: Execute Step 2
Failure: Execute Step 3
Step 2: Validate password
Success: Execute Step 4
Failure: Stop
The validate password plug-in gives the user three attempts to enter a valid password, which is based on a setting in the password policy, before it fails Step 2.
Step 3: Custom plug-in to check Search Base B
Success: Execute Step 2.
Failure: Stop
Step 4: Custom plug-in to do some additional processing
Success: Stop, return result.
Failure: Stop, return result
Sonal Kalra requests access to a resource protected by this authentication scheme. She enters her user name. Here is the process that occurs:
The Access Server searches Search Base A for an entry for Sonal Kalra.
There is no entry.
Evaluation of Step 1: failure. On failure, go to Step 3.
The Access Server searches Search Base B for an entry for Sonal Kalra
An entry with cn=Sonal Kalra is found.
Evaluation Step 3: success. On success, go to Step 2.
Sonal Kalra is prompted for her password
She enters the wrong password the first time. Step 2: validate password prompts her for her password three times before returning a failure.
At the second prompt, she enters the correct password.
Evaluation of Step 2: On success, go to Step 4.
Some additional processing is done, which completes successfully (Step 4: On success: Stop, return result).
If Sonal Kalra entered the wrong password for each of the three attempts, Step 2: validate password, would return a result of failure, and the authentication process would stop. The Delegated Access Administrator would know why the authentication process failed—not because no user entry was found for Sonal Kalra, but because she entered the wrong password three times.
About the Default Step
The first time you add plug-ins to an authentication scheme, the Policy Manager defines a default step that contains all of the plug-ins. You can modify the default step if you want to use it, or you can delete it after you add one or more additional steps to the scheme. An authentication scheme must include at least one step.
After you define an authentication scheme and add plug-ins to it, you can configure its steps. You can modify the steps of an authentication scheme at any time, but you must first ensure that the scheme is not used by any active policy domains. You can add plug-ins to a step or remove them from one, or you can delete the step.
The rest of this section discusses the following topics:
You can view a list of the currently configured steps of an authentication scheme.
To view the steps of an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme whose steps you want to see on the Authentication Management: List All Authentication Schemes page.
The Details for Authentication Scheme page appears. By default, the General page is displayed.
Select the Steps tab.
The Steps for Authentication Scheme page appears, as illustrated in the following screen shot. This page displays the names of all the steps configured for the scheme. Each step's name is a link, which you can click to display details about the step.
If you are creating an authentication scheme and have not yet added any steps to it, or if the scheme contains only a single step, this page shows only a step called Default Step. See "About the Default Step" for details.
You can view the details of the current configuration of a step for an authentication scheme any time after it is created.
To view the details for a step
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme containing the step whose configuration details you want to see.
The Details for Authentication Scheme page appears. By default, the General page is displayed.
Select the Steps tab.
The Steps for Authentication Scheme page appears. This page displays the names of all the steps configured for the scheme.
Click the name of the step whose configuration you want to see.
The Steps for Authentication Scheme page appears again, as illustrated in the following screen shot, this time showing the details for the selected step.
To add a step to a scheme, you name the step and add to it the plug-ins that provide the step's functions. For steps with more than one plug-in, the order in which you position the plug-ins in the step determines their execution order. The highest order plug-in—the one at the top of the list—is executed first.
When you add a plug-in to a step, it is placed at the bottom of the list of active plug-ins. You can rearrange the order of plug-ins in a step.
To add a step to an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme on the Authentication Management: List All Authentication Schemes page.
The Details for Authentication Scheme page appears. By default, the General page is displayed.
Select the Steps tab.
The Steps for Authentication Scheme page appears.
If you are creating an authentication scheme and have not yet added any steps to it, this page shows only a step called Default Step. See "About the Default Step" for details.
Click Add.
The Modify an Authentication Step page appears, as illustrated in the following screen shot. Note that although this page is titled Modify, it is used to add a step as well as to modify the content of an existing one.
Enter a unique name for the step in the Step Name text box.
From the list of available plug-ins, select the plug-in to be added to the step and click Add.
The name of the plug-in appears in the Active Plugins scroll box.
Repeat this step for as many plug-ins as you want to include in the step.
To reposition plug-ins within the step, select the plug-in in the list of active plug-ins, and click the appropriate arrow key to move the plug-in up or down in the list.
Click Save.
You can modify existing authentication steps. For example, you may want to upgrade a step's plug-ins, replacing one with another, or you may want to add new plug-ins to a step to extend or change its function. You may also want to remove plug-ins which are no longer used.
To add, remove, or re-order plug-ins in an existing step
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme whose step you want to change.
The Details for Authentication Scheme page for that scheme appears.
Select the Steps tab.
The Steps for Authentication Scheme page appears.
Click the name of the step that you want to modify.
The Steps for Authentication Scheme page appears, showing the plug-ins and parameters for the step.
Click Modify.
The Modify an Authentication Step page appears.
Change the plug-ins in the step in any of the following ways:
To add a plug-in to the Active Plugins list, select the plug-in from the Available Plugins list and click Add.
To remove a plug-in from the active list, select the plug-in from the Active Plugins list, and click Delete.
To change the order of plug-ins in the Active Plugins list, select the plug-in you want to move. Use the arrow keys to move the plug-in up or down in the list.
Click Save to save the step after you are satisfied with the changes.
You can delete one or more steps from a scheme. An authentication scheme must have at least one step.
To delete a step from an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Click the name of the authentication scheme whose step you want to delete.
The Details for an Authentication Scheme page for that scheme appears.
Select the Steps tab.
The Steps for Authentication Scheme page appears.
Select the step that you want to delete.
Select the check box for each step that you want to delete, if you want to delete more than one.
Click Delete.
An authentication flow is a path of execution through steps of an authentication scheme, or, for single-step authentication schemes, through their plug-ins.
Either of the following kinds of authentication schemes has an authentication flow:
A single-step authentication scheme
The authentication flow of an authentication scheme containing a single step consists of the flow of execution through that step's plug-ins in the order in which they appear in the step. For a description of single-step schemes, see "About Single-Step Authentication Schemes".
A chained authentication scheme
The authentication flows of a chained authentication scheme consist of the execution of the plug-ins of one step after another in a flow. A chained authentication scheme can have one flow or many flows. The execution order of the authentication scheme's steps can vary to create different possible authentication flows, depending on the outcome of each step in a flow.
For each step of an authentication scheme, you configure the next step to be executed based on the result of the current one. If the current step fails, the step you configured for that step's failure result is executed next. If the current step succeeds, the step you configured for that step's success result is executed next. The plug-ins of any of the steps of an authentication flow are executed in the order in which they appear in the step.
You use the following means to configure the steps of an authentication scheme to produce various possible flows:
Mark a step as the initiating step of the chained authentication scheme.
All possible flows of a chained authentication scheme begin with the same step. Each authentication scheme can have only one step designated as the initiating step.
Specify the next step to be executed if the present step fails or if it succeeds.
This mechanism enables you to configure different flows of a chain, each of which is determined by the result of the current step.
Use the Stop terminator.
Any step of a chain may be followed by the Stop terminator. You can specify that execution is to stop if a step fails or if it succeeds. For either case, you set the failure condition or the success condition of the step to Stop. You can terminate execution after a step absolutely by setting both conditions of the step's result to Stop.
You may want execution to terminate under more than one condition for the flows of a chained authentication scheme, depending on the possible flows. Stop indicates that a flow has ended and no other steps of the authentication chain are executed.
The rest of this section discusses the following topics:
An administrator for a company wants to organize the plug-ins used for authentication into steps so that she can more easily control the order in which they are executed. The administrator wants the result of execution of one plug-in to determine the next plug-in to be executed. If the plug-ins were to be executed in order, it would not be necessary to separate them into steps. The company uses the four plug-ins identified in Table 5-8 for its authentication process.
Table 5-8 Plug-Ins for Authentication Flow Example
| Plug-In | Use |
|---|---|
|
Plug-in 1: credential_mapping |
Access System-provided credential mapping plug-in |
|
Plug-in 2: validate_password |
Access System-provided password validation plug-in |
|
Plug-in 3: custom_pluginA |
do_what_I_want: A |
|
Plug-in 4: custom_pluginB |
do_what_I_want: B |
The administrator has determined that she wants to combine her authentication plug-ins into steps that allow her to define the following authentication flows:
If plug-in 1 is successful (credentials mapped to user entry)
Execute plug-in 2 (validate the user's password)
If plug-ins 1 and 2 are successful (user's credentials map and user's password is valid)
Execute plug-in 4 (do_what_I_want:B)
If plug-in 1 or 2 fails (either the user's credentials cannot be mapped to an entry or the user's password is invalid)
Execute plug-in 3 (do_what_I_want:A)
If plug-in 3 succeeds (do_what_I_want: B),
Execute plug-in 4 (do_what_I_want:B)
The administrator creates the three steps identified in Table 5-9.
Table 5-9 Steps for Authentication Flow Example
| Step | Plug-Ins Used | Step Result |
|---|---|---|
|
Step 1 |
Plug-in 1 and Plug-in 2 |
Succeeds if both Plug-in 1 and Plug-in 2 succeed. Fails if either of the plug-ins fails. |
|
Step 2 |
Plug-in 3 |
Succeeds if Plug-in 3 succeeds. Fails if Plug-in 3 fails. |
|
Step 3 |
Plug-in 4 |
Succeeds if Plug-in 4 succeeds. Fails if Plug-in 4 fails. |
She combines the plug-ins in Table 5-8 with the steps in Table 5-9 to create the desired authentication flows. Table 5-10 shows the steps of the authentication scheme and which step is executed next if the step succeeds or if it fails.
Table 5-10 Outcome of Steps for Authentication Flow Example
| Step | On success | On failure, executes |
|---|---|---|
|
Step 1 |
Step 3 |
Step 2 |
|
Step 2 |
Step 3 |
Stop |
|
Step 3 |
Stop |
Stop |
Figure 5-2 provides a diagram of the authentication flow table.
At any time after you configure the authentication flows for an authentication scheme, you can look at the configuration by selecting the Authentication Flow tab. The Flow of the Authentication Scheme page shows the current configuration. After you add a step to an authentication scheme, by default the Policy Manager assigns the Stop terminator to the On Success Next Step and On Failure Next Step result conditions of each step. The Flow of the Authentication Scheme page shows this default configuration until you modify it.
To view the configuration of an authentication flow
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Select the name of the authentication scheme whose authentication flows you want to view.
The Details for Authentication Scheme page for the authentication scheme appears.
Select the Authentication Flow tab.
The Flow of the Authentication Scheme page appears.
After you add steps to an authentication scheme, you can configure the possible flows of execution through the steps. You use the Flow of the Authentication Scheme page to configure the On Success Next Step and On Failure Next Step result conditions for each step.
At any time, you can use the same page to modify the flows of the authentication scheme. You can change the links between steps in a chain to correct cycles or to redirect flows.
To configure the flows of an authentication scheme
From the Access System Console, click the Access System Configuration tab.
Click the Authentication Management link in the left navigation pane.
The Authentication Management: List All Authentication Schemes page appears.
Select the name of the authentication scheme whose authentication flows you want to configure.
The Details for Authentication Scheme page for the authentication scheme appears.
Select the Authentication Flow tab.
The Flow of the Authentication Scheme page appears. For existing steps, this page shows the connections between steps of the chain. If there is only one step for the scheme, it appears here.
Click Modify
The Flow of the Authentication Scheme page with modifiable entries appears. The page shows the names of the scheme's steps. For each step, the page includes lists from which to choose the next step to be executed if the current one succeeds or if it fails.
Choose the step to be used as the initiating step by selecting the radio button for the step in the Initiating Step column.
Only one step can be configured as the Initiating step.
For each step in the Step Name column, complete the following:
In the list under the On Success Next Step column, select the next step to be executed if the present one succeeds.
In the list under the On Failure Next Step, select the next step to be executed if the present one fails.
If you want execution to terminate after a step is completed, select the Stop terminator. You can use Stop for success of a step or for failure of a step.
Both selection lists show the names of all steps configured for the chained authentication scheme.
After you are satisfied with the configuration, click Verify Flow to determine if it contains cycles.
See "Verifying and Correcting Cycles in an Authentication Flow" for details.
Click Save after you have determined that there are no cycles in the flows.
Because the flows of an authentication chain can be complex, it is possible for a chain to include cycles.
After you define how the steps of a scheme are connected, you can click the Verify Flows button to check the configuration for cycles before you save it.
The Verify Flows button appears when you click the Authentication flow sub-tab, then click Modify, as illustrated in the following screen shot.
If the authentication flow's configuration contains cycles, the Policy Manager identifies the offending flow on the All Flows in the Chained Authentication Scheme page. You cannot save the configuration until you correct the cycles. If you attempt to save an authentication flow's configuration without having verified it first, the Policy Manager automatically checks the configuration to ensure that none of its lows contain cycles.
Although the Policy Manager verifies the authentication flows to check for cycles, it is good practice to plot the flows of a complex authentication scheme well before you configure them. To correct flows containing cycles after they are reported on the All Flows in the Chained Authentication Scheme page, you use the Flow of the Authentication Scheme page.
The All Flows in the Chained Authentication Scheme page shows all of the configured flows, depicting them in the following way:
The All Flows in the Chained Authentication Scheme page shows all of the configured flows, depicting them in the following way:
Flows without cycles are shown in black.
Flows with cycles are shown in red.
To correct an authentication flow containing a cycle
From the Access System Console, click Access System Configuration tab, then click Authentication Management, in the left navigation pane.
Click the link for the multi-step authentication scheme.
Click the Authentication Flow sub-tab.
Click Modify.
Click Verify Flow.
If there is an error in the flow of the steps, the reported flow and its offending step in the flows display of the All Flows in the Chained Authentication Scheme page, as illustrated in the example of a flow with cycles in the following screen shot.
If the verification process reports more than one flow containing cycles, note and correct all of them.
Click Back on the All Flows in the Chained Authentication Scheme page, which reports the offending flow.
The Flow of the Authentication Scheme page appears.
Correct the problem within the flow that contains the cycle.
"Configuring and Modifying the Flows of an Authentication Chain" describes the process to use to create authentication flows. Follow this process to modify the connections between the offending steps.
Click Verify Flow.
If the verification results show more flows with cycles, continue to correct the flow.
After all problems causing the cycle are resolved, click Save.
Each policy domain must include a single default authentication rule, and each policy in a domain can include an authentication rule specific to the policy. If a policy does not include an authentication rule, it inherits protection by the default authentication rule established for the entire policy domain. Figure 5-3 illustrates conceptually the set of default rules for a policy domain, among which is an authentication rule. In this example, no policies have been created yet for the policy domain.
An authentication rule includes an authentication scheme that specifies the kind of authentication required to verify a user's identity, the directory server to be checked for user information, and so on. See "Authentication Schemes" for details.
Whenever a user requests access to a resource protected by an authentication rule, the user must authenticate using the challenge method specified by the rule's scheme.
Delegated Access Administrators can create authentication rules for the policy domains and their policies for which they have administrative rights.
The rest of this section discusses the following topics:
For each policy domain, you must define a single default authentication rule.
To create a default authentication rule for a policy domain
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
A list of policy domains appears.
Click the link for the policy domain that you want to view.
The General page for the selected policy domain appears.
For the selected policy domain, select the Default Rules page.
If there is an authentication rule already configured for the policy domain, the Authentication Rule page appears showing the definition of the rule.
There can be only one default authentication rule for a policy domain. If there is an existing default authentication rule, you must delete it before you can add a new one. For details, see "Deleting a Policy Domain's Authentication Rule".
Click the Add button on the Authentication Rule page.
The General page for the Authentication Rule appears.
Enter a Name for the default authentication rule.
Enter a Description for the default authentication rule.
Select an authentication scheme.
The list shows enabled authentication schemes created by the Master Access Administrator. To add new schemes, see "Defining and Managing Authentication Schemes" . Authentication schemes that are disabled do not appear in the list.
Click Save.
You can modify the authentication rule for any policy domain for which you have administrative rights, including any policy domain that you have created.
To modify a policy domain's authentication rule
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
A list of policy domains appears.
Click the link for the policy domain that you want to view.
The General page for the selected policy domain appears.
Click Default Rules.
The General page for the Authentication Rule tab appears. It shows the current configuration for the rule.
Click Modify.
The General page, whose fields you can modify, appears.
Change the Name, Description, and Authentication Rule as necessary.
Click Save to save your changes or click Cancel to exit the page without saving.
Because a policy domain can have only one authentication rule, you must delete the existing rule before you can add a new one.
To delete a policy domain's authentication rule
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
A list of policy domains appears.
Click the link for the policy domain that you want to view.
The General page for the selected policy domain appears.
Click Default Roles
The General page for the Authentication Rule tab appears showing the currently configured rule.
Click Delete.
Answer Yes to the prompt, to confirm the deletion.
For any policy domain, you can create special policies for groups of resources within the domain. All resources of a policy domain are protected by its default authentication rule unless the resource is covered by a policy containing a different authentication rule. You define an authentication rule for a policy just as you would for a policy domain, but you define the rule in association with the policy.
If an authentication rule exists for the policy and you want to replace it, you must delete the rule before you can create a new one. See "Deleting an Authentication Rule for a Policy" for details.
To create an authentication rule for a policy
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
Click the link for a policy domain.
The General page for the selected policy domain appears.
Click the Policies tab.
The Policies page appears listing all of the existing policies, if any.
Click the link for the Policy for which you want to add an authentication rule.
The General page showing the configuration for the policy appears.
Click the Authentication Rule sub-tab for the policy.
Click Add.
The General page for defining an authentication rule appears.
Enter a Name for the default authentication rule.
Enter a Description for the default authentication rule.
Select an authentication scheme.
The list shows the authentication schemes created by the Master Access Administrator. To add new schemes, if required, see "Defining and Managing Authentication Schemes".
Click Save.
You can modify the authentication rule for a policy within a policy domain for which you are granted administrative rights and for a policy within a policy domain that you have created.
To modify a policy's authentication rule
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
Select the policy domain whose authentication rule you want to modify.
The General page for the selected policy domain appears.
Select the Policies tab to display a page listing all existing policies.
From the list of policy names, select the Policy whose authentication rule you want to modify.
The Policies General page appears showing the configuration for the policy.
Select the Authentication Rule tab.
The Authentication Rule General page appears, listing the definition of the authentication rule, as illustrated in the following screen shot.
Click Modify.
The Authentication Rule General page form appears enabling you to edit the information using text boxes and a list.
Modify the definition of the policy's authentication rule as necessary, changing its name, description, or the authentication scheme it includes.
Click Save.
You can delete the authentication rule for a policy within a policy domain if you are granted administrative rights, and for a policy within a policy domain that you have created.
To delete a policy's authentication rule
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
The General page for the selected policy domain appears.
For the selected policy domain, select the Policies tab.
The Policies page appears listing all of the existing policies.
Select the Policy whose authentication rule you want to delete.
The General page showing the configuration for the policy appears.
Select Authentication Rule.
The General page showing the definition of the authentication rule appears.
Click Delete.
Answer Yes to the confirmation prompt.
You can configure an authentication rule that returns actions to be taken depending on the outcome of the rule. You can also specify actions to be taken depending on whether authentication succeeds or fails.
Actions allow you to pass user profile information for the user requesting the resource to other applications or to redirect the user's browser to another site.The use of actions is optional.
Actions are used in the following ways:
If an allow result is returned, the actions of the rule that determined the allow result are taken.
If a deny result is returned, the actions of the rule that determined the deny result are taken.
The rest of this section discusses the following topics:
Defining Actions for a Policy's Authentication Rule
Triggering Authentication Actions After the ObSSOCookie is Set
Actions allow you to:
Redirect the user's browser to another URL.
You can redirect URLs from the Access Server to an AccessGate or a WebGate.
Pass information about the user to downstream applications in the same policy domain or a different one.
Using HTTP header variables or cookies, you can use actions to pass the following kinds of information:
User profile information
A user's DN
Static text strings
See "About the Use of HTTP Header Variables and Cookies" for details about using header variables to pass information to downstream applications.
Consider the 4K size limit of the HTTP header when you use HTTP header variables and cookies to pass information to downstream applications. This HTTP header size limit includes all cookies, server variables, and environment variables—that is, all of the content of the HTTP header. There is no constraint on the number of individual elements an HTTP header can contain if the content does not exceed the 4K limit. Therefore, when assessing the amount of available space in the HTTP header, take into account the byte size of the data used by the applications. For example, if the Identity System and other applications combined used 1K in the HTTP header, you would have 3K for your data.
You can use actions for many purposes. The following table provides some examples of how to use actions.
Table 5-11 Examples of how to use actions
|
Important: Redirection and use of header variables are mutually exclusive. |
You can use HTTP header variables as vehicles for passing static values or identifying attributes. Authentication actions occur once during a user's session—when the user logs in. Header variables passed as authentication actions are not persistent during a user's session. A header variable is limited to 4KB. This size includes cookies, the server, and environment variables.
If a header variable's value is changed, the new value is not available until the Access Server cache is refreshed.
There are two cache timeout parameters that affect header variables:
User Cache Timeout: When an attribute in the header variable is obtained from the directory, it is placed in the user cache. If the value of this attribute changes and there is no user cache flush request for that user, the Access Server does not know about this change until the user cache timeout occurs. At this point, the Access Server retrieves the data again from the directory.
Policy Cache Timeout: For policy data, if a user changes the return attribute in an action, and this change does not reach the Access Server (for instance, if a cache flush failed), the Access Server does not know about this action until the policy cache timeout limit is reached.
Web servers process header variables differently. This variability affects how you must implement header variables in your applications.
Here are some examples:
Netscape/iPlanet Web servers precede Access System variables with the string, HTTP:
If you define a variable called HTTP_CN, Netscape/iPlanet produces a variable called HTTP_HTTP_CN.
When you write an application that needs to read a header variable, the application must look for a variable called HTTP_HTTP_CN and not HTTP_CN.
Microsoft IIS expects header variables to be defined with a dash, not an underscore. You would enter HTTP–CN, not HTTP_CN.
The receiving application must read the variable as if it had an underscore. It looks for HTTP_CN, not HTTP–CN.
The Lotus Domino Web server cannot pass Access System header variables.
For information about how to use header variables for various servers, refer to your Web server's documentation.
You can use actions to redirect a user from the target page to a different one. You can use form-based authentication to send users to another page when authentication succeeds, rather than to the originally requested URL. This is a popular use of redirection.
For example, a user might request www.dirac.com/spin/index.htm.You could create a custom form to be used to challenge the user. After the user is authenticated based on information they enter in the custom form, you might redirect the user to your main portal page. You could redirect the user's browser instead of sending the user to the resource requested initially. To do so, you enter the portal page URL in the redirect field when you configure the action.
You may want to redirect a user upon authentication failure if you want them to see a more informative Web page than the standard HTTP-404-Page Not Found.
Instead of implementing a plug-in to prompt your users for two levels of authentication information, you may want to use two consecutive form-based authentication screens.
You can design two HTML forms, each of which has text fields for users to enter credentials. You define credential mapping for each login form. You present the user consecutively with the two HTML form-based screens. When the user clicks on the form's submit button, the form data is intercepted and processed by WebGate before it is posted to the Web server. The WebGate searches the directory for profiles with attributes matching the form credentials.
For example, Arete Airlines provides employees with personal flight benefits accrued over time. The IT department of the airline has implemented a form-based authentication system to present two consecutive HTML form-based screens to the user. Each form requests a different kind of information for user authentication, and each form has its own security level:
First screen: Prompts the user for Employment Area and Organization Number.
This form-based authentication method may have a low security level, such as 1, because many people know the information.
Second screen: Prompts for the user's Personal Information Number (PIN).
This form-based authentication method may have a high security level, such as 3, because the information is private, identifying the user exclusively.
Process overview: Form-based authentication from the user's perspective
The user clicks a link on the company human resources site for employee flight benefits.
The application presents the user with the first form-based HTML page, prompting the user for department information.
If authentication succeeds for the first screen input, the user is presented with the second form-based HTML page.
If the user's PIN is authenticated, the user is granted access to the resource.
For more information about form-based authentication, see "Form-Based Authentication" .
If you want to customize the action taken in response to an authentication result, you can create your own actions.
To implement custom actions, you create a plug-in to be called in response to the authentication result.
You can design your external code to execute any number of actions. Some examples are:
Accessing a relational database using required parameters
Passing the user name of the user who has successfully been authorized for a resource
Adding optional parameters that define a user's access
You use the Actions page of the authentication rule page to create authentication actions. Actions are optional. You can specify them for authentication failure, authentication success, or both.
You can redirect header variables only to Web servers known or protected by the Access System. Header variables are not redirected outside of Oracle Access Manager.
For example, you could enter HTTP_HELLO in the Name field and cn in the Return Attribute field. In this case, the Access System sends a value to the Web server in the HTTP header called HTTP_HELLO, including the user's common name for the cn attribute. An application could then examine this HTTP header variable. It could then display the value using application code to personalize an interface to include the user's name.
If the attribute contains multiple entries, such as phone numbers, the Access System returns them as a single string in colon-separated format. End users must parse the individual values themselves.
Enter obmygroups:ldap_url to return only specific groups a user is a member of. For example, enter obmygroups:ldap:///o=company,c=us??sub?(group_type=role) to return all of the groups in the DN that the user is a member of and that have the group_type set to role. To return all of the groups a user is a member of, enter obmygroups in the Return Attribute field.
To set authentication actions for a policy domain
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
The General page for the selected policy domain appears.
Click the Default Rules tab.
The Authentication Rule sub-tab appears with the General panel selected. This page also has an Actions panel.
Click the Actions panel.
If no actions have been created, click Add.
If actions have been created, click Modify.
The Actions page for the authentication rule appears, as illustrated in the following screen shot.
Specify the actions to be taken in response to successful authentication of the user in the Authentication Success text boxes.
For details, see the next procedure.
Specify in the Authentication Failure text boxes the actions to be taken if authentication of the user fails.
For details, see the next procedure.
Determine when you want Access Server caches to be updated.
Click Save to save your input and return to the previous page (or click Cancel to return to the previous page without saving).
To complete the authentication actions for a policy domain
In the Redirection URL fields for both Authentication Success and Authentication Failure, type the complete path to a URL where the end user's browser is sent after the request is received.
Header variables can be redirected only to Web servers known to or protected by the Access System. Header variables are not redirected outside of Oracle Access Manager.
Examples:
For authentication success, use the following URL to redirect the end user to a portal index page.
http://mycompany.com/authnsuccess.htm
For authentication failure, use the following URL to redirect the end user's request to an error page or a self-registration script.
http://mycompany.com/authnfail.htm
In the Return Type field, specify the method the Access System uses to send the value to the AccessGate. The method you specify must be recognized by your AccessGate.
An AccessGate can use these two types of methods:
headervar
cookie
If you are using a client written with the Access Server API, you can pass any alphanumeric string as the type and the client can interpret it.
For details about HTTP header variables, see "About the Use of HTTP Header Variables and Cookies" and "Actions and Header Variables" .
|
Note: If you leave the Type field blank, and then click + to add another field (or click Save), the Access System uses headervar as the default. |
In the Name field, enter a variable name that defines your return value or return attributes, such as REMOTE-USER to return the UID.
Your applications must be configured in advance to accept the variables you enter in these fields.
In the Return Value field, enter the value that must be assigned to the associated Name variable when the user is authenticated.
In the Return Attribute field, enter the LDAP attributes included in the response from the requesting user's Profile.
Click the + or – icons to add or remove fields as needed.
|
Note: If the returned value contains a special character (such as \ or :), these characters are escaped with a backslash ( \). The obUniqueid special attribute returns the DN. |
After you define the actions, return to "To complete the authentication actions for a policy domain" to complete configuration of actions for the policy domain.
For every policy, you can define actions for that policy's authentication rule to be taken in response to successful authentication of a user or failure to authenticate a user. Actions are optional. You can specify them for authentication failure and authentication success, or both.
To set authentication actions for a policy
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
From My policy Domains select the link for the policy domain where you want to set authentication actions.
The General page for the selected policy domain appears.
For the selected policy domain, select the Policies tab.
The Policies tab lists all of the existing policies.
Select the policy for which you want to define authentication rule actions.
The policy page appears, showing the General panel for the policy. There are several other panels on this page, including Authentication Rule, Authorization Expression, and Audit Rule.
Select the Authentication Rule panel.
The Authentication Rule page appears, with a General panel selected. The page also contains an Actions panel.
If you are defining the rule, see "About Creating an Authentication Rule Using Chained Authentication".
Click the Actions panel.
Click Add.
An entry form for defining the authentication rule's actions appears.
Specify in the Authentication Success and Authentication Failure text boxes the actions to be taken in response to successful authentication of the user.
For details, see "To define actions for a policy" .
Determine when you want Access Server caches to be updated.
Select Update Cache if you want all Access Server caches to be updated immediately with information about this new prefix.
If you do not select Update Cache, the Access Server caches are updated when they time out and read new information from the directory server.
Click Save.
To define actions for a policy
In the Redirection URL fields, type the complete path to a URL where the end user's browser is to be sent after the request is received.
Examples:
For authentication success, use this field to redirect the end user to a portal index page.
http://mycompany.com/authnsuccess.htm
For authentication failure, use this field to redirect the end user's request to an error page or a self-registration script.
http://mycompany.com/authnfail.htm
In the Return Type field, specify the method the Access System uses to send the value to the AccessGate. The method you specify must be recognized by your AccessGate.
An AccessGate can use these two types of methods:
headervar
cookie
If you are using a client written with the Access Server API, you can pass any alphanumeric string as the type and the client can interpret it.
After a user successfully authenticates, but before the user is served a requested resource, the Access System performs any authentication actions that were defined in the authentication rule that protects the requested resource. Authentication actions may include passing attributes to the protected application to customize the user's experience, perform redirections, and so on. In addition to performing authentication actions, a cookie known as ObSSOCookie is set for the user. The ObSSOCookie allows the user to access the resource repeatedly without re-authenticating. See "Configuring Single Sign-On" for details.
Under some circumstances, the ObSSOCookie may be set before the authentication actions have been triggered. For example, suppose the user requests a resource that is protected by a form-based authentication scheme that redirects the user to a form with several options for logging in. When the user selects a login method on the form, he or she is again redirected, this time to a form containing a certificate-based authentication scheme. In this scenario, when the user authenticates and is redirected to the requested resource, the ObSSOCookie will have already been set and any authentication actions that exist for the target resource are bypassed.
The Access System provides a key named ObTriggerAuthentication (OTA) that triggers authentication success actions for a target resource after the ObSSOCookie has been set. To make use of this trigger, you configure parameter named OTA in an authentication scheme and define corresponding authorization success actions for each domain where you want the OTA scheme to work.
To trigger the authentication actions that are defined for a target resource, you usually pass information such as a header variable. The presence of the ObSSOCookie usually indicates that authentication actions have already been performed and should be bypassed. The OTA:true parameter in an authentication scheme acts as a trigger for authentication actions. When an authentication scheme contains the OTA:true parameter, the scheme sets a value of OTA=true in the ObSSOCookie. When the user is redirected back to the requested resource, the value of OTA=true in the ObSSOCookie forces execution of the authentication actions.
To configure the OTA authentication scheme, you must also define a cookie named NoExecuteOTA in the policy domain that protects the resource. The NoExecuteOTA cookie ensures that only specific policy domains can make use of the OTA:true trigger. If you implement single- or multi-domain single sign-on, the NoExecuteOTA cookie ensures that authentication actions are only triggered for designated policy domains, even when the ObSSOCookie contains the OTA parameter. This prevents the OTA parameter from working for targets with authentication actions that are not supposed to be triggered when the ObSSOCookie is present.
The NoExecuteOTA cookie set to true along with OTA set to true in a policy domain means that the authentication actions will not be performed for the resource protected by the policy domain.
The NoExecuteOTA cookie set to false along with OTA key set to true means that the authentication actions will be performed for the resource and the OBSSOCookie will be reset.
By default NoExecuteOTA is set to false.
The following procedures describe how to configure this scheme and actions associated with the scheme.
To create an OTA authentication scheme
From the Access System Console, click Access System Configuration.
Click Authentication Management in the left navigation pane.
Click the link for an authentication scheme for which you want to add the OTA:true parameter.
The Details for Authentication Scheme page appears, with the General tab selected.
Click Modify.
In the Challenge Parameter field, add OTA:true.
If necessary, click the plus symbol ("+") to add a new field for entering this parameter.
Click Save.
To create an associated authorization action
From the landing page for the Access System, select the Policy Manager link.
If you are working in the Access System Console, click the link for the Policy Manager at the top of the page.
Click My Policy Domains in the left navigation pane.
The General page for the selected policy domain appears.
Click the link for the policy domain for which you want to add the NoExecuteOTA cookie.
Click the Authorization Rules tab for this policy domain.
Provide a name for this authorization rule and click Save.
Click the Actions tab.
Click Add.
In the Return field, add the following:
The type is cookie.
The Name is NoExecuteOTA.
The Return Value is true.
An audit rule causes event-based data to be written to the audit log file. As a Master Access Administrator, you must create a Master Audit Rule in the Access System Console. As a Delegated Access Administrator, you can derive audit rules from the Master Audit Rule for your policy domains and policies, but you cannot create an alternative Master Audit Rule.
There is one audit log for an Access Server. You can configure the size of the audit log file and the rotation interval for a server. Depending on events, the audit log may contain some duplicate audit entries.
|
Note: You may direct audit details to a database, as described in the Oracle Access Manager Identity and Common Administration Guide. |
Different information is written to the audit log depending on the outcome of events. A log entry for authentication of a user differs depending on whether the user's identity was established.
Authentication failure can occur if there is no entry in the directory for a user or if a user's credentials are invalid. For example, if there is an entry for the user in the directory, but the user entered an incorrect password (authentication failure), the value for the cn attribute is logged based on the DN in the directory. However, because the entry for the user cannot be confirmed as the correct one, attributes such as givenname are not retrieved from the directory.
You can define audit rules for a policy domain and its policies. Any audit rules you define must be derived from a Master Audit Rule. A Master Audit Rule must be created by a Master Access Administrator. Delegated Access Administrators can derive access rules from the Master Audit Rule, but they cannot create them.
Because you create audit rules for the policy domain and its policies, this chapter does not describe them. For details explaining how to create and define audit rules, see the following sections in the policy domain chapter:
Plug-Ins to Authenticate Users on External Security Systems
The Access System offers plug-ins that allow you to authenticate users whose information is stored on a Security Bridge server, on Windows NT/2000, or on a SecurID Server. These plug-ins are installed automatically when you install the Access System.
This section describes the plug-ins for Security Bridge and Windows NT/2000. For information about the SecureID plug-in, see the Oracle Access Manager Developer Guide.
The rest of this section discusses the following topics:
Security Bridge, a product of Security Integration, Inc., is an LDAP interface for OS/390-based repositories. Using the authentication plug-in for Security Bridge, authn_securitybridge, you can authenticate users whose information exists in OS/390-based repositories.
Before you can configure the Access System to use Security Bridge, you must install and configure the following:
Security Bridge LDAP Server
One of the following OS/390-based repositories:
RACF
CA-ACF2
CA-TopSecret
The Access System, including at least one Access Server and one WebGate
The authn_securitybridge.dll (for Windows) or authn_securitybridge. so (for Unix) was installed under the AccessServer_install_dir/access/oblix/lib directory.
For more information about installing the Security Bridge server and repositories, refer to the Security Bridge documentation.
To authenticate Security Bridge users, you must create an authentication scheme that specifies the Security Bridge plug-in. Table 5-12 for the complete set of Security Bridge plug-in parameters.
To create an authentication scheme with a Security Bridge plug-in
Launch the Access System and select Access System Console, from Access System Console select Access System Configuration, from Access System Configuration select Authentication Management
Click Add.
The Define an Authentication Scheme page appears.
In the Name field, type a name for this scheme, for example, Security Bridge Authentication
In the Description field, type a brief description of the scheme, for example, "This authentication scheme requires a user to enter a Security Bridge login and password."
In the Level field, type an integer representing the level of security that this authentication scheme provides, for example, Level: 3
In the Challenge Method field, select Form.
In the Challenge Parameter field you must add two parameters, form and creds.
In the SSL Required field, leave No selected.
Leave Challenge Redirect blank if there is only one WebGate/Access Server pair. Otherwise, you must redirect to a WebGate that communicates with the Security Bridge authentication Access Server.
To add the plug-ins and create the steps and flows for the authentication scheme, see "Adding a Plug-In to an Authentication Scheme" and "Adding a Step to an Authentication Scheme".
These are the plug-ins you must define for the scheme:
Plugin Name: authn_securitybridge Plugin Parameters: username="uid=%login%, ou=people, o=test.com", passcode="password", newpasscode="newpassword", ldaphostname="os39029.datadist.com", ldapport="390", machine="machineName", formdir="formDirName", securitymode="open", certfile="c:\Program Files\Netscape\Users\machineName\cert8.db"
where:
machineName is the machine on which WebGate is located.
formDirName is the directory on WebGate where the Security Bridge forms are located. The default directory is named securitybridgeforms.
Plugin Name: credential_mapping Plugin Parameter: obMappingBase="o=Company,c=US", obMappingFilter="(?(objectclass=inetOrgPerson)(uid=%login%))"
Table 5-12 summarizes available Security Bridge plug-in parameters.
Table 5-12 Security Bridge Plug-In Parameters
| Name | Default | Mandatory or Optional | Comments |
|---|---|---|---|
|
username |
uid=%login%, ou=people, o=test.com |
Mandatory |
|
|
attribute=%login%, host=myhost, o=mycompany, c=usa |
Mandatory |
For attributes other than uid—for example cn—use this parameter specification. |
|
|
password |
password |
Mandatory |
|
|
newpassword |
<none> |
Optional |
Used during password change. |
|
ldaphostname |
os39029.datadist.com |
Mandatory |
IP address of the LDAP server run by Security Bridge to be used for authentication. |
|
ldapport |
390 |
Mandatory |
Port number for the server in the previous field. |
|
machine |
<none> |
Mandatory |
Web server computer name. |
|
formdir |
<none> |
Mandatory |
Path relative to the Web server document root. |
|
securitymode |
open or SSL |
Mandatory |
|
|
certfile |
<none> |
Optional |
Location of the cert8.db file that holds all the certificates needed for SSL connections for the LDAP server run by Security Bridge. |
Now that you have created an authentication scheme that specifies a Security Bridge plug-in, you can implement the scheme in Access System deployments.
To create an authentication rule for Security Bridge
Follow the procedures in this chapter for creating an authentication rule.
Select Modify, and select the Security Bridge authentication scheme from the Challenge Method list.
After Security Bridge and an Access System authentication plug-in have been installed and configured, the authentication process is as follows.
Process overview: Authentication for Security Bridge and the Access System
WebGate intercepts a request to access a resource and determines if the resource is protected.
If the resource is protected, WebGate then determines if the user is authenticated.
If the user is not authenticated, WebGate issues a form-based challenge and the user supplies the requested login credentials.
WebGate then forwards the authentication request to an Access Server.
The Access Server processes the request through the Security Bridge authentication plug-in, and the plug-in sends an LDAP bind to the Security Bridge:LDAP Server.
The Security Bridge:LDAP Server evaluates the user's credentials stored in the OS/390 repository.
If the credentials are valid, the request is approved. If not, the request is denied.
Figure 5-4, "Authentication with a Security Bridge Plug-In" illustrates this process.
Table 5-13 describes the Windows NT and Windows 2000 plug-in used to authenticate against a Windows domain.
Table 5-13 Windows NT/2000 Plug-in
| Name | authn_windows |
|---|---|
|
Purpose |
Authenticates user name and password against a Windows NT or Windows 2000 domain. |
|
Result |
|
|
Parameters |
|
