9 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 11g Administration Console for tasks and includes the following topics:

• Prerequisites

• Introduction to Application Domain Creation

• Anatomy of an Application Domain and Policies

• Managing Application Domains using the Administration Console

• Adding and Managing Resource Definitions for Use in Policies

• Defining Authentication Policies for Specific Resources

• Defining Authorization Policies for Specific Resources

• Introduction to Policy Responses for SSO

• Adding and Managing Policy Responses for SSO

• Introduction to Authorization Constraints

• Defining Authorization Policy Constraints

• Managing the Common SSO Engine

• Validating Authentication and Authorization in an Application Domain

Prerequisites

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

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

• Oracle Access Manager 11g should be operational

• Users and groups who can access a protected resource should already be created in the User Identity Store associated with OAM 11g.

• Policy-enforcement Agents should be registered as described in Chapter 5.

• Shared components for use in any application domain should be defined, as described in Chapter 8.

Introduction to Application Domain Creation

This section provides the following topics:

• About Automatic Application Domain Creation

• About Manually Creating Application Domains

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:

IDMDomainAgent is a pre-registered Java Agent filter that provides an application domain of the same name to protect Oracle Fusion Middleware console and other

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

3. Add one or more resources to the domain, as described in "Adding and Managing Resource Definitions for Use in Policies".

4. Configure one or more authentication policies to 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. Configure SSO Engine settings as described in "Managing the Common SSO Engine".

9. 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 9-1 illustrates Application Domain-specific components of the Oracle Access Manager 11g Policy Model.

Figure 9-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.

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

• Application Domain General Details

• Default Resource Definition in a Generated Application Domain

• Default Authentication Policies in a Generated Application Domain

• Default Authorization Policies in a Generated Application Domain

Application Domain General Details

Figure 9-2 shows an application domain name highlighted in the navigation tree under the Application Domains node, and the Application Domain page with a name and description.

Figure 9-2 Application Domain Generated using the Administration Console

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 Resource Definition in a Generated Application Domain

Figure 9-3 illustrates the default resource definition in the generated application domain. The Host Identifier matches the Agent name that was specified during registration. The default Resource Type is HTTP; the default Resource URL is /.../*.

Figure 9-3 Default Resource Definition in the Application Domain

See Also:

"Adding and Managing Resource Definitions for Use in Policies"

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 the following authentication policies are automatically generated:

• Protected Resource Policy

• Public Resource Policy

The Protected Resource Policy is shown in Figure 9-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 9-4 Default Authentication Policy for Protected Resources

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

See Also:

"Introduction to Policy Responses for SSO"

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 the following authorization policies are automatically generated:

• Protected Resource Policy

• Public 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 9-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 9-5 Default Authorization Policy for Protecting Resources

Authorization, Public Resource Policy: A second authorization policy is also created. The description explains "Policy set during domain creation. Add resources to this policy to allow anyone access." This Public Resource Policy does not initially protect any Resources.

See Also:

• "Introduction to Policy Responses for SSO"

• "Introduction to Authorization Constraints"

Managing Application Domains using the Administration Console

This section provides the following topics:

• About the Application Domains Page

• Creating a Fresh Application Domain

• Searching for an Application Domain

• Viewing or Editing an Application Domain

• Deleting an Application Domain and Its Content

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 Administration Console, several pages are involved. Initially, you add general details (name and optional description) on the form show in Figure 9-6.

Figure 9-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 9-7 illustrates the Application Domains navigation tree and the IDMDomainAgent-related containers for resources and authentication and authorization policies.

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

Users with valid OAM Administrator credentials can perform the following task to manually create an application domain using the OAM Administration Console.

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

See Also:

"Introduction to Application Domain Creation"

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 the Add Application Domain link 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:

   • Resources: See "Adding and Managing Resource Definitions for Use in Policies".

   • Authentication Policies: See "Defining Authentication Policies for Specific Resources".

   • Authorization Policies: See "Defining Authorization Policies for Specific Resources".

Searching for an Application Domain

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

See Also:

"About Search Controls"

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 OAM Administrator credentials can perform the following task to view or modify an application domain (including its resources, policies, constraints, and responses) using the OAM Administration 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:

   • Resources: See "Adding and Managing Resource Definitions for Use in Policies".

   • Authentication Policies: See "Defining Authentication Policies for Specific Resources".

   • Authorization Policies: See "Defining Authorization Policies for Specific Resources".

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

Deleting an Application Domain and Its Content

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

WARNING:

The application domain must be empty before you delete it. You must delete all authentication and authorization policies and resources before you can delete the domain itself. Deleting the domain does not automatically delete the host identifier used in the domain.

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 following nodes:

   
   Application Domains
   Domain Name
   

2. Delete all Authentication Policies:

   1. Expand the Authentication Policies node to reveal existing policies.

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

   3. Repeat Steps a through c to remove all Authentication Policies.

3. Delete all Authorization Policies:

   1. Expand the Authorization Policies node to reveal existing policies.

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

   3. Repeat Steps a through c to remove all Authorization Policies.

4. Delete all Resources in the Domain:

   1. Expand the Resources node to reveal existing resource names.

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

   3. Repeat Steps a through c to remove all resources from the application domain.

5. In the navigation tree, click the application domain name and then click the Delete button in the tool bar.

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

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

• An entire external Web site

• Specific pages in a Web site

• Partner portals

• A parts order application

• Invoice applications

• A benefits enrollment application on Web servers of an enterprise in many countries

This section provides the following topics:

• About the Resource Definition Page in an Application Domain

• Searching for a Resource URL Definition

• Adding Resource Definitions to an Application Domain

• Viewing or Editing a Resource Definition in an Application Domain

• Deleting a Resource Definition from an Application Domain

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. Figure 9-8 illustrates a typical Resources definition page, which illustrates details of one resource in the pre-configured IDMDomainAgent application domain.

Figure 9-8 Resources Page in an Application Domain

Table 9-1 describes elements that must be specified on the Resources page.

Table 9-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. See Also "Managing Resource Types".
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. Other components, such as the query string or fragment, are not used. 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 9-2.

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

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

• About the Host Identifier in a Resource Definition

• About the Resource URL

• About Run Time Resource Evaluation

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:

There is no host identifier or URL 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 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 9-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 9-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.

See Also:

"Managing Run Time Policy Evaluation Caches"

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 9-4 describes the possible outcomes.

Table 9-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.htmlindex.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 OAM 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".

See Also:

"About the Resource Definition Page in an Application Domain"

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. Click the Resources node, then click the Create button in the tool bar.

3. On the Resource Definition page:

   1. Add details for a single resource:

      
      Type
      Description (optional)
      Host Identifier
      Resource URL (see Table 9-2)
      

   2. Click Apply to add this resource to the application domain.

   3. In the navigation tree, expand Resources to confirm that the addition is successful (or click the Refresh button in the tool bar).

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

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

   • Defining Authentication Policies for Specific Resources

   • Defining Authorization Policies for Specific Resources

Searching for a Resource URL Definition

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

See Also:

"About Search Controls"

To search for a specific resource definition

1. Activate the Policy Configuration tab.

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

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

   my_Resource_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 a Resource Definition in an Application Domain

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

Prerequisites

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

See Also:

"About the Resource Definition Page in an Application Domain"

To view or modify resource definitions in an application domain

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

   
   Application Domains
   Desired Domain
   Resources
   

2. Double-click the desired resource definition to open the page and proceed as follows:

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

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

3. Click the name of the desired resource definition 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. 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:

• Protected Resource

• Public Resource

See Also:

"Anatomy of an Application Domain and Policies"

This section provides the following topics:

• About the Authentication Policy Page

• Adding an Authentication Policy and Resources

• Searching for an Authentication Policy

• Viewing or Editing an Authentication Policy

• Deleting an Authentication Policy

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. There is no policy inheritance as there is with Oracle Entitlement Server. The policy cannot be applied to any other resource.

Figure 9-9 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 IDMDomainAgent application domain.

Figure 9-9 Authentication Policy Page: IDMDomainAgent

Table 9-5 describes authentication policy elements. The IDMDomainAgent application domain is shown simply as an example.

Table 9-5 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.
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 OAM 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.

See Also:

• "About the Authentication Policy Page"

• "Managing Authentication Schemes"

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

2. Click the Create button in the tool bar to open a fresh page.

3. Add General Policy Details:

   • Name

   • Authentication Scheme

4. Add Global Policy Elements (Table 9-5):

   • Description (optional)

   • Success URL

   • Failure URL

5. Add Resources:

   • Click the Resources tab on the Authentication Policy page.

   • Click the Add button on the tab.

   • Click 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 OAM Administrator credentials can use the following procedure to search for a specific authentication policy.

See Also:

"About Search Controls"

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

See Also:

"About the Authentication Policy Page"

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 9-5):

   • Description

   • Success URL

   • Failure URL

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

See Also:

"About the Authentication Policy Page"

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:

• Protected Resource

• Public Resource

See Also:

"Anatomy of an Application Domain and Policies"

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

• Adding an Authorization Policy and Specific Resources

• Searching for an Authorization Policy

• Viewing or Editing an Authorization Policy and Resources

• Deleting an Authorization Policy

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 9-10 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 IDMDomainAgent application domain is shown simply as an example.

Figure 9-10 Authorization Policy Page: IDMDomainAgent

Table 9-6 describes authorization policy elements. The elements are the same regardless of the domain; only the details will differ. The IDMDomainAgent application domain is shown simply as an example.

Table 9-6 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".
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 OAM 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.

See Also:

"About Authorization Policies for Specific Resources"

To add an authorization policy and resources

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

   
   Application Domains
   Desired Domain
   Authorization Policies
   

2. Click the Create button in the tool bar.

3. Add a unique name for this authorization policy.

4. Global Policy Elements: Enter your own details (Table 9-6):

   • Description (optional)

   • Success URL

   • Failure URL

   • Use Implied Constraints

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 OAM Administrator credentials can use the following procedure to locate a specific authorization policy.

See Also:

"About Search Controls"

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 OAM Administrator credentials can use the following procedure to view or modify an authorization policy within an application domain.

See Also:

"About Authorization Policies for Specific Resources"

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 9-6):

   • Description (optional)

   • Success URL

   • Failure URL

   • Use Implied Constraints

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 OAM 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".

See Also:

"About Authorization Policies for Specific Resources"

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.

This section provides the following information:

• About Authentication and Authorization Policy Responses for SSO

• About the Policy Response Language

• About the Namespace and Variable Names for Policy Responses

• About Constructing a Policy Response for SSO

• About Policy Response Processing

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 9-11 illustrates an Authorization Policy Response defined by an administrator in the OAM Administration Console. Authorization responses can operate in conjunction with authorization constraints.

Figure 9-11 Authorization Policy Response in the Administration 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 how 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 Administration Console, as described Table 9-7.

Table 9-7 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 supported 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 9-8, "Namespace Request Variables for Single Sign-On"

• Table 9-9, "Namespace Session Variables for Single Sign-On"

• Table 9-10, "Namespace User Variables"

Table 9-8 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 9-9 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 9-10 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

About Constructing a Policy Response for SSO

This section is divided as follows:

• Simple Responses

• Compound and Complex Responses

Simple Responses

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

Figure 9-12 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 9-11 illustrates several simple responses and a description of what each one returns.

Table 9-11 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 9-13 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 9-13 Sample Complex Responses

Table 9-12 describes the complex responses shown in Figure 9-13.

Table 9-12 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 2010/Wed Feb 24 01:47:42 PST 2010/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

• Viewing, Editing, or Deleting a Policy Response for SSO

Adding a Policy Response for SSO

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

See Also:

"Introduction to Policy Responses for SSO"

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

     See Also:

     "About the Namespace and Variable Names for Policy Responses"

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

See Also:

"Introduction to Policy Responses for SSO"

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:

• An Allow type condition that specifies who is authorized to access a protected resource.

• A Deny type condition that specifies explicitly who is denied access to the protected resource.

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:

• Identify the users or groups of users who are who are either allowed or denied access to protected resources.

• Stipulate the range of IP addresses who are either allowed or denied access to protected resources.

  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.

• Set a time period defining when the constraint applies.

This section provides the following topics:

• About Allow or Deny Type Constraints

• About Classifying Users and Groups for Constraints

• About Constraints and General Authorization Policy Details

• About the Add Constraint Window

• About Identity Class Constraints

• About IP4Range Class Constraints

• About Temporal Class Constraints

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 cn (common name) 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 9-14.

Figure 9-14 Authorization Policy Page, General Details

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

Table 9-13 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)

About the Add Constraint Window

When an administrator adds a constraint to an authorization policy, the window shown in Figure 9-15 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 9-15 Add Constraint Window

Table 9-14 describes the Add Constraint window elements.

Table 9-14 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 9-16. 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 9-16 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

• About IP4Range Class Constraints

• About Temporal Class Constraints

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 9-18.

Figure 9-17 Identity Class Constraint Details: Selected User and Groups Table

Figure 9-18 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 9-18 Identity Class Add User Population Entries Window

Table 9-15 describes the Add User Population Entries elements.

Table 9-15 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 9-19.

Figure 9-19 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.

See Also:

"Defining Identity Class Constraints"

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 9-20.

Figure 9-20 IP4Range Class Constraints

See Also:

"Defining 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 9-18.

Figure 9-21 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 9-16 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.

See Also:

"Defining Temporal Class Constraints"

Defining Authorization Policy Constraints

This section is divided as follows:

• Defining Identity Class Constraints

• Defining IP4Range Class Constraints

• Defining Temporal Class Constraints

• Viewing, Editing, or Deleting Authorization Policy Constraints

Defining Identity Class Constraints

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

See Also:

"About Identity Class Constraints"

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 9-14) 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 OAM 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.

See Also:

"About IP4Range Class Constraints"

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 9-14) 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 9-15):

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

See Also:

"About Temporal Class Constraints"

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

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

   • Click Add Selected in the Add Constraint window.

5. Add Temporal Details (Table 9-16): 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 OAM 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.

See Also:

"Introduction to Authorization Constraints"

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:

   • "Defining Identity Class Constraints"

   • "Defining IP4Range Class Constraints"

   • "Defining Temporal Class Constraints"

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.

Managing the Common SSO Engine

The SSO Engine is the controller for user sessions. SSO Engine settings common to all OAM Servers in the administration domain.

This section provides the following details:

• About Common SSO Engine Settings

• Viewing or Editing Common SSO Engine Details

See Also:

"Introduction to OAM Server Registration and Management"

About Common SSO Engine Settings

The SSO Engine is the controller for user sessions. SSO Engine settings are global and common to all OAM Servers in the WebLogic administration domain.

Figure 9-22 shows the common SSO Engine settings that are shared by all Oracle Access Manager server instances.

Figure 9-22 Common SSO Engine Settings

Description of "Figure 9-22 Common SSO Engine Settings"

Table 9-17 describes common SSO Engine settings, which include a type (text string) and a value.

Table 9-17 Common SSO Engine Settings

Setting	Description
IP Validation	Specific to WebGates and is used to determine whether a client's IP address is the same as the IP address stored in the ObSSOCookie generated for single sign-on.
SSO Token Version	Select your SSO token version from the list.
OAM Server Host	The port on which the host is listening.
OAM Server Port	The port on which the host is listening.
OAM Server Host Protocol	Either HTTP or HTTPS. See Also: "About Security Modes and X509Scheme Authentication"

Viewing or Editing Common SSO Engine Details

Users with valid OAM Administrator credentials can perform the following task to modify common SSO Engine details using the OAM Administration Console.

See Also:

"About Common SSO Engine Settings"

To view or edit common SSO Engine details

1. From the System Configuration tab, navigation tree, double-click Server Instances to display the Server Common Properties page.

2. On the Server Common Properties page, click the SSO Engine tab:

   • View Only: Close the page when you finish.

   • Modify: Perform remaining steps to edit the common SSO Engine configuration.

3. Edit settings as needed for your deployment, based in details in Table 9-17.

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

5. Dismiss the Confirmation window.

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

• Users and groups who are granted access must exist in the primary LDAP User Identity Store that is registered with OAM 11g

• Agents must be registered to operate with OAM 11g. After registration, protected resources should be accessible with proper authentication without restarting the Administration or Managed Server.

• Application domain, authentication policies, and authorization policies must be configured.

See Also:

Chapter 10, "Validating Connectivity and Policies Using the Access Tester"

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 Administration Console.