Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service
11g Release 1 (11.1.1)

Part Number E15478-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

13 Managing Policies to Protect Resources and Enable SSO

This chapter describes how to create and manage policies, and identify the resources to be governed by these policies. This chapter focuses on using the Oracle Access Manager Console for tasks and includes the following topics:

Prerequisites

Review Chapter 11 for an introduction to the OAM policy model and single sign-on.

System level requirements for tasks in this chapter include the following:

Introduction to Application Domain Creation

This section provides the following topics:

About Automatic Application Domain Creation

When you register a policy-enforcement Agent with OAM 11g, you can choose to have policies created automatically. An application domain, and host identifier, are created automatically based on details specified for the Agent. The domain is seeded with a default resource, and with default authentication and authorization policies.

Each application domain is a collection of resources that represents a singular application on a particular host. Configurable authentication and authorization policies allow or deny access to the resources in the domain.

During Agent registration, it is presumed that the Agent is on the same Web Server as the application it protects. However, the Agent can be on a proxy Web server and the application can be on a different host.

Note:

IAMSuiteAgent is a pre-registered Java Agent filter that provides an application domain (IAMSuite) to protect Oracle Fusion Middleware console and other consoles.

For more information, see "Anatomy of an Application Domain and Policies".

About Manually Creating Application Domains

When a new application is placed behind an existing agent, the administrator must decide if it should be protected by a separate application domain and policies or an existing application domain and policies.

Administrators can define different application domains for resources even when these reside on the same Web server and are closely tied to each other in one way or another. For example, an administrator can create a single application domain for a financial application and an accounts receivable application or have a different application domain for each one.

Note:

Before adding a new resource to an application domain, consider whether the resource belongs to an existing application and its policies or if it should be defined as a new application with specific policies of its own.

The following task overview outlines the procedures that must be performed to manually create a fresh application domain.

Note:

Tasks 3 through 6 enable administrators to manage an existing application domain.

Task overview: Creating an application domain manually

  1. Review "Anatomy of an Application Domain and Policies".

  2. Start the application domain registration as described in "Creating a Fresh Application Domain Manually".

  3. Add one or more resource definitions to the domain, set as Protected, Unprotected, or Excluded, as described in "Adding and Managing Resource Definitions for Use in Policies".

  4. Configure one or more authentication policies in the domain, as described in "Defining Authentication Policies for Specific Resources".

  5. Configure one or more authorization policies to the domain, as described in "Defining Authorization Policies for Specific Resources".

  6. Define one or more SSO Responses to your policies, as described in "Adding and Managing Policy Responses for SSO".

  7. Define one or more authorization constraints as described in "Defining Authorization Policy Constraints".

  8. Define Token Issuance Policies, if needed, as described in "Managing Token Issuance Policies and Constraints with Oracle Access Manager".

  9. Configure SSO settings as described in "Managing SSO Tokens and IP Validation".

  10. Validate the domain's operation, as described in "Validating Authentication and Authorization in an Application Domain".

Anatomy of an Application Domain and Policies

OAM 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access.

Note:

OAM 10g default behavior allowed access when a resource was not protected by a rule or policy that explicitly denied access to limit the number of Webgate queries to the Access Server.

With OAM 11g, administrators control who can access resources by defining policies that discriminate between authenticated users who are authorized to access a particular resource and those who are not authorized. Each application domain can be made to contain policy elements related to an entire application deployment, a particular tier of the deployment, or a single host. Application domains do not have any hierarchical relationship to one another.

Figure 13-1 illustrates Application Domain-specific components of the Oracle Access Manager 11g Policy Model.

Figure 13-1 Application-Specific Components of the OAM Policy Model

Application Domain Components, OAM Policy Model
Description of "Figure 13-1 Application-Specific Components of the OAM Policy Model"

The application domain that is automatically created during Agent registration, is named after the Agent and is seeded with default resources and default policies (authentication and authorization), based on the Agent name. Initially, all resources are protected by the default authentication and authorization policies and there is no Token Issuance Policy defined (just an empty container). After creating the application domain, you can add more resource definitions to it and then add resources to specific policies.

Whether you register an Agent using the Oracle Access Manager Console or the remote registration tool, the elements of an application domain are the same, as described in following topics:

See Also:

"Managing Token Issuance Policies and Constraints with Oracle Access Manager" for details about the Token Issuance Policies.

Application Domain General Details

Figure 13-2 shows an application domain that is automatically created during Agent registration. The application domain name is highlighted in the navigation tree under the Application Domains node, and the Application Domain page with a name and description.

Figure 13-2 New Application Domain Generated During Agent Registration

Generated Application Domain
Description of "Figure 13-2 New Application Domain Generated During Agent Registration"

Beneath the application domain name in the navigation tree are the default resource definitions, and policies.

Administrators can modify the application domain to add more resources, and define policies, responses, and authorization constraints.

Default Resources in a Generated Application Domain

Figure 13-3 illustrates the default resources in the generated application domain, when you use the Auto Generate Policies function. The Host Identifier matches the Agent name that was specified during registration. The default Resource Type is HTTP; the default Resource URLs are /and /.../*.

Figure 13-3 Default Resource Definition in a Generated Application Domain

Generated Resource Definition
Description of "Figure 13-3 Default Resource Definition in a Generated Application Domain"

You can add resources to this policy, drawing from list of the resources that have been added to the application domain. HTTP resource definitions enable you to enter a query string. This query string can contain only the Base URL, which can include optional pattern-matching special characters to represent a set of URLs. You can also search on a query string to locate a specific resource. The Search page includes a Create button to start a new resource definition.

Default Authentication Policies in a Generated Application Domain

Each resource can be protected by only a single authentication policy. When an administrator creates an application domain manually she must also manually create all policies. However, when the application is generated automatically, during Agent registration for instance, the Protected Resource Policy is created are automatically generated:

The Protected Resource Policy is shown in Figure 13-4. The description explains "Policy set during domain creation. Add resources to this policy to protect them." This default policy uses the default authentication scheme (in this case, it is the LDAPScheme authentication scheme). Protected Resources are identified on the Resources tab as HostIdentifier/.../*. Administrators can change the authentication scheme, specify Success and Failure URLs, add other resources, and define authentication Responses.

Authentication policies are local, which means that each policy applies only to the resources specified for the policy. A policy cannot be derived or applied to any other resource.

Note:

Initially, all resources are protected. Success and Failure URLs and Responses must be added manually; no default values are supplied.

Figure 13-4 Default Authentication Policy for Protected Resources

Generated Authentication Policy
Description of "Figure 13-4 Default Authentication Policy for Protected Resources"

Authentication, Public Resource Policy: A second authentication policy is also created, which uses AnonymousScheme as its default for authentication. The description tells administrators "Policy set during domain creation. Add resources to this policy to allow anyone access." 

Note:

This Public Resource Policy does not initially protect any Resources.

Default Authorization Policies in a Generated Application Domain

Each resource can be protected by only a single authorization policy. Administrators who manually create an application domain must manually create all policies. However when the application is generated automatically, during Agent registration for instance, the following authorization policies are automatically generated:

  • Authentication Policy: Protected Resource Policy

  • Authorization Policy: Protected Resource Policy

Note:

Initially, all resources are protected and access is denied. Success and Failure URLs and Constraints and Responses must be added manually; no default values are supplied.

The Authorization, Protected Resource Policy is shown Figure 13-5. The description explains "Policy set during domain creation. Add resources to this policy to protect them." Protected Resources are identified on the Resources tab as HostIdentifier/.../*. Administrators can specify Success and Failure URLs, add other resources, and define authorization Constraints and Responses.

Figure 13-5 Default Authorization Policy for Protecting Resources

Generated Authorization Policy
Description of "Figure 13-5 Default Authorization Policy for Protecting Resources"

In the previous release, a second authorization policy (Public) was also created, which initially did not protect any resources. Beginning with patch set 1, this second policy is not set.

About Token Issuance Policies

By default, only a container for Token Issuance Policies is provided in an application domain that is generated when you register an agent.

For information on this policy type, resources, and possible constraints, see:

Managing Application Domains using the Console

This section provides the following topics:

About the Application Domains Page

Managing an application domain involves adding, modifying, copying, or deleting general and resource-related settings as well authentication and authorization policies. The copy uses a default name that is based on the original. For example, if you copy an Application Domain named AppDom3, the copy is named copy of AppDom3. All other settings in the copied domain are retained in the copy.

When creating or editing an application domain using the Oracle Access Manager Console, several pages are involved. Initially, you add general details (name and optional description) on the form show in Figure 13-6.

Figure 13-6 Fresh Application Domains General Page

Fresh Application Domains Page
Description of "Figure 13-6 Fresh Application Domains General Page"

Each application domain must have a unique name that matches the agent name. After applying the name and optional description for the new Application Domain, it is created and the name is added to the Application Domains node in the navigation tree under the Policy Configuration tab. The list includes all application domain names as a flat list of containers.

You can expand the Application Domains node to reveal all domains, including the new one. Figure 13-7 illustrates the Application Domains navigation tree and the related containers for resources policies for one domain.

Figure 13-7 Application Domains Navigation Tree

New Application Domain, General Details
Description of "Figure 13-7 Application Domains Navigation Tree"

When you select a domain name in the navigation tree, you can add, modify, or delete individual elements, as described in topics elsewhere in this chapter.

Creating a Fresh Application Domain Manually

Users with valid Administrator credentials can perform the following task to manually create an application domain using the Oracle Access Manager Console.

Note:

Application domains can be generated automatically during Agent Registration, as described in Chapter 9 and Chapter 10.

You can protect multiple applications using the same Agent by manually creating the application domain and manually adding resources and policies.

Prerequisites

Decide whether you need a fresh application domain or if you can add resources to an existing application domain.

Note:

You can duplicate an existing domain to use as a template and edit the copy to define unique identifiers (resource name and resource URLs), as described in "Viewing or Editing an Application Domain".

To create a fresh application domain

  1. From the Policy Configuration tab navigation tree, click the Application Domains node, and then click the Create command button in the tool bar.

    Alternatively: From the Welcome page, Policies panel, click New Application Domain to open a fresh page.

  2. On the fresh Application Domains page, add a unique name and an optional description for this domain, then click Apply and close the Confirmation window.

  3. Click the Refresh button in the tool bar and confirm that the new application domain appears in the navigation tree.

  4. In the navigation tree, expand the new Application Domain to view and manage the following nodes:

Searching for an Application Domain

Users with valid Administrator credentials can use the following procedure to search for a specific application domain.

To search for an application domain

  1. Activate the Policy Configuration tab.

  2. From the search type list, choose Application Domain to define your search.

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

    my_App_Domain_Name
    
  4. Click the Search button to initiate the search.

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

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

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

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

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

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

Viewing or Editing an Application Domain

Users with valid Administrator credentials can perform the following task to view or modify an application domain (including its resources, policies, constraints, and responses) using theOracle Access Manager Console.

Note:

You can duplicate an existing domain to use as a template and edit the copy to define unique identifiers (resource name and resource URLs).

Oracle recommends that you consider grouping similar applications into the same application domain. While editing the application domain, be aware that different applications are using the same domain. Editing the description and domain name are supported.

To view or modify an application domain and its content

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


    Application Domains
    Desired Domain
  2. Expand each of the following nodes to add, view, modify, or delete specific:

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

Deleting an Application Domain and Its Content

Users with valid Administrator credentials can perform the following task to delete an application domain (including its resources, policies, constraints, and responses) using the Oracle Access Manager Console.

Prerequisites

Ensure that resources in the domain to be deleted are placed in another application domain for protection.

To delete an application domain

  1. From the Policy Configuration tab, navigation tree, expand the Application Domain node.

  2. In the navigation tree, open and review the application domain name.

  3. Select the Application Domain and then click the Delete button in the tool bar.

  4. In the Confirmation window, click Delete (or click Cancel to dismiss the window).

  5. Check the navigation tree to confirm the application domain has been removed.

Adding and Managing Resource Definitions for Use in Policies

Protecting resources requires an application domain containing specific resource definitions. With OAM, you can protect different types of resources, including non-HTTP/HTTPS-based resources and HTTP/HTTPS-based resources such as:

This section provides the following topics:

About the Resource Definition Page in an Application Domain

Within an application domain, resource definitions exist as a flat collection of objects. Each resource is defined as a specific resource type, and the URL prefix that identifies a document or entity stored on a server and available for access by a large audience. The location is specified using an existing shared Host Identifier.

Each resource is defined separately in an application domain. If a resource that is not explicitly marked as excluded, is not associated with a policy, then access is denied to all users because there is no policy match.

Figure 13-8 illustrates a fresh Resources definition page.

Figure 13-8 Resources Page in an Application Domain

Resources Page in Application Domain
Description of "Figure 13-8 Resources Page in an Application Domain"

Table 13-1 describes elements that comprise a resource definition.

Table 13-1 Resource Definition Elements

Elements Description

Type

The HTTP type is the default; it covers resources that are accessed using either the HTTP or HTTPS protocol. Policies that govern a particular resource apply to all operations.

The wl_authen resource type is used for Fusion Middleware application scenarios, as described in the Oracle Fusion Middleware Application Security Guide.

See Also "Managing Resource Types".

The TokenServiceRP resource type is used to represent the Token Service Relying Party as described in "Managing TokenServiceRP Type Resources".

Description

An optional unique description for this resource.

Host Identifier

A list of host identifiers is available, which contains all identifiers that were defined as a shared component. You must choose a host identifier to assign this resource.

Note: The combination of the host identifier and URL string that make up a resource definition must be unique across all application domains.

See Also: "Managing Host Identifiers".

Resource URL

The URL value must be expressed as a single relative URL string that represents a path component of a full URL composed of a series of hierarchical levels separated by the '/' character. The URL value of a resource must begin with / and must match a resource value for the chosen host identifier.

Based on its contents, a URL is matched in response to an incoming request as a literal or a wild card pattern. The special characters available to define a pattern, if included, are:

  • The asterisk (*) is allowed only at the lowest, terminating level of the path. The asterisk matches zero or more characters.

  • An ellipses (…) is allowed at any level of the path except the terminating level. The ellipses represents a sequence of zero or more intermediate levels.

See Also Table 13-2.

Query String

The Policy Model supports query string-based HTTP resource definitions within Access Policies. The following formats are allowed:

Supported: Resource protection based on literal full query string matching. A single Query String Pattern that would be matched against the entire input Query string (as opposed to matching only portions (selected name value pairs) of the query string. For example:

status=active&adminrole=*

A Query String pattern specified as a regular free form String with these extra features:

  • Optional: Special character (*) that matches zero or more characters, which is applied to a set of names in the run time Query String.

  • Two resource definitions can exist with same URL base path pattern and different Query String patterns. These two are independent and non-equal resources. For example, these are all valid and can exist at same time:

    /foo
    /foo?bar=true
    /foo?bar=false
    

The Query String is free form with no restriction in terms of format or characters. It is not required to specify Query String as key/value pairs

At run time, onlythe Query String that is part of HTTP GET requests is processed; Query String pattern does not apply to HTTP POST data.

Resource Matching (at run time):

  • The base URL path is matched and then the Query String is matched

  • Multiple resource patterns that contain matching Query Strings: The best match is determined based on the number of tokens (pattern delimited by '*') and thegth length of the token at each position. Patterns with longer tokens in the beginning are preferred and then the pattern that contains more number of tokens. (If there are matching patterns that contain same number of tokens and same length at each position then the match would fail.)

Conflicts:

  • Super Set: The input resource definition contains a set of name-value Query String patterns that are a super set of patterns of an existing resource definition in the policy store.

  • Overlap: The input resource specification contains a set of name-value Query string patterns that overlap a set of patterns of an existing resource definition in the policy store.

Note: For OAM Agents, the remote registration tool (oamreg) accepts Query-string based HTTP resource definitions and generates the relevant policy objects for securing access of these resources. If any conflicts are encountered during policy provisioning, only policies for resources that do not have any conflicts are provisioned. This feature does not apply to 10g OSSO agent- based partners and applications. OSSO agents are not capable of enforcing authentication scheme per resource. Instead, a single authentication scheme is applied to all resources of an application.

Protection Level

Choose the appropriate protection level from the following:

  • Protected (the default)

    Protected resources are associated with a protected-level Authentication policy that uses a variety of authentication schemes (LDAP, or example).

    Authorization policies are allowed for protected resources.

    Responses, constraints, auditing, and session management are enabled for protected resources using a policy that protects the resource.

  • Unprotected

    Unprotected resources are associated with an unprotected-level Authentication policy (level 0) that can use a variety of authentication schemes (LDAP, for example).

    Authorization policies are allowed for unprotected resources, and a basic one is needed to allow such access. However, an elaborate policy with constraints and responses is irrelevant.

    Responses, constraints, and auditing are enabled for Unprotected resources using a policy that protects the resource. Only Session Management is not enabled. Access to Unprotected resources incur an OAM Server check from Webgate, which can be audited.

  • Excluded (these are public)

    Only HTTP resource types can be excluded. Typically security insensitive files like Images (*.jpg, *.png), protection level Excluded resources do not require an OAM Server check for Authentication, Authorization, Response processing, Session management, and Auditing. Excluded resources cannot be added to any user-defined policy in the console.

    The Webgate does not contact the OAM Server while allowing access to excluded resources; therefore, such access is not audited. Most regular resource validations apply to Excluded resources. However, excluded resources are not listed when you add resources to a policy.

    There is no Authentication or Authorization associated with the resource.

    Note: If a resource protection level is modified from "Protected" to "Excluded" and a policy exists for that resource, modification will fail until the resource is first disassociated with the policy.

Authentication Policy

A list of Authentication policies based on the specified resource protection level becomes available. Only policies within this domain, and that match the specified protection level, are listed.

Authorization Policy

A list of authorization policies defined in the domain become available from which you can choose.


Table 13-2 shows sample URL values for resources. For more information, see "About the Resource URL".

Table 13-2 HTTP Resources Sample URL Values

Resource Sample URL Values

Directories

  • /mydirectory

  • /mydirectory/projects

  • /mydirectory/*

Pages

  • /mydirectory/projects/index.html

  • /mydirectory/projects/*.html

  • /mydirectory/.../*.html

  • /.../*.html

Web applications

  • /mydirectory/projects/myexe.exe

  • /mydirectory/projects/*.exe

  • /mydirectory/.../*.exe

  • /.../*.exe


After adding the resource, it is grouped under the Resources node of the named application domain. When you create authentication and authorization policies all defined resources for the domain appear on a list so that you can choose one or more for inclusion in the policy.

For more information on resource definitions, see the following topics:

About the Resource Type in a Resource Definition

When adding a resource definition to an application domain, administrators must choose from a list of defined Resource Types.

When adding an HTTP type resource to an application domain, administrators choose from a list of existing host identifiers and then add the resource URL. Operations associated with the HTTP resource type need not be defined by an administrator. Instead, policies apply to all HTTP operations.

Non-HTTP resource types are named and are not associated with a URL. When adding a non-HTTP type resource definition, administrators must enter the type's name into the Resource URL field.

About the Host Identifier in a Resource Definition

Administrations identify resources in an application domain by the host where the resources reside and the resource URL.

Note:

Non-HTTP resource types are not associated with a host identifier. Instead, administrators must enter the type's name into the Resource URL field of the resource definition page.

Host identifiers create a context for each resource, which is useful when adding resources that have the same URL paths on different computers. Administrations can protect all of these resources in the same way within the same application domain. The only variable that distinguishes one set of resources from another is identification of its host computer.

All defined host identifiers appear on the Host Identifiers list on the Resources page. When adding a resource to an application domain, administrations must choose one host identifier for the computer hosting the resource.

To ensure that OAM recognizes the URL for a resource, OAM must know the various ways used to refer to that resource's host computer.

About the Resource URL

During automated application domain generation, a URL prefix is defined under which all resources are protected. Resources are linear, not hierarchical. Resource definitions are treated as complete URLs.

Note:

No host identifier is associated with a non-HTTP resource type.

Administrations identify individual resources in the application domain using a specific resource URL. Individual resource URLs need not be unique across domains. However, the combination of a resource URL, Query String, and a host identifier must be unique across domains.

An HTTP type resource is expressed as a single relative URL string representing a path. The string is composed of a series of hierarchical levels separated by the '/' character. Based on its content, a URL is matched in response to an incoming request as a literal or a wild card pattern.

URL Prefixes

The policy model does not support a resource prefix. If a policy is defined for /mydirectory/projects/, it only applies to this URL (and does not apply to /mydirectory/projects/index.html, for example). In other words, there is no policy inheritance. If you need a policy for all resources with the same prefix string, you can define the resource using special characters (three periods ... (ellipsis) or * (asterisk) for instance: /mydirectory/projects/.../*.

URL Patterns

Administrators can create granular URL patterns to specify the fine-grained portion of a resource's namespace.

Pattern matching is provided for only the following two patterns (with limited features):

… *

The three periods (called an ellipsis) matches any sequence of one or more characters that starts and ends with the forward slash character (/). It represents a sequence of zero or more intermediate levels and enables spanning multiple directories. The ellipsis (...) can be used at any level of the path except the terminating one, and only one time in any URL. The ellipsis serves to protect every resource within the applicable domain.

The * (asterisk) can be used only at the lowest, terminating level of the path. It matches zero or more characters. Every character in a URL pattern must match the corresponding character in the URL path exactly, with two exceptions:

  • At the end of a pattern, /* matches any sequence of characters from that point forward.

  • The pattern *.extension matches any file name ending with the named extension.

Note:

No other wild cards are supported. An asterisk at any other position in the pattern is not a wild card.

For example the following URL pattern:

/.../update.html

matches these resources:

/humanresources/benefits/update.html
/corporate/news/update.html
update.html

Table 13-3 illustrates a number of resource definitions within a single application domain. These are organized alphabetically according to the Host Identifier and Resource URLs.

Table 13-3 Resource URLs for.jsp

Resource URL Correct

/bank/accounts/*

Yes

/bank/accounts/*.jsp

Yes

/bank/accounts/checking

Yes

/bank/.../checking.jsp

Yes

/.../*.jsp

Yes

/bank/accounts/checking*.jsp

No

/bank/accounts/c*.jsp

No

/bank/.../accounts/def.gif

No


About Run Time Resource Evaluation

While processing requests for resources, an evaluation is made to ensure that the proper policy is invoked for the resource.

Process overview: Resource evaluation

  1. A user specifies the URL for a requested resource.

  2. Based on the host identifier and URL, OAM creates a fully qualified URL that includes the URL pattern.

  3. OAM compares the incoming URL for the requested resource to the fully qualified URL constructed from the application domain information and the policy's URL pattern:

    • If there is a match, the various policies are evaluated to determine whether the requester should be allowed or denied access to the resource.

    • If requester is allowed access, the resource is served to the user.

Table 13-4 describes the possible outcomes.

Table 13-4 Resource Evaluation Outcomes

Outcome Description

Best Match

The best match is when a resource definition has the least resource scope compared to other possible matches to the run time resource. The term resource scope represents all possible resources that could be matched using a particular resource definition

No Match1

If no match is found, the default evaluation outcome is FAILURE. Depending on what kind of policy was being evaluated, this could mean no authentication is attempted, or no resource access is granted.


Look Up Mechanism Examples

  • The default resource URL in a generated application domain defines the broadest scope of content possible (all directories and below):

    /.../*

  • The pattern /.../index.html matches:

    /index.html
    /oracle/index.html
    /oracle/sales/index.html
    index.html
    

    It does not match, for example, xyzindex.html.

  • /oracle/.../*.html matches:

    /oracle/index.html
    /oracle/sales/order.html
    and so on
    

Resource Scope Examples

  • Resource scope of the following resource definition (includes the asterisk):

    /mybank/…/*

    includes all URLs prefixed with "/mybank/"

  • Resource scope of the following resource definition (no special characters in the definition):

    /mybank/account.html

    includes only one URL: "/mybank/account.html"

Adding Resource Definitions to an Application Domain

Users with valid Administrator credentials can use the following procedure to add the resource definitions to protect to the corresponding application domain.

Note:

Failure can occur if you specify a host identifier value that is invalid. An error informs you that the challenge URL is invalid.

Prerequisites

The resource type must be defined as a Shared Component. For details, see "Managing Resource Types".

To add resource definitions to an application domain

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


    Application Domains
    Desired Domain
  2. Within the application domain, open the Resources node.

  3. Click the New Resource button in the upper-right corner of the Search page.

  4. On the Resource Definition page:

    1. Select or enter your details for a single resource (Table 13-1):


      Type
      Description (optional)
      Host Identifier
      Resource URL
      Query String
      Protection Level
      Authentication Policy (if level is Protected)
      Authorization Policy (if level is Protected and Athentication Policy is chosen)
    2. Click Apply to add this resource to the application domain.

    3. Repeat this procedure to add other resources to this application domain.

  5. Proceed to adding a resource to specific policies as described in:

Searching for a Resource Definition

This section provides the following topics:

About Searching for a Specific Resource Definition

Figure 13-9 shows the default Search elements and Search Results table for resource definitions in an application domain.

Figure 13-9 Searching for Resource Definitions within an Application Domain

Searching for Resource Definitions
Description of "Figure 13-9 Searching for Resource Definitions within an Application Domain"

You can simply click the Search button using the defaults or refine your search by supplying as much or as little of the information in Table 13-0 as needed to find the resource.

Table 13-5 Search Elements for a Resource in an Application Domain


Search Elements Description
 

Resource Type

Provides a list of defined resource types from which you can choose. You can also leave this blank.

Default: HTTP

 

Host Identifier

Enter a host identifier here, if desired. You can leave this blank

Default: blank

 

Resource URL

Enter a resource URL, if desired. You can leave this blank

Default: blank

 

Query String

Enter a query string for the resource, or leave this blank. You can include this in the search criteria if a query string was defined for the resource when it was added to the application domain.

Default: blank

 

Authentication Policy

Provides a list of defined authentication policies for this application domain. You can choose one or leave the space blank.

Default: blank

 

Authorization Policy

Provides a list of defined authorization policies for this application domain. You can choose one or leave the space blank.

Default: blank


You can click Reset to clear the form or Search to initiate the search. The results table is shown in Example 13-0. Each resource listed includes everything specified when it was added to the domain. The Actions and View menus are available for use with the table. Also you can click the Create command button to add a new resource definition to this domain.

Figure 13-10 Search Results Table for Resource Definitions in an Application Domain

Search Results for Resource Definitions
Description of "Figure 13-10 Search Results Table for Resource Definitions in an Application Domain"

Searching for a Specific Resource Definition

Users with valid Administrator credentials can use the following procedure to search for a specific resource definition.

To find a resource definition

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


    Application Domains
    Desired Domain
  2. Open the Resources node to display related Search criteria and the Search Results table.

  3. Fill in the search criteria as needed (Table 13-0), and click the Search button.

  4. In the Search Results table, click the desired resource definition:

    • Actions: Select an Actions menu item to Create a new resource in the domain or to Edit or Delete the selected resource in the table.

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

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

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

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

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

Viewing or Editing a Resource Definition in an Application Domain

Users with valid Administrator credentials can use the following procedure to modify resource definitions within a specific application domain.

Note:

If a resource protection level is modified from "Protected" to "Excluded" while it is associated with a policy, the modification will fail. First, remove the resource from the policy, make the change, and add the resource to the policy.

Prerequisites

You must have the desired resource type defined as a shared component. For details, see "Managing Resource Types".

To view or modify resource definitions in an application domain

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


    Application Domains node
    Desired Domain
  2. Find the Resource, as described in "Searching for a Resource Definition".

    • View Only: Close the page when you finish.

    • Modify: Alter the definition as desired and then click Apply to submit changes (or close the page without applying changes).

Deleting a Resource Definition from an Application Domain

Users with valid Administrator credentials can use the following procedure to delete a resource from an application domain.

Prerequisites

Ensure that the resource definition you will delete is not used in any policy.

To delete resource definitions from an application domain

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


    Application Domains
    Desired Domain
  2. Find the Resource, as described in "Searching for a Resource Definition"

  3. Optional: Double-click the desired resource definition and confirm this is the one to be deleted, then close the page.

  4. Click the name of the desired resource definition and then click the Delete button in the tool bar.

  5. In the Confirmation window, click Delete (or click Cancel to dismiss the window).

  6. Repeat this procedure as often as needed to delete other resources in an application domain.

Defining Authentication Policies for Specific Resources

Each resource assigned to an application domain can be protected by only one authentication policy. After adding a resource definition to the application domain, the administrator can begin refining a default authentication policy, adding a new policy, and assigning resources to the authentication policy.

In an automatically generated application domain, the following authentication policies are seeded as defaults to help streamline the administrator's tasks:

This section provides the following topics:

About the Authentication Policy Page

Administrators use authentication policies to protect specific resources. The authentication policy provides the sole authentication method for resources governed by the policy.

Each authentication policy defines the type of verification that must be performed to provide a sufficient level of trust for Oracle Access Manager to grant access to the user making the request.

Authentication policies are local. A single policy can be defined to protect one or more resources in the application domain. However, each resource can be protected by only one authentication policy.

Figure 13-11 shows the Authentication Policy page within an application domain. The resources assigned to this policy are displayed on the Resources tab of the policy. This example is from the IAM Suite application domain.

Figure 13-11 Authentication Policy: IAM Suite Application Domain

Authentication Policy and Resources Page
Description of "Figure 13-11 Authentication Policy: IAM Suite Application Domain"

Table 13-6 describes authentication policy elements. The IAM Suite application domain is shown simply as an example.

Table 13-6 Authentication Policy Elements and Descriptions

Element Description

Name

A unique name used as an identifier in the navigation tree.

Description

Optional unique text that describes this authentication policy.

Authentication Scheme

A single, previously-defined authentication scheme to be used by this policy for user authentication. See Also: "Managing Authentication Schemes" for details.

Success URL

The redirect URL to be used upon successful authentication.

Failure URL

The redirect URL to be used if authentication fails.

Identity Assertion

Required in the ID propagation use case scenario for any issued token from Oracle Access Manager that represents an end user (and possibly its OAM session).

The Identity Assertion Token is generated and returned as a response (as an HTTP HEADER with a name of "OAM_IDENTITY_ASSERTION" and a value as a SAML token) after a successful authentication.

For Oracle Security Token Service clients that are Web applications protected by OAM 11g requesting tokens to gain proxy access to a Relying Party (ID Propagation use case), Oracle Security Token Service requires clients to pass an OAM Identity Assertion token that represents the end user.

The ID Provider (Oracle Access Manager) processes the request and returns an Authentication Token and an ID Assertion Token. An ID Assertion Token, in itself, does not represent a user session and cannot be used independently to request direct access to a resource or service.

The ID Assertion Token Requestor uses this Token later, during the end user session, as part of a backend service processing request (on behalf of the end user).

The ID Assertion Token Consumer (Oracle Security Token Service), as part of the request processing, first validates the ID Assertion Token and then (on validation success) processes the request in the context of the end user Identity.

See Also: "Scenario: Identity Propagation with the OAM Token".

Resources

The URL of a resource chosen from those listed. The listed URLs were added to this application domain earlier. You can add one or more resources to protect with this authentication policy. The resource definition must exist within the application domain before you can include it in a policy.

See Also: "About Resources in an Authentication Policy".

Responses

The obligations (post authentication actions) to be carried out by the Web agent. After a successful authentication, the application server hosting the protected application should be able to assert the User Identity based on these responses.After a failed authentication, the browser redirects the request to a pre-configured URL

See Also: "Introduction to Policy Responses for SSO".


About Resources in an Authentication Policy

You can choose to add one or more resources to be protected by the authentication policy. The Resources tab on the Authentication Policy page provides a table where you can enter resource URLs. A list is also provided from which you can choose from defined resources within the application domain.

To add a resource, click the + button and select from the list. To delete a resource, select the name from the Resources table and click the Delete button in the table.

Adding an Authentication Policy and Resources

Users with valid Administrator credentials can use the following procedure to add an authentication policy and resources to an application domain. You can use a pre-configured authentication scheme or a custom authentication scheme in the authentication policy.

Prerequisites

Any resource to be added to a policy must be defined within the same Application Domain as the policy.

To add an authentication policy for specific resources

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


    Application Domains
    Desired Domain
  2. In the navigation tree, click Authentication Policies, then click the Create button to open a fresh page.

  3. Add General Policy Details:

    • Name

    • Authentication Scheme

  4. Add Global Policy Elements and Specifications (Table 13-6):

    • Description (optional)

    • Success URL

    • Failure URL

    • Identity Assertion

  5. Add Resources:

    • Click the Resources tab on the Authentication Policy page.

    • Click the Add button on the tab.

    • Choose a URL from the list.

    • Repeat these steps as needed to add more resources.

  6. Click Apply to save changes and close the Confirmation window.

  7. Add policy Responses, as described in "Adding and Managing Policy Responses for SSO".

  8. Close the page when you finish.

Searching for an Authentication Policy

Users with valid Administrator credentials can use the following procedure to search for a specific authentication policy.

To search for an authentication policy in an application domain

  1. Activate the Policy Configuration tab.

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

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

    my_AuthNPolicy
    
  4. Click the Search button to initiate the search.

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

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

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

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

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

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

Viewing or Editing an Authentication Policy

Users with valid Administrator credentials can use the following procedure to modify an authentication policy in an application domain. This includes changing the authentication scheme, adding or removing resources or responses, and altering the Success or Failure URLs.

To view or modify an authentication policy

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


    Application Domains
    Desired Domain
    Authentication Policies
  2. Double-click the desired authentication policy name.

    The Authentication Policy is opened and its Resource tab is available.

  3. General Policy Elements:

    • Name

    • Authentication Scheme

  4. Global Policy Elements: Edit as desired, (Table 13-6):

    • Description

    • Success URL

    • Failure URL

    • Identity Assertion for Oracle Security Token Service

  5. Resource: Click the Resources tab and perform the following tasks as needed:

    • Add: Click the Add button on the Resources table, click a URL in the list, click Apply.

    • Delete: Click a URL in the Resources table, click the Delete button on the table.

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

  7. Responses: View or edit responses as described in "Adding and Managing Policy Responses for SSO".

  8. Close the page when you finish.

Deleting an Authentication Policy

Users with valid Administrator credentials can use the following procedure to delete an authentication policy from an application domain.

When you remove the policy, all resource definitions remain within the application domain. However, the policy and all responses are eliminated.

The following procedure describes how to delete the entire policy. To simply alter an element in the policy, see "Viewing or Editing an Authentication Policy".

To delete an authentication policy

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


    Application Domains
    Desired Domain
    Authentication Policies
  2. Optional: Double-click the desired policy name to review its content, and then close the page.

  3. Delete all responses, as described in "Adding and Managing Policy Responses for SSO".

  4. In the navigation tree, click the name of the authentication policy, then click the Delete button in the tool bar.

  5. In the Confirmation window, click Delete to confirm (or click Cancel to dismiss the window).

  6. Ensure that resources governed by this policy are added to a different policy.

Defining Authorization Policies for Specific Resources

Each resource assigned to an application domain can be protected by only one authorization policy.

In an automatically generated application domain, the following authorization policies are seeded as defaults:

After adding resource definitions to the application domain, administrators can begin refining a default authorization policy, adding a new policy, and adding resources to authorization policies. This section provides the following topics:

About Authorization Policies for Specific Resources

Administrators can create an authorization policy to protect access to one or more resources based on attributes of an authenticated user or the environment. The authorization policy provides the sole authorization protection for resources included in the policy.

Authorization policies are local, which means that each policy applies only to the resources specified for the policy. A policy cannot be derived or applied to any other resource.

A single policy can be defined to protect one or more resources in the application domain. However, each resource can be protected by only one authorization policy.

Figure 13-12 shows the Authorization Policy page within an application domain. The resources assigned to this policy are displayed on the Resources tab of the policy. The IAM Suite Application Domain is shown simply as an example.

Figure 13-12 Authorization Policy Page: IAM Suite Application Domain

Authorization Policy and Resources Pages
Description of "Figure 13-12 Authorization Policy Page: IAM Suite Application Domain"

Table 13-7 describes authorization policy elements. The elements are the same regardless of the domain; only the details will differ. The IAM Suite Application Domain application domain is shown simply as an example.

Table 13-7 Authorization Policy Elements and Descriptions

Element Description

Name

A unique name used as an identifier in the navigation tree.

Description

Optional unique text that describes this authorization policy.

Success URL

The redirect URL to be used upon successful authorization.

Failure URL

The redirect URL to be used if authorization fails.

Use Implied Constraints

Allows (or denies) access. Set on the authorization policy to allow access in the absence of any authorization constraints of a particular class.

Default: Checked (enabled)

See Also "Introduction to Authorization Constraints".

Identity Assertion

Required in the ID propagation use case scenario for any issued token from OAM that represents an end user (and possibly its OAM session).

For OSTS clients that are Web applications protected by OAM 11g requesting tokens to gain proxy access to a Relying Party (ID Propagation use case), OSTS requires clients to pass an OAM Identity Assertion token that represents the end user.

The ID Provider (Oracle Access Manager) processes the request and returns an Authentication Token and an ID Assertion Token. An ID Assertion Token, in itself, does not represent a user session and cannot be used independently to request direct access to a resource or service.

The ID Assertion Token Requestor uses this Token later, during the end user session, as part of a backend service processing request (on behalf of the end user).

The ID Assertion Token Consumer (Oracle Security Token Service), as part of the request processing, first validates the ID Assertion Token and then (on validation success) processes the request in the context of the end user Identity.

See Also: "Scenario: Identity Propagation with the OAM Token".

Resources Tab

One or more previously-defined resource URLs to be protected by this authorization policy.

Constraints Tab

See Also "Introduction to Authorization Constraints".

Responses Tab

See Also "Introduction to Policy Responses for SSO".


Adding an Authorization Policy and Specific Resources

Users with valid Administrator credentials can use the following procedure to add an authorization policy to an application domain.

Prerequisites

Any resource to be added to a policy must be defined within the same Application Domain as the policy.

To add an authorization policy and resources

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


    Application Domains
    Desired Domain
  2. In the navigation tree, click Authorization Policies and then the Create button.

  3. Enter a unique name for this authorization policy.

  4. Global Policy Elements: Enter your own details (Table 13-7):

    • Description (optional)

    • Success URL

    • Failure URL

    • Use Implied Constraints

    • Identity Assertion for Oracle Security Token Service

  5. Resources:

    • On the Resource tab, click the Add button.

    • From the list provided, click a resource URL.

    • Repeat these steps to add more resources to this policy.

  6. Click Apply to save changes and close the Confirmation window.

  7. Constraints: Add authorization constraints, as described in "Defining Authorization Policy Constraints".

  8. Responses: Add or edit responses for SSO, as described in "Adding and Managing Policy Responses for SSO".

  9. Close the page when you finish.

Searching for an Authorization Policy

Users with valid Administrator credentials can use the following procedure to locate a specific authorization policy.

To search for an authorization policy

  1. Activate the Policy Configuration tab.

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

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

    my_AuthZPolicy
    
  4. Click the Search button to initiate the search.

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

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

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

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

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

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

Viewing or Editing an Authorization Policy and Resources

Users with valid Administrator credentials can use the following procedure to view or modify an authorization policy within an application domain.

To view or edit an authorization policy

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


    Application Domains
    Desired Domain
    Authorization Policies
  2. Double-click the desired policy name to display details.

  3. Global Elements: Edit as needed (Table 13-7):

    • Description (optional)

    • Success URL

    • Failure URL

    • Use Implied Constraints

    • Identity Assertion for Oracle Security Token Service

  4. Resource: Click the Resources tab and perform the following tasks as needed:

    • Add: Click the Add button on the Resources table, click a URL in the list, click Apply.

    • Delete: Click a URL in the Resources table, click the Delete button on the table.

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

  6. Constraints: View or edit these as described in "Viewing, Editing, or Deleting Authorization Policy Constraints".

  7. Responses: View or edit these as described in "Viewing, Editing, or Deleting a Policy Response for SSO".

  8. Close the page when you finish.

Deleting an Authorization Policy

Users with valid Administrator credentials can use the following procedure to delete an authorization policy or simply delete resources within the policy.

When you remove the entire policy, all resource definitions remain within the application domain. However, the authorization policy and the constraints and responses governing access are eliminated.

Note:

To simply alter an element in the policy see "Viewing or Editing an Authentication Policy".

Prerequisites

Assign resources governed by this policy to another authorization policy, either before or after deleting the policy.

To delete an authorization policy

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


    Application Domains
    Desired Domain
    Authorization Policies
  2. Optional: Double-click the policy name to review its content, and then close the page when finished.

  3. Click the policy name, and then click the Delete button in the tool bar.

  4. In the Confirmation window, click Delete (or click Cancel to dismiss the window).

  5. Confirm that the policy is no longer listed in the navigation tree.

Introduction to Policy Responses for SSO

Each policy can optionally contain one or more authentication or authorization responses, or both. Responses are post-processing actions (obligations) to be carried out by the web agent.

Note:

There are no responses in Token Issuance Policies.

This section provides the following information:

About Authentication and Authorization Policy Responses for SSO

Administrators can define responses that declare the actions that must be fulfilled after successful authentication or authorization. Authentication and authorization data is returned to the client (typically a Web Agent).

Policy responses enable the insertion of information into a session or application and the ability to withdraw the information at a later time to enable SSO. For instance, identity mappings can be inserted into the customer's application or actions can be carried out by the Agent or the application.

Depending on the responses specified for authentication or authorization success and failure, the user might be redirected to a specific URL, or user information might be passed on to other applications through a header variable or a cookie value.

Note:

OAM 10g provided data passage to (and between) applications only by redirecting to URLs in a specific sequence.

There are no default response provided. Figure 13-13 illustrates an Authorization Policy Response defined by an administrator in the Oracle Access Manager Console. Authorization responses can operate in conjunction with authorization constraints.

Figure 13-13 Authorization Policy Response in the Console

Authorization Policy Response
Description of "Figure 13-13 Authorization Policy Response in the Console"

Each response consists of two inputs (a type and an expression) and a single output (the value of the evaluated expression). The expression declares how the value should be constructed when the expression is processed. The response type defines the form of action to be taken with the value string.

  • The authentication policy determines the identity of the user. Each authentication policy requires an authentication scheme and responses (expressions).

  • The authorization policy determines whether the user has the right to access the resource. Each authorization policy requires authorization constraints and responses (expressions).

Administrators set Responses in the Oracle Access Manager Console, as described Table 13-8.

Table 13-8 Response Elements

Element Description

Name

A unique name to distinguish this response from other responses that use the same mechanism (type).

Type

The mechanism used to convey the response. form of the action to be taken with the value string:

  • HEADER (Header variables): Sets an HTTP request header for downstream applications using the defined value to dictate the action to be taken (such as the assertion of a User ID using a pre-defined HTTP header name).

  • SESSION: Sets an attribute inside the user session by the client (to enable single sign-on) based on the defined session variable name and value.

  • COOKIE: Sets a variable name and value (typically set by Web agents) inside the authentication session cookie to enable single sign-on.

    In cookie-less mode, Web-cache is currently used to store cookies from Webgate. However, in cookie-less mode, the end application does not have access to cookies and cannot use them.

Value

The response expression, set as a variable.

For more information, see "About the Policy Response Language".


About the Policy Response Language

OAM 11g authentication and authorization responses are defined using a very small, domain-specific language (DSL) with two main constructs:

  • Literal strings: For example: This is a valid expression

  • Variable references:

    • Declared using a dollar sign prefix $

    • Scoped to a namespace: $namespace.var_name

      Note:

      Certain variables include an attribute: $ns.name.attribute

About the Namespace and Variable Names for Policy Responses

With the namespace mechanism, the following variable types are to enable single sign-on:

  • Request: Information on the requested resource, the client making the request, and the policy matched during evaluation

  • Session: User session details

  • User: User details (user ID, group, and attribute information)

For details of each, see:

Table 13-9 Namespace Request Variables for Single Sign-On

Namespace Description

agent_id

Name of the requesting agent

client_ip

IP address of the user browser

policy_appdomain

Name of the application domain holding the policy matched for the request

policy_res

Resource host ID and URL pattern matched for the request

res_policy

Name of the specific policy matched for the request

res_host

Requested resource's hostname

res_port

Requested resource's port number

res_type

Requested resource's type

res_url

Requested resource URL


Table 13-10 Namespace Session Variables for Single Sign-On

Namespace Description

attr

Reference to an arbitrary session attribute, the name of which is passed to us as a variable attribute. Its value has been bound to the session by executing a session response during a previous request

authn_level

Current authentication level for the session

authn_scheme

Name of the authentication scheme executed to achieve the current authentication level

count

Session count for the user bound to this session

creation

Session creation time

expiration

Session expiration time


Table 13-11 Namespace User Variables

Namespace Description

attr

Reference to an arbitrary LDAP attribute, the name of which is passed to us as a variable attribute

groups

Comma-separated list of the user's group membership

userid

The user ID

user.id_domain

The user's identity domain (essentially the same as the identity store)

guid

A unique identifier that locates the user entry in an Identity Store


About Constructing a Policy Response for SSO

This section is divided as follows:

Simple Responses

After deciding on the response type and determining which namespace and variable, you simply enter the response attributes in the Oracle Access Manager Console. A simple response might look like one of the several authorization responses shown in Figure 13-14.

Figure 13-14 Simple Response Samples

Response Samples
Description of "Figure 13-14 Simple Response Samples"

Simple responses stand alone. Each is preceded with the dollar sign ($), followed by the namespace, which is separated from the variable Value by a dot (.). For example:

$namespace1.var1

Table 13-12 illustrates several simple responses and a description of what each one returns.

Table 13-12 Simple Responses and Descriptions

Name Type Value (Simple $Namespace.Variable) Returned Environment Variables and Values

oam_literal

Header

This is a response string.

HTTP_OAM_LITERAL This is a response string

oam_sessioncount

Header

$session.count

HTTP_OAM_SESSIONCOUNT integer

oam_userid

Header

$user.userid

HTTP_OAM_USERID name

oam_ipaddress

Header

$request.client_ip

HTTP_OAM_IPADDRESS nnn.nn.nn.nnn


Compound and Complex Responses

When crafting a compound or complex policy response, administrators can combine literals and variables arbitrarily using braces { } to construct an expression. A colon (:) is used as a separator. For example:

${namespace1.var1}:${namespace2.var2}

Literal String (LS): ${namespace1.var1}:${namespace2.var2}

LS: ${namespace1.var1}, LS:${namespace2.var2}

Figure 13-15 illustrates several complex responses defined by an administrator. All are Header type responses, which set values in a header variable of an HTTP request for consumption by a downstream application.

Figure 13-15 Sample Complex Responses

Complex Response Samples
Description of "Figure 13-15 Sample Complex Responses"

Table 13-13 describes the complex responses shown in Figure 13-15.

Table 13-13 Complex Responses

Name Value Returned Environment Variables and Values

oam_resinfo

Runtime resource: ${request.res_host}:${request.res_port}${request.res_url}

HTTP_OAM_RESINFO

Runtime resource: myhost.domain.com:1234/cgi-bin/myres3

oam_clientinfo

Runtime client: Agent ID: ${request.agent_id}, Browser IP: $request.client_ip

HTTP_OAM_CLIENTINFO

Runtime client: Agent ID: RREG_OAM, Browser IP: 123.45.67.891

oam_userinfo

${user.userid}'s groups: ${user.groups}, description: ${user.attr.description}

HTTP_OAM_USERINFO

WebLogic's groups: Administrators, description: This user is the default administrator

oam_sessioninfo

Session creation/expiration/count: ${session.creation}/${session.expiration}/${session.count}

HTTP_OAM_SESSIONINFO

Session creation/expiration/count: Tue Feb 23 17:47:42 PST 2011/Wed Feb 24 01:47:42 PST 2011/7

oam_app_user

$user.userid

HTTP_OAM_USERID name


For more information, see "About Policy Response Processing".

About Policy Response Processing

Policy response processing occurs during the authorization request for which the authentication responses are replayed. Variable references are filled with appropriate values to ensure that all variables have a value set, and can be set consistently with authorization values.

Processing a response expression is done through a series of steps:

  • Scanner/tokenizer

  • Parser

  • Interpreter

    During interpretation, variable references are resolved to values. The result after processing is a simple String value, which is propagated to the Agent or saved within the session for future use.

Authentication success responses are saved and then “replayed” along with any authorization responses on the first applicable authorization request.

Authorization response expressions create the actions to be taken, depending on the evaluation of the expression: success, failure, or inconclusive.

Note:

OAM 10g exhibits the same behavior in the “authenticating Webgate” configuration. This is also employed by OAM 11g with 10g Webgates: The 10g Webgate always redirects to the OAM 11g credential collector which acts like the authenticating Webgate

When referencing a variable, either the value is returned, or the following is returned:

  • NOT FOUND is returned if the variable is not set

  • NULL is returned if the variable is set to a null value

Note:

Verify the Responses as follows:
  • Header:

  • Session:

  • Cookie: Use a browser plug-in tool or turn on the browser "show cookies" settings.

Pass Through Without Processing

A value that must be passed through without processing, can be identified using a \. For example:

\$1000

results in the value $1000 appearing in the returned value.

Adding and Managing Policy Responses for SSO

Policies and responses enable single sign-on and can override other directives. Before starting activities in this section, be sure to review the "Introduction to Policy Responses for SSO".

Unless explicitly stated, information in this section applies equally to authentication and authorization responses.

Adding a Policy Response for SSO

Users with valid Administrator credentials can use the following procedure to add a policy response for authentication or authorization.

Prerequisites

Analyze authorization constraints before crafting authorization responses to ensure the appropriate actions are taken by the response. You need an application domain with an existing authentication or authorization policy.

To add a policy response

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


    Application Domains
    Desired Domain
    Authorization Policies (or Authentication Policies)
  2. Double-click the desired policy name to open the page.

  3. Click to activate the Responses tab, then click its Add button and:

    • In the Name field, enter a unique name for this response.

    • From the Type list, choose a response type (Session or Header or Cookie).

    • In the Value field, enter a value for this response. For example: $namespace1.var1

    • Repeat as needed.

  4. Click Apply, then close the Confirmation window.

  5. Close the page when you finish.

  6. Verify the Responses based on your definitions for:

    • Header

    • Session:

    • Cookie: Use a browser plug-in tool or turn on the browser "show cookies" settings.

Viewing, Editing, or Deleting a Policy Response for SSO

Users with valid Administrator credentials can use the following procedure to view or edit a policy response for authentication or authorization.

Prerequisites

You must have an application domain with an existing authentication or authorization policy.

To view, modify, or delete a policy response

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


    Application Domains
    Desired Domain
    Authorization Policies (or Authentication Policies)
  2. Double-click the desired policy name to open the page.

  3. Responses: Click the Responses tab and proceed as needed:

    • Add a response as described in "Adding a Policy Response for SSO"

    • Edit: Click the desired response Name, Type, or Value, edit as needed, and click Apply.

    • Delete: Click the desired response, then click the Delete button for the Response table.

  4. Responses: Edit a response as follows.

    1. Click the Responses tab.

    2. Click the desired response Name, Type, or Value.

    3. Make the desired change.

    4. Repeat as needed and click Apply when finished.

  5. Click Apply, then close the Confirmation window.

  6. Close the page when you finish.

  7. Verify Responses based on your definitions for:

    • Header

    • Session

    • Cookie: Use a browser plug-in tool or turn on the browser "show cookies" settings.

Introduction to Authorization Constraints

Authorization constraints must be specified by an administrator to apply to all resources within a specific authorization policy in an application domain.

An authorization constraint is a rule that grants or denies access to a particular resource based on the context of the request for that resource. Authorization Constraints define the obligations (requirements) that must be fulfilled before responding to a client's request.

Evaluation of constraints determines if the authorization policy applies to the incoming request. The appropriate obligations take affect after successful authentication and work in concert with defined authorization responses. For each incoming request, the authorization policy determines if there are any constraints. During authorization, constraints are evaluated.

Allow versus Deny Type Constraints

Each authorization policy can contain one or more authorization constraints that determine whether access to the requested resource should be granted or denied.

Authorization constraints contain:

Note:

When defining constraints within a particular policy, only a single outcome (allow or deny) is allowed.

Constraint Classes

Using different constraint classes, you can configure different constraints within the same authorization policy. For instance, you can configure constraints to:

This section provides the following topics:

About Allow or Deny Type Constraints

Each authorization constraint enables you to include either a Allow or Deny type outcome. The Use Implied Constraints option can be set on the authorization policy to allow access in the absence of any authorization constraints.

If Allow Access conditions do not apply to a user, the user is not qualified by the policy and, by default, the user is denied access to the requested resource.

Note:

Access is denied when no constraints are defined and when Use Implied Constraints is not enabled.

About Classifying Users and Groups for Constraints

Oracle recommends that you consider the same information for the policies and constraints when analyzing users and groups to determine who is explicitly allowed or denied access. For example, one authorization policy might be constrained to a particular time of day (temporal class) while another might be constrained to a specific group of users (Identity class).

Note:

Do not be concerned about users who are denied access under any conditions. They are denied access by default if none of the constraints qualify them.

When classifying users Oracle recommends that you divide the users, and groups of users, into groups for whom different conditions apply. For example, constraints can determine when the users can access the resources, the computers from which they must make their requests, and so on.

If some users fall into multiple categories, for example, a user in the marketing group belongs to a certain project group, or a user in the human resources group also belongs to the project group, put the user in both categories. You can require that the user meet the conditions of two constraints.

Guidelines for Authorization Responses Based on Constraints

For each constraint class, consider the response actions that you want to occur for authorized users. For example, you may want the system to return user profile information and pass that information to a downstream application, as follows:

  • If the user is authorized, you may want to pass the user's common name (cn) to another application so that the application can present a customized greeting to the user.

  • If the user is not authorized, you may also want to return information about the user for security purposes.

About Constraints and General Authorization Policy Details

All constraint definitions apply along with the general authorization policy details shown in Figure 13-16.

Figure 13-16 Authorization Policy Page, General Details

Authorization Policy Page
Description of "Figure 13-16 Authorization Policy Page, General Details"

Table 13-14 describes the common authorization policy general details.

Table 13-14 Authorization Policy General Details

Element Description

Name

A unique name used as an identifier in the navigation tree.

Description

Optional unique text that describes this authorization policy.

Success URL

The redirect URL to be used upon successful authorization.

Failure URL

The redirect URL to be used if authorization fails.

Use Implied Constraints

Allows (or denies) access. Set on the authorization policy to allow access in the absence of any authorization constraints of a particular class.

Default: Checked (enabled)

Identity Assertion

Required in the ID propagation use case scenario for any issued token from OAM that represents an end user (and possibly its OAM session).

For OSTS clients that are Web applications protected by OAM 11g requesting tokens to gain proxy access to a Relying Party (ID Propagation use case), OSTS requires clients to pass an OAM Identity Assertion token that represents the end user.

The ID Provider (Oracle Access Manager) processes the request and returns an Authentication Token and an ID Assertion Token. An ID Assertion Token, in itself, does not represent a user session and cannot be used independently to request direct access to a resource or service.

The ID Assertion Token Requestor uses this Token later, during the end user session, as part of a backend service processing request (on behalf of the end user).

The ID Assertion Token Consumer (Oracle Security Token Service), as part of the request processing, first validates the ID Assertion Token and then (on validation success) processes the request in the context of the end user Identity.

See Also: "Scenario: Identity Propagation with the OAM Token".


About the Add Constraint Window

When an administrator adds a constraint to an authorization policy, the window shown in Figure 13-17 appears to capture the name, class, and outcome type of the constraint. When submitted, this information is used to create a container for the constraint details that must be specified by the administrator.

Figure 13-17 Add Constraint Window

Add Constraint Window
Description of "Figure 13-17 Add Constraint Window"

Table 13-15 describes the Add Constraint window elements.

Table 13-15 Add Constraint Window Elements

Element Description

Name

A unique name for this constraint.

Class

Only one class can be specified (Identity, IP4 Range, or Temporal).

Type

Outcome type: Allow or Deny access.

Add Selected

Click this button to initiate creation of the constraint container.


After specifying the general details, the constraint container is added and displayed on the policy page as shown in Figure 13-18. Here, only the Name, Class, and Type are displayed. However, a window control (red circle in the figure) allows administrators to open a window where they can specify details for the selected constraint.

Figure 13-18 Constraint Containers on the Authorization Policy Page

Constraint Containers
Description of "Figure 13-18 Constraint Containers on the Authorization Policy Page"

Constraint details are specific to the chosen constraint class, as described in following topics:

About Identity Class Constraints

With the Identity constraint class, administrators must add a user population to the constraint. After opening the constraint container, any defined user population is displayed. Like the other constraints, this one can be used in conjunction with identity and temporal constraints.

When no user population is specified you see the screen as it appears in Figure 13-20.

Figure 13-19 Identity Class Constraint Details: Selected User and Groups Table

Identity Class Constraints
Description of "Figure 13-19 Identity Class Constraint Details: Selected User and Groups Table"

Figure 13-20 shows the Add User Population Entries window, which appears when you click the Add button on the Selected User and Groups table. From this table, you can choose from several populations: Users, Groups, or All.

Figure 13-20 Identity Class Add User Population Entries Window

Identity Class User Population
Description of "Figure 13-20 Identity Class Add User Population Entries Window"

Table 13-16 describes the Add User Population Entries elements.

Table 13-16 Identity Class Constraint Details

Element Description

Search

List of possible search types: Users, Groups, or All

Text Field

Enter the name of a specific user or group and click the arrow button.

Results table

Displays the results of your search for selection.

Add Selected

Adds the selected users or groups from the results table to the Constraints Details page.


After selecting one or more populations and clicking the Add Selected button, your screen might look something like Figure 13-21.

Figure 13-21 Selected User and Groups Window

Identity Class User and Groups
Description of "Figure 13-21 Selected User and Groups Window"

To save these details as a constraint, click the Save button in the upper-right corner of the details page.

About IP4Range Class Constraints

With the IP4Range constraint class, administrators must add the range of IP addresses who are either allowed or denied access. Like the other constraints, this one can be used in conjunction with identity and temporal constraints.

Each IP address should be of the format 999.999.999.999 as shown in Figure 13-22.

Figure 13-22 IP4Range Class Constraints

IP4Range Class Constraints
Description of "Figure 13-22 IP4Range Class Constraints"

About Temporal Class Constraints

With the Temporal constraint class, administrators must add the start and end time and the range of days. Like the other constraints, this one can be used in conjunction with identity and IP4Range constraints.

By default, all days in the range are enabled (though none are checked in the form as shown in Figure 13-20.

Figure 13-23 Temporal Constraint Class Details Page

Temporal Constraint Class
Description of "Figure 13-23 Temporal Constraint Class Details Page"

Time periods must be specified in the HH:MM:SS (hour, minute, and second) format based on a 24-hour clock based on Greenwich Mean Time (GMT). Midnight is specified as 00:00:00 (start). The day ends at 24:59:59.

Table 13-17 Temporal Constraint Class Details

Elements Description

Type

Outcome type: Allow or Deny access.

Start Time

Notes: Time is specified using a full 24-hour range. For instance, midnight is specified as 00:00:00 and 11:00 PM is specified as 23:00:00.

Specifies the hour, minute, and second that this constraint begins.

Notes: Time is based on Greenwich Mean Time (GMT). GMT is the same all year with no adjustments for daylight savings time or summer time.

End Time

Specifies the hour, minute, and second that this constraint concludes.

Days

Specifies the days where this policy is active.

Default: AlL Days (even though these are not checked).


Save the details before closing this page.

Defining Authorization Policy Constraints

This section is divided as follows:

Defining Identity Class Constraints

Users with valid Administrator credentials can use the following procedure to add identity class constraints to an application domain.

Note:

You must save each constraint definition individually, before adding or selecting another constraint.

Prerequisites

The application domain must already exist.

To add identity class constraints to an authorization policy

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


    Application Domains
    Desired Domain
    Authorization Policies
  2. Double-click the desired policy name to open the page (or click the Edit command button in the tool bar).

  3. Click the Constraints tab.

  4. Click the Add button on the Constraints tab to display the Add Constraint window (Table 13-15) and:

    • In the Name field, enter a unique name for this Constraint.

    • From the Class list, choose Identity as the Constraint type.

    • Click the option button beside the Type (Allow or Deny).

    • Click Add Selected in the Add Constraint window.

    • Highlight the new constraint in the table and then click the Add button in the details table.

    • Add User Population Entries: Choose Users, Groups or All; enter desired search criteria, click the arrow, select desired results, and then click Add Selected.

    • Scroll in the details window to confirm your definition and click Save.

    • Repeat as needed.

  5. Click Apply and then close the Confirmation window.

  6. Close the page when you finish.

  7. Verify the Constraints.

Defining IP4Range Class Constraints

Users with valid Administrator credentials can use the following procedure to add IP-4 Range class constraints to an application domain.

Note:

If the user's IP address falls outside the range of denied addresses, this by itself is not enough for authorization to be successful. For authorization to be successful, the user must specifically be granted access based on an Allow rule.

Prerequisites

The application domain must exist.

Note:

You must save each constraint definition individually, before adding or selecting another constraint.

To add IP-4 Range class constraints to an authorization policy

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


    Application Domains
    Desired Domain
    Authorization Policies
  2. Double-click the desired policy name to open the page.

  3. Click the Constraints tab.

  4. Click the Add button on the Constraints tab to display the Add Constraint window (Table 13-15) and:

    • In the Name field, enter a unique name for this Constraint.

    • From the Class list, choose IP4Range.

    • Click the option button beside the Type (Allow or Deny).

    • Click Add Selected in the Add Constraint window.

  5. Add the desired IP address range (Table 13-16):

    • Enter the start of the range in the From: field.

    • Enter the end of the range in the To: field.

    • Click the option button beside the Type (Allow or Deny).

    • Click Save.

  6. Click Apply and then close the Confirmation window.

  7. Verify the IP-4 Range Constraints.

Defining Temporal Class Constraints

Users with valid Administrator credentials can use the following procedure to add temporal class constraints to an application domain.

Note:

You must save each constraint definition individually, before adding or selecting another constraint.

Prerequisites

The application domain must exist.

To add temporal class constraints to an authorization policy

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


    Application Domains
    Desired Domain
    Authorization Policies
  2. Double-click the desired policy name to open the page.

  3. Click the Constraints tab.

  4. Click the Add button on the Constraints tab to display the Add Constraint window and:

    • In the Name field, enter a unique name for this Constraint.

    • From the Class list, choose Temporal (Table 13-15).

    • Click the option button beside the Type (Allow or Deny).

    • Click Add Selected in the Add Constraint window.

  5. Add Temporal Details (Table 13-17): Double-click the name of the constraint, and expand the details panel.

    • Click the option button beside the constraint type (Allow or Deny).

    • Enter the Start time.

    • Enter the End time.

    • Click the days of the week to which this constraint applies (or leave all blank to specify every day of the week).

    • Click Save.

    • Repeat as needed.

  6. Click Apply and then close the Confirmation window.

  7. Verify the Temporal Constraints.

Viewing, Editing, or Deleting Authorization Policy Constraints

Users with valid Administrator credentials can use the following procedure to add identity class constraints to an application domain.

Prerequisites

The application domain and authorization policy already exist.

To view, edit, or delete authorization policy constraints

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


    Application Domains
    Desired Domain
    Authorization Policies
  2. Double-click the desired policy name to open the page.

  3. Click the Constraints tab.

  4. View Constraint Details: Click the row containing the constraint name and view the details in the lower panel.

  5. Edit Constraints: Click the row containing the constraint name, change and immediately save the details as described in:

  6. Remove constraints: Click the constraint to remove and click the Delete button on the Constraint tab.

  7. Click Apply and then close the Confirmation window.

  8. Close the page when you finish.

  9. Verify the Constraints by accessing the resource and evaluating the results.

Validating Authentication and Authorization in an Application Domain

The procedure here provides several methods for confirming that Agent registration and authentication and authorization policies are operational. The procedures are nearly identical for both OAM Agents and OSSO Agents (mod_osso). However, OSSO Agents use only the authentication policy and not the authorization policy.

Prerequisites

To verify authentication and access

  1. Using a Web browser, enter the URL for an application protected by the registered Agent to confirm that the login page appears (proving that the authentication redirect URL was specified appropriately). For example:

    http://myWebserverHost.us.abc.com:8100/resource1.html
    
  2. Confirm that you are redirected to the login page.

  3. On the Sign In page, enter a valid username and password when asked, and click Sign In.

  4. Confirm that you are redirected to the resource and proceed as follows:

    • Success: If you authenticated successfully and were granted access to the resource; the configuration is working properly.

    • Failure: If you received an error during login or were denied access to the resource, check the following:

      • Authentication Failed: Sign in again using valid credentials.

      • Access to URL ... denied: This userID is not authorized to access this resource.

      • Resource not Available: Confirm that the resource is available.

      • Wrong Redirect URL: Verify the redirect URL in the Oracle Access Manager Console.

Example: Pre-seeded IAM Suite Application Domain and Policies

IAM Suite Authentication Policies, Schemes, and Resources

The following figures present Authentication Policies in the IAM Suite application domain:

Figure 13-24 OAM Admin Console Policy, Scheme, and Resources

Policy, Scheme, and Resources
Description of "Figure 13-24 OAM Admin Console Policy, Scheme, and Resources"

Figure 13-25 Protected HigherLevel Policy, LDAP Scheme, and Resources

Protected HigherLevel Policy
Description of "Figure 13-25 Protected HigherLevel Policy, LDAP Scheme, and Resources"

Figure 13-26 Protected LowerLevel Policy, Autentication Scheme, and Resources

Protected LowerLevel Policy
Description of "Figure 13-26 Protected LowerLevel Policy, Autentication Scheme, and Resources"

Figure 13-27 Public Policy, Anonymous Scheme, and Resources

Public Policy
Description of "Figure 13-27 Public Policy, Anonymous Scheme, and Resources"

IAM Suite Authorization Policy

Figure 13-28 presents Authorization Policy in the IAM Suite application domain. There are no explicit constraints or responses. Use Implied Constraints is checked by default, which allows access in the absence of any authorization constraints of a particular class. There are no explicit constraints defined.

Figure 13-28 IAM Suite Authorization Policy

IAM Suite Authorization Policy
Description of "Figure 13-28 IAM Suite Authorization Policy"

IAM Suite Token Issuance Policy

Figure 13-29 presents IAM Suite Token Issuance Policy in the IAM Suite application domain. Use Implied Constraints is checked by default, which allows access in the absence of any authorization constraints of a particular class. There are no explicit constraints defined.

Figure 13-29 IAM Suite Token Issuance Policy and Resource URLs

IAM Suite Token Issuance Policy
Description of "Figure 13-29 IAM Suite Token Issuance Policy and Resource URLs"

See Also:

"Managing Token Issuance Policies and Constraints with Oracle Access Manager" for details about the Token Issuance Policies.