25.9 Introduction to Authorization Policy Rules and Conditions

In Access Manager 11g, each Authorization policy includes a rule that defines whether the policy allows or denies access to resources protected by the policy. The rule references conditions that define the user or population to be granted or denied access and other considerations for authorization. Authorization rules and conditions apply to all resources within a specific authorization policy.

Evaluation of conditions and rules 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 rules, conditions, and responses. For each incoming request, the authorization policy determines if there are any conditions that apply. If so, these conditions are evaluated.

This section provides the following topics:

25.9.1 About Allow or Deny Rules

In an authorization policy, a Rule contains all (or a subset) of conditions defined for the policy. The effect of the Rule determines the effect of the policy. You can set one or more rule effects (outcomes) per policy. However, you can specify only one Rule per outcome.

The following outcomes can be applied to authorization and token issuance policies:

  • Allow authorized users access to a protected resource. If Allow 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.

  • Deny authorized users access to a protected resource.

You can develop simple rules that rely on a single condition, or use expressions to define more complex rules based on multiple conditions. For more information, see "Expressions and Expression-Based Policy".

25.9.2 Authorization Policy Conditions

A condition is an element that specifies one or more criteria to be satisfied by the access request. Each authorization policy can contain one or more conditions.

In structure, conditions are similar to constraints (in and However, earlier constraints included Allow and Deny rules that are now specified independently on the Rules tab.

Using different condition types, you can:

  • Identify the users or groups of users who are either allowed or denied access (based on the rule) to protected resources.

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


    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 condition applies.

  • Specify attributes that enforces evaluation of request context, user session state, and user attributes

The Conditions tab provides a table of defined conditions, organized by name, and a table of details for the selected condition, as shown in Figure 25-16.

Figure 25-16 Individual Authorization Policy Conditions Tab

Description of Figure 25-16 follows
Description of "Figure 25-16 Individual Authorization Policy Conditions Tab"

Table 25-11 describes elements and controls on the Conditions tab.

Table 25-11 Authorization Policy Condition Tab

Element Description

Conditions Table Elements

Lists all conditions defined for this policy.


A unique name used as an identifier for the condition.


The kind of condition you want to use. Only one Type can be specified:

  • Identity

  • IP4 Range

  • Temporal

  • Attribute

  • True (see Table 21-5)


Optional unique text that describes this condition.

Condition Details Section

Depending on the Type of the selected condition, the information in this table will differ. For details, see:

25.9.3 About Classifying Users and Groups for Conditions

Oracle recommends that you consider the same information for the policies and conditions 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 Type) while another might be constrained to a specific group of users (Identity Type).


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

When classifying users Oracle recommends that you divide the users, and groups of users, into groups for whom different conditions apply. For example, conditions 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 conditions.

To create policies for subsets of resources in an Application Domain and protect them with different authorization rules and conditions, consider the same information: who can access the resources protected by this policy and under what conditions you want explicitly to allow or deny access to the resources.

25.9.4 Guidelines for Authorization Responses Based on Conditions

For each condition type, consider the response actions that you want to occur for authorized users.

You might want the system to return user profile information and pass that information to a downstream application. For example:

  • If the user is authorized, you might 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 might also want to return information about the user for security purposes.