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:
Adding and Managing Resource Definitions for Use in Policies
Validating Authentication and Authorization in an Application Domain
Example: Pre-seeded IAM Suite Application Domain and Policies
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:
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 9.
Shared components for use in any application domain should be defined, as described in Chapter 12.
This section provides the following topics:
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".
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
Start the application domain registration as described in "Creating a Fresh Application Domain Manually".
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".
Configure one or more authentication policies in the domain, as described in "Defining Authentication Policies for Specific Resources".
Configure one or more authorization policies to the domain, as described in "Defining Authorization Policies for Specific Resources".
Define one or more SSO Responses to your policies, as described in "Adding and Managing Policy Responses for SSO".
Define one or more authorization constraints as described in "Defining Authorization Policy Constraints".
Define Token Issuance Policies, if needed, as described in "Managing Token Issuance Policies and Constraints with Oracle Access Manager".
Configure SSO settings as described in "Managing SSO Tokens and IP Validation".
Validate the domain's operation, as described in "Validating Authentication and Authorization in an Application Domain".
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
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:
Default Authentication Policies in a Generated Application Domain
Default Authorization Policies in a Generated Application Domain
See Also:
"Managing Token Issuance Policies and Constraints with Oracle Access Manager" for details about the Token Issuance Policies.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
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.
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
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.
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
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.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
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.
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:
This section provides the following topics:
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
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
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.
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.
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
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.
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.
Click the Refresh button in the tool bar and confirm that the new application domain appears in the navigation tree.
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".
Token Issuance Policies: See "Managing Token Issuance Policies and Constraints with Oracle Access Manager".
Users with valid Administrator credentials can use the following procedure to search for a specific application domain.
To search for an application domain
Activate the Policy Configuration tab.
From the search type list, choose Application Domain to define your search.
In the text field, enter the exact name of the instance you want to find. For example:
my_App_Domain_Name
Click the Search button to initiate the search.
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.
Click the Browse tab to return to the navigation tree when you finish with the Search results.
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
From the Policy Configuration tab, navigation tree, expand the following nodes:
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"
Token Issuance Policies: See "Managing Token Issuance Policies and Constraints with Oracle Access Manager".
Click Apply to submit the changes (or close the page without applying changes).
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.
Ensure that resources in the domain to be deleted are placed in another application domain for protection.
To delete an application domain
From the Policy Configuration tab, navigation tree, expand the Application Domain node.
In the navigation tree, open and review the application domain name.
Select the Application Domain and then click the Delete button in the tool bar.
In the Confirmation window, click Delete (or click Cancel to dismiss the window).
Check the navigation tree to confirm the application domain has been removed.
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:
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:
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
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 See Also "Managing Resource Types". The |
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:
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:
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):
Conflicts:
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:
|
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 |
|
|
|
Web applications |
|
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:
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.
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.
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.
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/.../*
.
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.
While processing requests for resources, an evaluation is made to ensure that the proper policy is invoked for the resource.
Process overview: Resource evaluation
A user specifies the URL for a requested resource.
Based on the host identifier and URL, OAM creates a fully qualified URL that includes the URL pattern.
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. |
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, xyz
index.html
.
/oracle/.../*.html matches:
/oracle/index.html /oracle/sales/order.html and so on
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"
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.The resource type must be defined as a Shared Component. For details, see "Managing Resource Types".
To add resource definitions to an application domain
From the Policy Configuration tab, navigation tree, expand the following nodes:
Within the application domain, open the Resources node.
Click the New Resource button in the upper-right corner of the Search page.
On the Resource Definition page:
Select or enter your details for a single resource (Table 13-1):
Click Apply to add this resource to the application domain.
Repeat this procedure to add other resources to this application domain.
Proceed to adding a resource to specific policies as described in:
This section provides the following topics:
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
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
Users with valid Administrator credentials can use the following procedure to search for a specific resource definition.
From the Policy Configuration tab, navigation tree, expand the following nodes:
Open the Resources node to display related Search criteria and the Search Results table.
Fill in the search criteria as needed (Table 13-0), and click the Search button.
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.
Click the Browse tab to return to the navigation tree when you finish with the Search results.
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.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
From the Policy Configuration tab, navigation tree, expand the:
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).
Users with valid Administrator credentials can use the following procedure to delete a resource from an application domain.
Ensure that the resource definition you will delete is not used in any policy.
To delete resource definitions from an application domain
From the Policy Configuration tab navigation tree, expand the following nodes:
Find the Resource, as described in "Searching for a Resource Definition"
Optional: Double-click the desired resource definition and confirm this is the one to be deleted, then close the page.
Click the name of the desired resource definition and then click the Delete button in the tool bar.
In the Confirmation window, click Delete (or click Cancel to dismiss the window).
Repeat this procedure as often as needed to delete other resources in an application domain.
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
This section provides the following topics:
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
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. |
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". |
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.
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.
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
From the Policy Configuration tab, navigation tree, expand the following nodes:
In the navigation tree, click Authentication Policies, then click the Create button to open a fresh page.
Add General Policy Details:
Name
Authentication Scheme
Add Global Policy Elements and Specifications (Table 13-6):
Description (optional)
Success URL
Failure URL
Identity Assertion
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.
Click Apply to save changes and close the Confirmation window.
Add policy Responses, as described in "Adding and Managing Policy Responses for SSO".
Close the page when you finish.
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
Activate the Policy Configuration tab.
From the search type list, choose Authentication Policies to define your search.
In the text field, enter the exact name of the policy you want to find. For example:
my_AuthNPolicy
Click the Search button to initiate the search.
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.
Click the Browse tab to return to the navigation tree when you finish with the Search results.
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.
See Also:
"About the Authentication Policy Page"To view or modify an authentication policy
From the Policy Configuration tab, navigation tree, expand the following nodes:
Double-click the desired authentication policy name.
The Authentication Policy is opened and its Resource tab is available.
General Policy Elements:
Name
Authentication Scheme
Global Policy Elements: Edit as desired, (Table 13-6):
Description
Success URL
Failure URL
Identity Assertion for Oracle Security Token Service
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.
Click Apply to submit changes and close the Confirmation window (or close the page without applying changes)
Responses: View or edit responses as described in "Adding and Managing Policy Responses for SSO".
Close the page when you finish.
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.
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
From the Policy Configuration tab, navigation tree, expand the following nodes:
Optional: Double-click the desired policy name to review its content, and then close the page.
Delete all responses, as described in "Adding and Managing Policy Responses for SSO".
In the navigation tree, click the name of the authentication policy, then click the Delete button in the tool bar.
In the Confirmation window, click Delete to confirm (or click Cancel to dismiss the window).
Ensure that resources governed by this policy are added to a different policy.
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
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:
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
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) |
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 |
|
Responses Tab |
Users with valid Administrator credentials can use the following procedure to add an authorization policy to an application domain.
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
From the Policy Configuration tab, navigation tree, expand the following nodes:
In the navigation tree, click Authorization Policies and then the Create button.
Enter a unique name for this authorization policy.
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
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.
Click Apply to save changes and close the Confirmation window.
Constraints: Add authorization constraints, as described in "Defining Authorization Policy Constraints".
Responses: Add or edit responses for SSO, as described in "Adding and Managing Policy Responses for SSO".
Close the page when you finish.
Users with valid Administrator credentials can use the following procedure to locate a specific authorization policy.
To search for an authorization policy
Activate the Policy Configuration tab.
From the search type list, choose Authentication Policies to define your search.
In the text field, enter the exact name of the policy you want to find. For example:
my_AuthZPolicy
Click the Search button to initiate the search.
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.
Click the Browse tab to return to the navigation tree when you finish with the Search results.
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
From the Policy Configuration tab, navigation tree, expand the following nodes:
Double-click the desired policy name to display details.
Global Elements: Edit as needed (Table 13-7):
Description (optional)
Success URL
Failure URL
Use Implied Constraints
Identity Assertion for Oracle Security Token Service
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.
Click Apply to submit changes and close the Confirmation window (or close the page without applying changes).
Constraints: View or edit these as described in "Viewing, Editing, or Deleting Authorization Policy Constraints".
Responses: View or edit these as described in "Viewing, Editing, or Deleting a Policy Response for SSO".
Close the page when you finish.
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".Assign resources governed by this policy to another authorization policy, either before or after deleting the policy.
To delete an authorization policy
From the Policy Configuration tab, navigation tree, expand the following nodes:
Optional: Double-click the policy name to review its content, and then close the page when finished.
Click the policy name, and then click the Delete button in the tool bar.
In the Confirmation window, click Delete (or click Cancel to dismiss the window).
Confirm that the policy is no longer listed in the navigation tree.
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:
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
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.
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:
|
Value |
The response expression, set as a variable. For more information, see "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
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"
Table 13-10, "Namespace Session Variables for Single Sign-On"
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 |
This section is divided as follows:
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.
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 |
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.
Table 13-13 describes the complex responses shown in Figure 13-15.
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".
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 WebgateWhen 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.
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.
Users with valid Administrator credentials can use the following procedure to add a policy response for authentication or authorization.
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.
From the Policy Configuration tab, navigation tree, expand the following nodes:
Double-click the desired policy name to open the page.
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.
Click Apply, then close the Confirmation window.
Close the page when you finish.
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.
Users with valid Administrator credentials can use the following procedure to view or edit a policy response for authentication or authorization.
You must have an application domain with an existing authentication or authorization policy.
To view, modify, or delete a policy response
From the Policy Configuration tab, navigation tree, expand the following nodes:
Double-click the desired policy name to open the page.
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.
Responses: Edit a response as follows.
Click the Responses tab.
Click the desired response Name, Type, or Value.
Make the desired change.
Repeat as needed and click Apply when finished.
Click Apply, then close the Confirmation window.
Close the page when you finish.
Verify Responses based on your definitions for:
Header
Session
Cookie: Use a browser plug-in tool or turn on the browser "show cookies" settings.
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.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:
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.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.
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.
All constraint definitions apply along with the general authorization policy details shown in Figure 13-16.
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". |
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.
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 details are specific to the chosen constraint class, as described in following topics:
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
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
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
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"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.
See Also:
"Defining IP4Range 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
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.
See Also:
"Defining Temporal Class Constraints"This section is divided as follows:
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.The application domain must already exist.
See Also:
"About Identity Class Constraints"To add identity class constraints to an authorization policy
From the Policy Configuration tab, navigation tree, expand the following nodes:
Double-click the desired policy name to open the page (or click the Edit command button in the tool bar).
Click the Constraints tab.
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.
Click Apply and then close the Confirmation window.
Close the page when you finish.
Verify the 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.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
From the Policy Configuration tab, navigation tree, expand the following nodes:
Double-click the desired policy name to open the page.
Click the Constraints tab.
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.
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.
Click Apply and then close the Confirmation window.
Verify the IP-4 Range 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.The application domain must exist.
See Also:
"About Temporal Class Constraints"To add temporal class constraints to an authorization policy
From the Policy Configuration tab, navigation tree, expand the following nodes:
Double-click the desired policy name to open the page.
Click the Constraints tab.
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.
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.
Click Apply and then close the Confirmation window.
Verify the Temporal Constraints.
Users with valid Administrator credentials can use the following procedure to add identity class constraints to an application domain.
The application domain and authorization policy already exist.
To view, edit, or delete authorization policy constraints
From the Policy Configuration tab, navigation tree, expand the following nodes:
Double-click the desired policy name to open the page.
Click the Constraints tab.
View Constraint Details: Click the row containing the constraint name and view the details in the lower panel.
Edit Constraints: Click the row containing the constraint name, change and immediately save the details as described in:
Remove constraints: Click the constraint to remove and click the Delete button on the Constraint tab.
Click Apply and then close the Confirmation window.
Close the page when you finish.
Verify the Constraints by accessing the resource and evaluating the results.
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.
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.
To verify authentication and access
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
Confirm that you are redirected to the login page.
On the Sign In page, enter a valid username and password when asked, and click Sign In.
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.
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"
Figure 13-25, "Protected HigherLevel Policy, LDAP Scheme, and Resources"
Figure 13-26, "Protected LowerLevel Policy, Autentication Scheme, and Resources"
Figure 13-27, "Public Policy, Anonymous Scheme, and Resources"
Figure 13-24 OAM Admin Console Policy, Scheme, and Resources
Figure 13-25 Protected HigherLevel Policy, LDAP Scheme, and Resources
Figure 13-26 Protected LowerLevel Policy, Autentication Scheme, and Resources
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 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
See Also:
"Managing Token Issuance Policies and Constraints with Oracle Access Manager" for details about the Token Issuance Policies.