| Oracle® Access Manager Access Administration Guide 10g (10.1.4.0.1) Part Number B25990-01 |
|
|
View PDF |
| Oracle® Access Manager Access Administration Guide 10g (10.1.4.0.1) Part Number B25990-01 |
|
|
View PDF |
The Access System enables you to protect your resources with policy domains and policies that specify who is authorized to use the resources and who is not allowed to use them, and under what conditions.
This chapter explains authorization and how to configure authorization rules and authorization expressions to meet the requirements for your policy domains and their policies. A policy domain must include an authorization expression among the set of default rules that specify how its resources are protected. Authorization rules are combined to create authorization expressions.
This chapter discusses the following topics:
Authorization is the process of determining whether a user has the right to access a requested resource. To protect resources, you define authorization rules which contain conditions. Authorization rules are contained within authorization expressions. A policy domain and a policy can each contain only one authorization expression.
In addition to authorization rules, policy domains and policies also include authentication rules and audit rules, which are described in other chapters of this guide. After you have created your policy domains, you can define their rules and expressions. You can create the authentication rules, authorization rules and expressions, and audit rules for a policy domain in any order. Before you read this chapter, read the following chapters:
Chapter 3, "Configuring WebGates and Access Servers" describes the configuration of AccessGates and Access Servers, which you must do before the policy domains you create can take effect.
Chapter 4, "Protecting Resources with Policy Domains" describes how to create and test policy domains and policies, how to define resource types, and how to define audit rules.
Chapter 5, "Configuring User Authentication" describes how to create and use authentication schemes and rules.
An authorization rule can contain:
A condition that specifies who is authorized to access a protected resource. This condition is referred to as the Allow Access condition of the rule.
A condition that specifies explicitly who is denied access to the protected resource. This condition is referred to as the Deny Access condition of the rule.
Both Allow Access and Deny Access conditions.
Both Allow Access and Deny Access conditions.
If Allow Access or Deny Access conditions or both are specified and they do not apply to a user, the user is not qualified by the rule. If a user is unqualified by a rule, by default the user is denied access to the requested resource.
To specify who is authorized to use the resource or explicitly denied access, the rule can:
Identify the users by their user name, role, or an LDAP filter whose criteria the user must satisfy.
Stipulate the computers from which users can access the resources.
Set the period of time during which the rule applies.
Additionally, you can set actions to be taken if the rule is evaluated to allow qualifying users access to the resource. You can also set actions to be taken if the rule is evaluated to deny qualifying users access to the resource.
Resources of a policy domain are protected by an authorization expression containing one or more authorization rules.
Authorization expressions include
Authorization rules that you select from among those that have been defined for the policy domain.
Operators that you use to combine rules in various ways to provide the kind of authorization protection required for the policy domain.
An authorization expression may consist of a single rule or a group of rules combined to express more complex conditions. For example, you can create an expression which requires that a user meet the Allow Access conditions of two rules to be granted access to the resource. You use the Policy Manager interface to combine rules in expressions.
This chapter describes the Policy Manager authorization component, and it explains how it works. It also provides the procedures you use to protect your resources with authorization expressions.
Here is an overview of the steps you follow to create authorization expressions for your policy domains and their policies:
Task overview: Creating authorization expressions
Create your policy domain, as discussed in Chapter 4, "Protecting Resources with Policy Domains".
Determine who is authorized to use the resources of the policy domain, and under what conditions, using the "Guidelines for Classifying Users". See also "Authorization Rules".
You can give specific users access to the resources. You can also explicitly deny specific users access to the resources. It is not necessary for you to create rules that apply to all of your users—whether to allow them access or to expressly deny them access.
Some users may not qualify for the conditions of a rule. They may qualify for other rules of the expression, or they may not qualify for the conditions of any rules. If a user does not qualify for the conditions of any of the rules of an expression, by default the user is denied access to the resource.
Create all of the authorization rules you need to protect the resources of the policy domain and any of its policies. See "Configuring Authorization Rules" for details.
You create all of these rules at the level of the policy domain. When you create a rule, you include an authorization scheme in it. If you do not plan to use the Authorization Scheme provided by the Access System, you must configure one or more custom ones. In this case, you must provide custom plug-ins. See "Authorization Schemes for Custom Plug-Ins" for details.
Create the authorization expression for the policy domain, which can have only one authorization expression. See "Authorization Expressions" for details.
Create an authorization expression for each of the policy domain's policies. See "Authorization Expressions" for details.
|
Note: You must configure an authorization expression to determine if users are permitted to access resources. If no authorization expression is defined, access is denied to the target resources. |
Observe the following guidelines when classifying users:
Divide the users and groups of users into sets for whom different conditions apply—conditions such as when they can access the resources, the computers from which they must make their requests, and so on. See "About the Contents of an Authorization Rule" for details.
If some users fall into more than one category—for example, a user in the marketing group belongs to the Teleon project group, a user in the human resources group also belongs to the Teleon group—put the user in both categories. You can require that the user meet the conditions of two rules.
|
Note: You do not need to be concerned about users who are denied access to the resources of the policy domain under any conditions. They are denied access by default if none of the rules of an expression qualify them. |
For each category for which you want to create a separate rule, consider the kinds of actions you want to occur if the user is authorized to use the resource or if the user is not authorized to use it as a result of the rule. For example, for one case or the other, you may want the system to return user profile information and pass that information to a downstream application:
If the user is authorized to use the resource, 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 to use the resource, you may also want to return information about the user to be used for security purposes. (For information about actions, see "Authorization Actions".)
Do this analysis for users and groups: users for whom you want to grant authorization to use the policy domain's resources; users and groups for whom you want to explicitly deny authorization to use the resources.
If you want to create policies for subsets of resources within a policy domain and protect them with different authorization rules, consider the same information for the policies: who can access the resources of the policy and under what condition; for whom, and under what conditions, you want explicitly to deny access to the resources.
An authorization rule specifies information that identifies who can access a resource it protects. It also specifies who is explicitly denied access to the resource. One or more authorization rules are included in an authorization expression for a policy domain or policy.
When a user requests access to a resource protected by an authorization rule included in an authorization expression, information about the user is checked against the rule. If the rule stipulates other kinds of information, such as period of time or time of day the rule applies, that, too, is checked. This process is referred to as evaluation of the rule.
The result of evaluation of an authorization rule—in conjunction with other authorization rules, if more than one is included in the authorization expression—determines whether a user is granted access to the requested resource.
At the policy domain level, you create all of the authorization rules to be used for a policy domain or any of its policies. You combine these rules to create authorization expressions. For details about authorization expressions, see "Authorization Expressions".
This section describes authorization rules, and how to create and manage them. It includes the following topics:
An authorization rule specifies the following two types of primary conditions:
A condition referred to as Allow Access that grants the user access to the resource.
A condition referred to as Deny Access that denies the user access to it.
When a user is said to qualify for an authorization rule, it does not mean that the user is authorized to use the resource protected by the rule. A user is said to qualify for a rule if the user meets a condition of the rule:
If the user meets the Allow Access condition, the user qualifies for the Allow Access part of the rule.
If the user meets the Deny Access condition, the user qualifies for the Deny Access part of the rule.
If the user satisfies neither the Allow Access nor the Deny Access conditions, the rule is said to be unqualified for that user. You can also think of this as the user not qualifying for the rule. If evaluation of a rule results in an unqualified user, the user is denied access to the resource based on that rule.
For authorization expressions that contain more than one rule, a user may qualify for none of the expression's rules, one of the rules, or for the conditions of more than one rule. In any case, it is the result of evaluation of the expression—all of its rules and how they are combined—not any one rule, that determines whether a user is allowed or denied access to a resource.
A policy domain can have only one authorization expression, which can include all of the authorization rules necessary to express the protection requirements for its resources. Each of the policies a policy domain contains can have its own authorization expression.
Any of the authorization rules you define for a policy domain can be used for the policy domain and for any of the policies it contains in the following ways:
It can appear in more than one authorization expression.
It can appear in a single authorization expression more than once.
For information about authorization expressions, see "Authorization Expressions".
An authorization rule contains the following information:
General Information: An authorization rule has a name and a description, and it can be enabled or disabled. See "Configuring Authorization Rules" for details.
Allow Access: The Allow Access condition of an authorization rule specifies the end users and groups of users who are allowed access to a resource protected by the rule. See "Setting Allow Access" for details.
Deny Access: The Deny Access condition of an authorization rule specifies the end users and groups of users who are explicitly denied access to a resource protected by the rule. See "Setting Deny Access" for details.
Timing Conditions: An authorization rule can be configured to include a value that restricts access to a resource within a period of time, such as 9:00 a.m. to 5:00 p.m. on week days for one group of users and 10:00 a.m. to 4:00 p.m. for another group of users. See "Setting Timing Conditions"for details.
Actions: For either result of an authorization rule—whether its evaluation results in authorization success or authorization failure for a user requesting access to a protected resource—an associated set of actions can be specified to be taken in response to the result. For example, the Access System can return a header variable to be passed to a downstream application. The following list describes the kinds of actions you can specify:
Static values and user profile identity values passed in HTTP header variables or cookies.
See "Authorization Actions" for information about actions.
When information about a user requesting access to a protected resource is checked against the conditions of an authorization rule, and the user qualifies for one of the conditions of the rule, that rule is evaluated to produce one of the following results:
Authorization Success
In this case, the user succeeds in gaining access to the requested resource. This result is associated with the Allow Access condition of the rule.
Authorization Failure
In this case, the user fails to gain access to the requested resource. This result is associated with the Deny Access condition of the rule.
Evaluation of a rule can produce neither result if the user requesting access to the protected resource is not mentioned in the Allow Access or the Deny Access conditions of the rule. In this case, the evaluation of the rule is said to be inconclusive, and the user is denied access to the rule.
This discussion provides details about configuring and managing authorization rules:
You may find it useful to display a list of authorization rules before you define a new one.
To display a current list of authorization rules
From the landing page for the Access System, click the Policy Manager link.
If you are working with the Access System Console, click the Policy Manager link at the top of the page.
Click My Policy Domains.
The General page for the policy domain appears.
Select the policy domain that you want to view.
Select the Authorization Rules tab for the policy domain.
The Authorization Rules page appears, as illustrated in the following screen shot, showing the list of authorization rules configured for the policy domain.
To configure an authorization rule, you define its general information, you set its Allow Access and Deny Access conditions, and you define actions for the rule, if any. This section describes how to configure general information for a rule.
You can specify general information about an authorization rule to identify the rule, to specify its authorization scheme, to enable or disable the rule, and so forth. Some of the information you can configure is optional.
You must specify an authorization scheme for every authorization rule you define. You can use the Authorization Scheme provided by the Access System or you can select a custom authorization scheme, if any are configured. See "Authorization Schemes for Custom Plug-Ins" for details.
You create all of the authorization rules to be used for a policy domain or any of its policies at the policy domain level.
To define an authorization rule
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain that you want to see.
Select the Authorization Rules tab.
A page appears listing existing authorization rules for the policy domain.
|
Note: If you are creating a policy domain, you do not see any configured authorization rules. |
Click Add.
The General page for the authorization rule appears.
Specify a name for the authorization rule and, optionally, a brief description of it in the following text boxes:
Name: A name for this authorization rule.
Description: A brief description of this authorization rule.
For example, for an authorization rule that includes a custom authorization scheme, you could explain the function the custom plug-in provides.
Select Yes from the Enabled list to enable the authorization rule or No to disable it.
Select Yes if you want the authorization rule to be activated as soon as you click Save. Enabling an authorization rule makes it available for inclusion in an authorization expression. The rule is disabled by default.
After an authorization rule is used in an authorization expression, you cannot disable it until it is removed from all of the expressions that use it.
For Allow takes precedence, select one of the following:
Yes: If you want the Allow Access condition to take precedence over the Deny Access condition.
No: If you want the Deny Access condition to take precedence over the Allow Access condition.
If you configure Allow Access and Deny Access conditions for a rule, use this option to specify which condition of the rule should be honored if the user qualifies for both of a rule's conditions.
Determine when you want Access Server caches to be updated.
Immediately: Select Update Cache to update all Access Server caches immediately with information about this new prefix.
Later: If you do not select Update Cache, the Access Server caches are updated when they time out and read new information from the directory server.
Click Save.
The General page appears displaying the information you specified.
Select the authorization scheme to include in the authorization rule.
If the Master Access Administrator has not created custom authorization schemes, the only scheme available is the Oracle Authorization Scheme.
Click Add.
The General page for an authorization rule appears.
The Allow Access part of an authorization rule defines users and groups who are authorized to use the protected resource.
From the landing page for the Access System, click the Policy Manager link.
If you are working in the Access System Console, the link for the Policy Manager is at the top of the page.
Click My Policy Domains in the left navigation pane.
Select the policy domain that you want to see.
Select the Authorization Rules tab.
A page appears listing the authorization rules for the policy domain.
If you are creating a policy domain, you do not see any configured authorization rules.
Select the authorization rule whose Allow Access conditions you want to set.
Click the Allow Access tab.
Click Add if no conditions exist, click Modify if they exist.
Specify the users and groups who are allowed to access resources protected by this rule using the People, Role, Rule, and IP Address controls as indicated in the following list.
|
Note: These options are alternatives. An end user or group specified in any of these fields is allowed access. |
People: Click Select User to select by user name
Use the Search facility to display configured users.
Click Add before the name of each user who is allowed to access resources protected by this rule.
Role: Select No Role in the Role selection box to prevent users from being selected based on roles or select Anyone to allow anyone access to the protected resources.
Rule: Enter an LDAP filter that specifies the users and groups who are allowed to access the protected resources using the plus and minus buttons to add new filters and delete existing ones.
IP Address: Enter the IP addresses of computers whose users are allowed access.
Except where noted, the Access System supports the following conventions for IP addresses in Access System and Policy Manager:
- An explicit address, such as 192.2.2.2.
- An address with a wildcard, but the wildcard must be the last entry, such as 192.2.2.*, 192.2.*, or 192.*
The Access System does not support the following items:
- An address in which a wildcard is not the final entry. For example, 192.128.*.2 is not supported.
- An entry of all wildcards, such as ***.*.*.*.
If you entered an IP address using a format that is not supported, the error message "Invalid IP address entered" appears.
For the IP Address fields, click the plus and minus buttons to add new IP addresses and delete existing ones.
Determine when you want Access Server caches to be updated.
Immediately: Select Update Cache to update all Access Server caches immediately with information about this new prefix.
Later: If you do not select Update Cache, the Access Server caches are updated when they time out and read new information from the directory server.
Click Save.
The Deny Access part of an authorization rule specifies the users and groups who are denied the right to use the resources protected by this rule.
From the Policy Manager, select My Policy Domains, then click on the policy domain that you want to see.
If you are in the process of defining the rule and have configured the rule's general information, you do not need to retrace this path.
Select the Authorization Rules tab.
A page appears listing authorization rules for the policy domain.
If you are creating a policy domain, you do not see any authorization rules.
Select the authorization rule for which you want to set Deny Access conditions.
A set of panels for the authorization rule appears, with the General panel selected. Other panels for the rule are Timing Conditions, Allow Access, and Deny Access.
Click the Deny Access panel, then click Add if no authorization rules exist, or click Modify if they exist.
Specify the users and groups who are denied to access resources protected by this rule using the People, Role, Rule, and IP Address controls as indicated in the following list.
|
Note: These options are alternatives. An end user or group specified in any of these fields is denied access. |
People: Click Select User to select by user name.
Use the Search facility to display configured users.
Click Add before the name of each user who is denied to access resources protected by this rule.
Role: Select No Role in the Role selection box to prevent users from being selected based on roles or select Anyone to deny anyone access to the protected resources.
Rule: Enter an LDAP filter that specifies the users and groups who are denied to access the protected resources using the plus and minus buttons to add new filters and delete existing ones.
IP Address: Enter the IP addresses of computers whose users are denied access.
Except where noted, the Access System supports the following conventions for IP addresses in Access System and Policy Manager:
- An explicit address, such as 192.2.2.2.
- An address with a wildcard, but the wildcard must be the last entry, such as 192.2.2.*, 192.2.*, or 192.*.
The Access System does not support the following items:
- An address in which a wildcard is not the final entry. For example, 192.128.*.2 is not supported.
- An entry of all wildcards, such as ***.*.*.*
If you entered an IP address using a format that is not supported, the error message "Invalid IP address entered" appears.
For the IP Address fields, click the plus and minus buttons to add new IP addresses and delete existing ones.
Determine when you want Access Server chaches to be updated.
Click Save.
Use the Timing Conditions option to set the time periods when the authorization rule is in effect. For example, you may want the rule to remain in effect only during business hours, Monday through Friday. If you do not set a timing condition, by default the authorization rule is always in effect. Take into account that both of the rule's conditions—its Allow Access and its Deny Access conditions—remain in effect for the specified time period.
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain that you want to see.
Select the Authorization Rules tab.
A page appears listing the authorization rules for the policy domain.
If you are creating a policy domain, you do not see any authorization rules.
Select the authorization rule for which you want to set timing conditions.
The General panel for the authorization rule appears. Other panels for the authorization rule include Timing Conditions, Actions, Allow Access, and Deny Access.
Click the Timing Conditions panel.
If any timing conditions exist, they are listed. Otherwise, this page reports that there are no timing conditions for the authorization rule.
Click Add to create a new timing condition if none have been defined, or click Modify if they exist.
The Timing Conditions page appears.
Select either Greenwich Mean Time or Local time on Web server:
Greenwich Mean Time: A standard for universal time. If you use Greenwich Mean Time, this authorization rule is in force at the same time throughout the world.
Use this option if you want this rule to be in force at the same time for your globally-dispersed workforce.
Local time on Web server: Indicates that users outside the server's time zone could be denied access.
For example, if the server is located in New York, and the timing conditions do not allow access after 5 P.M., West Coast users would be denied access starting at 2:01 P.M.
|
Note: If you want to restrict hours for users in various time zones, do not use this option. Instead, create a separate authorization rule that gives West Coast users access until 8 P.M. Eastern Time, and so forth. |
Select a Start Date and End Date.
|
Note: If you select the — option, for the Start Date, then this rule effectively does not have a Start Date. If you select the — option, for the End Date, then this Rule effectively does not have an End Date. |
Select a Start Time and End Time:
You cannot choose only a Start Time or End Time. If you specify a Start Time, you must choose an End Time.
By default, the Start Time and End Time fields are set to —, which means this rule does not have a Start Time and End Time. It is in effect 24 hours a day.
When choosing a Start Time and End Time, you must make a selection for all three fields (hours, minutes, seconds). If you do not, the Start Time and End Time are invalid.
Select the Months of the Year, Days of the Month, and Days of the Week for which this rule is valid.
|
Note: To select a single item (for example, a month) click to select it. To select more than one, hold down the Shift key as you select additional items in the same list. If you select the — option, this rule is in effect everyday. |
Select Update Cache if you want all AccessGate and Access Servers caches to be updated immediately with information about these timing conditions.
Click Save.
You may want to view general information about an authorization rule before you decide to modify the rule or use the rule in an authorization expression.
To view the general information for an authorization rule
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain that you want to see.
Select the Authorization Rules tab.
A page appears listing the authorization rules for the policy domain.
Select the authorization rule whose general information configuration you want to see.
The General information panel for the authorization rule appears, showing the name, description, enabled status, and Allow Takes Precedence value for the rule. Other panels for the rule include Timing Conditions, Actions, Allow Access, and Deny Access.
You can modify the authorization rules for a policy domain at any time. However, it is good practice to disable a rule before you modify it.
To modify an authorization rule
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain that you want to see.
Select the Authorization Rules tab.
A page appears listing the authorization rules for the policy domain.
Select the authorization rule that you want to modify.
Click Modify.
The General page with editable text boxes appears.
Verify that the Enabled status box is blank to ensure the rule is disabled before modifying information.
Modify the general information as required, and any of the following:
Timing Conditions: Click the tab, and follow the instructions for defining them.
Actions: Click the Actions tab and follow the instructions for defining actions in "Authorization Expressions".
Allow Access or Deny Access: Click the appropriate link, and follow the instructions for defining the rules.
Click Save.
You cannot delete an authorization rule that is used in an authorization expression for the policy domain or any of its policies.
To delete an authorization rule
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain that you want to see.
Select the Authorization Rules tab.
A page appears listing the authorization rules for the policy domain.
Select the check box for each rule that you want to delete.
Click Delete.
In some cases, a single authorization rule is all that is required to protect the resources of a policy domain or a policy. You can configure the rule to identify who is allowed access to the resources it protects, who is denied access to them, and under what conditions these controls apply—when they apply and from which computer, for example. An authorization rule does not need to cover all users in its Allow Access and Deny Access conditions. Users who do not qualify for any of the conditions of the rule and who request access to a resource protected by the rule are, by default, denied access to the resource.
For other cases, it may be necessary to configure many authorization rules to protect resources with complex restrictions imposed on different users. For example, you may want to define a policy that includes many authorization rules, a part of any one of which a user must meet to qualify for access to a protected resource (or to qualify for denial of access to it). You may also want the same policy domain to specify more than one condition a user must meet. For example, you may require that the user meet two conditions—such as belonging to one group and using a computer assigned a specific IP address—to be granted access to the resource. To define the complete authorization conditions required for the resources you want to protect, you form an authorization expression. The Policy Manager provides an interface that makes it easy for you to form authorization expressions. You must create a default authorization expression for the policy domain, but you can also create an authorization expression for a policy within the domain.
This section describes authorization expressions, and how to create and manage them. It includes the following topics:
In an authorization expression, you define authorization requirements for a set of resources. An authorization expression can apply to resources for the entire policy domain or for one of its policies.
An authorization expression includes:
You can define only one authorization expression for a policy domain. This becomes the default authorization expression for the policy domain. You can define one authorization expression for each policy in the domain. An authorization expression can contain any of the authorization rules defined at the policy domain level. Figure 6-1 illustrates the default authorization expression for a policy domain. For the default protected URL, the authentication rule, authorization expression, and audit rule together form the defaults for the policy domain.
An authorization expression is always evaluated from left to right. The rules of an expression can be grouped using operators, and how they are grouped has a bearing on the outcome of the overall evaluation of the expression.
You can use two operators to combine the rules of an expression: AND and OR. You combine authorization rules to create authorization expressions that can include the following types of conditions:
A Compound Condition: Specifies more than one condition for which a user must qualify, either to be granted access to the requested resource or explicitly denied access to it, depending on the rest of the expression. You use the AND operator for this purpose. See "Authorization Rules Used in Example Scenarios".
A Complex Condition: Specifies two or more alternative conditions any of which a user must meet, either to be allowed access to the requested resource or denied access to it, depending on the condition and its relationship to the rest of the rules of the expression. You use the OR operator for this purpose. See "Authorization Rules Used in Example Scenarios".
See "About Evaluation of the Rules of an Expression" for details explaining how grouping of the rules of an expression using AND and OR is interpreted.
Evaluation of an authorization expression can result in the following three conditions:
Authorization Success: In this case, the user succeeds in gaining access to the requested resource. This result is associated with the Allow Access condition of the expression.
Authorization Failure: In this case, the user fails to gain access to the requested resource. This result is associated with the Deny Access condition of the expression.
Authorization Inconclusive: In this case, the rules of the expression produce conflicting results, and the user is denied access to the resource.
An expression can return a result of Inconclusive, in which case the Access System returns a major status code of Deny and a minor status code of Inconclusive.
The major status code of Deny is returned for Inconclusive results to maintain compatibility with previous releases of the system. The minor status code of Inconclusive is available to Oracle Access Manager systems to allow those systems to distinguish between true Deny results and Deny results returned because of an Inconclusive state.
An authorization expression result of Deny differs from an authorization expression result of Inconclusive even though the user is denied access to the resource in both cases. An application written to run with Oracle Access Manager can interpret the two status codes for an Inconclusive result and use the additional information for other purposes. For example, the application can then invoke other authorization engines instead of denying the user access to the resource.
An authorization expression can contain a mix of compound conditions and complex conditions which determine whether a user can access a resource protected by the expression. When a user requests access to a protected resource, the user's information is checked against the rules of the expression.
The interplay between user information assessed against the rules of an expression, the position of the rules in the expression, and the way in which the rules are combined in the expression allows for a wide degree of variety. An authorization expression is exercised to different extents depending on these variables—that is, some of its rules might not be evaluated.
Precedence and Position: The Access Server processes the rules of an expression in the following way:
Precedence of Operators: The AND operator takes precedence over the OR operator in regard to how rules of an expression are combined.
That is, if an expression contains three or more rules combined in some way with the AND operator and the OR operator, the Access Server always associates the rules on either side of the AND operator with it first, and then it combines the rules using the OR operator.
For example, given the following authorization expression,
R1 OR R2 AND R3
internally the Access Server creates the following grouping by default:
R1 OR (R2 AND R3)
The Access Server goes through the entire expression making these groupings based on AND taking precedence over OR before it evaluates the user's information against the rules.
For details about operators, see "Authorization Rules Used in Example Scenarios".
|
Note: You can override the default way in which operators are interpreted by using parenthesis to enforce new groupings. See "About the Use of Parenthesis" for details. |
Position of Rules in an Expression: The Access Server evaluates an expression from left to right.
You do not assign to an authorization rule its priority among other rules. It would not be possible to reuse authorization rules if you assigned to each of them an evaluation priority. Rather, you position rules in an expression from left to right—which is the order in which they are evaluated—and you use operators to combine them. For details about operators, see "Authorization Rules Used in Example Scenarios".
Use of Parenthesis to Override Default Precedence: You can use parenthesis to override the default way in which the Access Server groups the rules of an expression. The Access Server continues to evaluate the rules of an expression from left to right, but it assesses the rules within the couplings and groups you create through use of parenthesis. See "About the Use of Parenthesis".
About the Definitive Result of an Authorization Expression: The Access Server evaluates the rules of an expression until it can produce a definitive result. Evaluation of an authorization expression may produce a definitive Allow Access result, a Deny Access result, or an Inconclusive result.
For example, a user qualifies for the Allow Access condition of Rule 1, the Deny Access condition of Rule 2, and the Deny Access condition of Rule 3 of the following expression.
(Rule 1 AND Rule 2) OR Rule 3
In this case, evaluation of Rule 3 produces a definitive result of the expression, and the user is denied access to the resource. Neither Rule 1 nor Rule 2 has any bearing on the outcome of the expression because they produce conflicting results as part of an AND condition. Because Rule 3 is part of an OR condition, it stands on its own. If the user satisfies the rule's Allow Access or Deny Access condition, then Rule 3 defines the outcome of the expression.
For Rule 2 to be responsible for the definitive result, the user must qualify for either both the Allow Access conditions or both the Deny Access conditions of Rule 1 and Rule 2. In this case, Rule 3 would not be evaluated because evaluation of Rule 1 and Rule 2 would produce a definitive result. Therefore, evaluation of Rule 3 would be unnecessary.
Table 6-1 contains examples of authorization rules that, if defined at the policy domain level, could be used in authorization expressions for the domain and any of its policies. The example authorization rules in Table 6-1 show only one condition of a rule—either its Allow Access condition or its Deny Access condition—not the full authorization rule.
An authorization rule need not specify both an Allow Access condition and a Deny Access condition, or either one alone. It can specify either condition, both conditions, or none. Table 6-1 identifies example authorization rules which are used in example scenarios throughout the rest of this chapter.
Table 6-1 Example Authorization Rules and Their Conditions
| Authorization Rule | Condition |
|---|---|
|
Rule 1 |
Allow anyone from the marketing department group access to the requested resource. |
|
Rule 2 |
Allow anyone using a computer with the IP address 192.168.2.123 access to the requested resource. |
|
Rule 3 |
Allow anyone from the human resources department group access to the requested resource. |
|
Rule 4 |
Allow anyone from the Teleon project group access to the requested resource. |
|
Rule 5 |
Deny anyone from the consultants group access to the requested resource. |
|
Rule 6 |
Deny anyone from the Saber project group access to the requested resource. |
|
Rule 7 |
Deny anyone using a computer with the IP address 192.168.5.123 access to the requested resource. |
|
Rule 8 |
Allow anyone from the managers group access to the protected resource. |
|
Rule 9 |
Allow anyone from the administrative assistants group access to the protected resource. |
You use the AND operator to form a compound condition which combines authorization rules. Any number of rules can be combined using the AND operator to implement the full scope of conditions a user must meet to satisfy the authorization requirement. However, a user must satisfy the same kind of condition—either Allow Access or Deny Access—of all of the rules of the AND compound condition for the AND clause to produce a definitive result.
An authorization expression can contain more than one coupling or grouping of rules combined using AND. For example, it may contain several AND clauses, one connected to another by an OR operator.
|
Note: A user may qualify for both the Allow Access condition and the Deny Access condition of the same rule. In this case, whichever condition is configured to take precedence is the one that is honored. You configure this setting in the Allow takes precedence field. |
The following scenarios use the example authorization rules in Table 6-1 to illustrate compound conditions. For some of these examples, the Policy Manager Authorization Expressions page you use to create the expression is shown. Here is where to find information explaining how to use these pages to create authorization expressions:
For the steps to follow to create an authorization expression, see "Creating Authorization Expressions".
For information explaining how to use the Authorization Expression interface portion of the Policy Manager to create expressions, see "Modifying an Authorization Expression as You Create It". These instructions apply both to creating an expression and modifying an existing one.
A Compound Condition Whose Two Authorization Rules Specify Allow Access Conditions: To be allowed access to a resource protected by the following authorization expression, a user must belong to the marketing department group and the IP address of the user's computer must be 192.168.2.123.
Rule 1 AND Rule 2
A Compound Condition Whose Three Authorization Rules Specify Allow Access Conditions: To be allowed access to a resource protected by the following authorization expression, a user must belong to the marketing department and the executive team, or must be accessing the resource from IP address 192.168.2.123.
Rule 1 AND Rule 2 AND Rule 4
Here is what the expression would look like if you configured it using the Expression panel of the Authorization Expression sub-tab.
A Compound Condition Whose Two Authorization Rules Specify Deny Access Conditions: To be explicitly denied access to a resource protected by the following authorization expression, a user must belong to the Consultants group and belong to the Saber project group.
Rule 5 AND Rule 6
An authorization expression can include a complex condition containing two or more alternative authorization rules. Authorization rules forming a complex condition are combined using the OR operator. Each of the authorization rules specified by a complex OR condition stands on its own. Unlike compound conditions using the AND operator, the user need qualify for the condition of only one of the authorization rules connected by OR operators.
An authorization expression can contain as many authorization rules connected using the OR operator as are required to express the authorization policy for the resources it protects. You can use the OR operator to connect authorization rules all of which have Deny Access conditions, all of which have Allow Access conditions, or which specify a mix of Deny Access and Allow Access conditions. You can connect single rules to single rules using OR, and you can connect a single rule to a clause containing rules combined using AND.
The following scenarios use the example authorization rules in Table 6-1.
A Complex Condition Whose Two Rules Specify Allow Access Conditions: To be allowed access to a requested resource protected by the following rule, a user must either be a member of the marketing department group or the human resources department group.
Rule 1 OR Rule 3
Complex Condition Whose Three Authorization Rules Specify Deny Access Conditions: To be explicitly denied access to a requested resource, a user must belong to the Consultants group, or belong to the project XYZ group, or use a computer with the IP address 192.168.5.123.
Rule 5 OR Rule 6 OR Rule 7
Here is what the expression would look like if you configured it using the Authorization Expression's Expression page.
A Complex Condition with Rules that Specify a Mix of Allow Access and Deny Access Conditions: To be allowed access to a requested resource protected by the following expression, a user must either be a member of the marketing department group or the executive team. To be explicitly denied access to a requested resource, a user must belong to the Consultants group or be a member of the XYZ project group.
Rule 1 OR Rule 2 OR Rule 5 OR Rule 6
Here is what the expression would look like if you configured it using the Expression panel on the Authorization Expression tab.
The following scenarios use the example authorization rules in Table 6-1 to illustrate authorization expressions that contain both compound and complex expressions.
A Complex Condition Authorization Expression with Three Rules: A Delegated Access Administrator forms the following expression:
Rule 2 OR Rule 4 AND Rule 1
Here is what the expression would look like if you configured it using the Authorization Expression's Expression page.
Jane requests access to a resource protected by this authorization expression. The Access Server evaluates the expression to determine if Jane meets either of the following conditions that would allow her access to the resource:
The IP address of Jane's computer is 192.168.2.123 and she belongs to the executive group (Rule 4 AND Rule 1)
Jane is a member of the marking department group (Rule 2)
If parenthesis were used to make explicit the grouping of rules according to how the Access Server evaluates the authorization expression, the expression would look like this:
Rule 2 OR (Rule 4 AND Rule 1)
An expression is evaluated from left to right until a definitive result is produced. Jane meets the condition of Rule 1, which is followed by the OR operator, so she is granted access to the resource.
A Complex Condition Expression with Four Rules: A Delegated Access Administrator forms the following expression:
(Rule 2 AND Rule 4) AND (Rule 7 OR Rule 8)
Here is what the expression would look like if you created it using the Authorization Expression's Expression page.
Maurice is allowed access to a resource protected by this authorization expression because he satisfies the following conditions:
He is a member of the marketing department and the IP address of his computer is 192.168.2.123. (Rule 2 AND Rule 4)
He is also a manager and belongs to the Managers group. (Rule 8)
The IP address of Maurice's computer is not 192.168.5.123 (Rule 7). However, he is not denied access for this reason because the authorization expression dictates that he meet either Rule 7 or Rule 8, but not both.
A Complex Condition Expression with Six Rules: A Delegated Access Administrator forms the following expression:
Rule 2 OR Rule 4 OR Rule 1 AND Rule 9 OR Rule 5 AND Rule 6
Here is what the expression would look like if you used the Authorization Expression's Expression page to configure it. Notice that the Authorization Expression List box does not show the last rule. To see the last rule, you would have to scroll down. However, the Text Format box wraps the text to show the complete expression.
If parenthesis were used to make explicit the grouping of rules, the expression would look like this:
Rule 2 OR Rule 4 OR (Rule 1 AND Rule 9) OR (Rule 5 AND Rule 6)
Following the order of precedence of AND over OR in regard to how rules are grouped and left-to-right processing of the rules, a user must qualify for one of the following conditions to gain access to the requested resource:
The first single rule of the complex condition (Rule 2)
A user who belongs to the marketing department group is allowed access to the resource.
The second single rule of the complex condition (Rule 4)
A user whose computer has the IP address 192.168.2.123 is allowed access to the resource.
The first compound condition (Rule 1 AND Rule 9)
A user who belongs to the executive team and who belongs to the ABC project group is allowed access.
The second compound condition (Rule 5 AND Rule 6)
A user who belongs to the Consultants group and the XYZ project group is denied access to the resource.
In its evaluation, the Access Server progresses through the expression until it evaluates a rule that produces the definitive result of the expression. If the Access Server completes evaluation of the expression and the user does not qualify for any of its conditions, the result of the evaluation is Inconclusive. In such a case, because no rules apply to the user, no actions associated with rules are taken. However, the actions configured for the Inconclusive result of the expression are taken. For information about actions, see "Authorization Actions". For information about status codes returned for inconclusive results, see "Status Codes for an Inconclusive Result".
By default, two rules on either side of an AND operator compose the compound AND condition. Rules on either side of an OR operator are alternatives. When no parenthesis are used to enforce grouping of rules, the AND operator takes precedence over the OR operator.
For example, if no parenthesis were used in the following expression to override the default way in which the rules of the following expression would be evaluated:
R1 OR R2 AND R3 OR R4 AND R5
the expression would be interpreted in the following way:
R1 OR (R2 AND R3) OR (R4 AND R5)
You can use parenthesis to override the normal grouping of the rules of an expression, for example, to give precedence to the OR condition over the AND condition.
The following example uses the same expression. In this instance of the expression, parenthesis are used to override the default grouping:
(R1 OR R2) AND (R3 OR R4) AND R5
The following discussions provide procedures for working with authorization expressions:
A policy domain can have only one authorization expression. Each of its policies can also have an authorization expression. If an expression has already been defined for either, you can look at its definition at any time.
If an authorization expression exists for the policy domain or for a policy, the Expression page displays the entire authorization expression. If the authorization expression is long, the text is wrapped onto the next line, and so on, to display all of the expression.
An authorization expression includes the content of the expression—its rules and operators—and the configuration for the expression itself.
To view an authorization expression for a policy domain
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain whose authorization expression you want to see.
Select Default Rules.
Select the Authorization Expression tab.
The Authorization Expression page appears, as illustrated in the following screen shot. This page shows the name of the expression and its value configured for the policy domain. It also has three panels: Expression, Duplicate Actions, and Actions.
To look at values configured for the expression:
If a duplicate actions policy has been configured for the authorization expression, this section defines how duplicate actions are handled for the policy domain protected by the authorization expression. A policy domain can include one or more policies.
See "About Duplicate Actions" for details.
Click Actions.
This section defines the actions configured for this authorization expression.
Click Modify to look at the content of the expression.
The configuration for an expression appears on the page used to create the expression or modify it.
To see the actions configured for each rule of an expression, you must check the rule's configuration. See "Authorization Rules".
Each policy has its own authorization expression. You can view it from within the definition of the policy.
An authorization expression includes the content of the expression—its rules and operators—and the configuration for the expression itself.
To view an authorization expression for a policy
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain containing the policy whose authorization expression you want to see.
Select Policies.
Select the policy whose authorization expression you want to see.
Click Authorization Expression.
The Authorization Expression page appears, as illustrated in the following screen shot. This page shows the name of the expression, Lost Password Management None Authorization rule.
Click Modify to look at the content of the expression.
The configuration for the expression appears on the page used to create it or modify it.
|
Note: To see the actions configured for each rule of an expression, you must check the rule's configuration. See "Authorization Rules". |
Optional: Look at values configured for the expression:
Click Duplicate Actions to display the section that defines how duplicate actions are handled for the resources protected by this policy. The setting for the policies authorization expression Duplicate Actions overrides that of the policy domain. See "About Duplicate Actions" for details.
The authorization expression for a policy may contain its own duplicate actions setting. In this case, the policy domain's duplicate actions setting overrides the one set for the policy domain.
Click Actions to display the section that defines the actions configured for this authorization expression.
The authorization expression for a policy domain applies to all resources of the domain unless those resources are protected by a policy containing an expression.
To create an authorization expression for a policy domain
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain for which you want to create an authorization expression.
Select Default Rules.
Select the Authorization Expression tab.
The Authorization Expression page appears. If there is no defined authorization expression, a message appears, "There is no Authorization Expression defined."
|
Note: If an authorization expression exists, you can only modify its content. To replace it, you must modify all parts of it. |
Click Add.
The Authorization Expression page you use to create the expression appears, as illustrated in the following screen shot.
You use the Authorization Expression page to create an authorization expression.
Using the following steps, select the authorization rules for the authorization expression and the operators you want to use to combine those rules.
|
Note: If you want to include the first rule in a parenthetical phrase, click the open parenthesis button before you add the first rule to the expression. |
From the Select Authorization Rule list, select the first rule to be added to the expression, and click Add.
If the authorization expression includes more than one rule, select the operator to be used to combine the first two rules.
For the AND operator, click the And button beside Select Separator.
For the OR operator, click the Or button beside Select Separator.
To begin a parenthetical phrase, click the open parenthesis button.
To close a parenthetical phrase, click the close parenthesis button.
Continue to add rules to the authorization expression, and combine them with other rules until you have completed forming the expression to fit your authorization requirements.
Click Save to save the expression.
Select the Duplicate Actions tab in the Authorization Expression page.
The Duplicate Action Headers page appears, as illustrated in the following screen shot.
Click Modify to select the duplicate actions policy. The Duplicate Actions page appears, as illustrated in the following screen shot.
Click Select the checkbox and the radio button for the type of Duplicate Actions handling you want.
The duplicate actions policy you set at the authorization expression level overrides that set at the Access System Console level.
Determine when you want Access Server chaches to be updated.
Immediately: Select Update Cache to update all Access Server caches immediately with information about this new prefix.
Later: If you do not select Update Cache, the Access Server caches are updated when they time out and read new information from the directory server.
You cannot save an authorization expression that contains syntax errors. When you click Save, the Access Server checks the authorization expression to ensure that it is well-formed. If an authorization expression contains a syntax error—for example, an error occurs if you include an AND or OR operator at the end of the expression—you must correct the error and then save the expression.
Click Save.
After you save the authorization expression, the Authorization Expression view page appears showing the full expression. For details explaining how to use the features of the Authorization Expression page to create an expression, see "Modifying an Authorization Expression as You Create It".
The steps you use to create an authorization expression for a policy are the same as those for a policy. For details, see "Creating Authorization Expressions". Start with the step that follows step 5, "Click Add."
To create an authorization expression for a policy
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain containing the policy for which you want to create an authorization expression.
Select the Policies page.
Select the name of the policy for which you want to create an authorization expression.
Select the Authorization Expression tab.
The Authorization Expression page appears displaying the message "No authorization expression is defined for this policy."
Click Add.
The Authorization Expression with an active list box, text entry box, and scrolling lists appears.
As you create an authorization expression, you may want to change the way you have combined the rules of the expression. You may change the form of an expression as you create it, for example, to express a different authorization policy or to correct errors.
If the authorization expression contains many components—rules and operators—a scroll bar is displayed at the right side of the authorization expression list box so that you can scroll to bring items into view.
You can modify an authorization expression in either of the following two ways:
You can modify an authorization expression within the Authorization Expression list box.
You can modify an authorization expression within the Authorization Expression in Text Format box.
Changes you make to an authorization expression in one box are reflected in the other box in the following ways:
As you form the authorization expression by adding rules and operators to the Authorization Expression list box, the Authorization Expression in Text Format box is automatically updated to reflect the additions and modifications.
After you make changes to an expression in the Authorization Expression in Text Format box, you must click the Update button for those changes to be reflected in the Authorization Expression list box.
The way some operators are expressed in the Authorization Expression list box differs from how they are expressed in the Authorization Expression in Text Format box. The following table shows the differences.
Table 6-2 Operators for List Box and Text Format Box
| Operator in List Box | Operator in Text Format Box |
|---|---|
|
AND |
& |
|
OR |
| |
|
( |
( |
|
) |
) |
You use buttons to enter operators in the Authorization Expression List box. You use keys to enter operators in the Authorization Expression in Text Format text box.
The Authorization Expression list box displays the authorization rules and the operators that you use to combine them as you select and add rules and operators to form the expression.
|
Note: As you create an authorization expression using the Authorization Expression list box, the expression content is reflected in the Authorization Expression in Text Format editable text box. |
To manipulate the content of an expression in the Authorization Expression list box, you use the following buttons:
Modify: Replaces one rule of an authorization expression with another rule selected from the Select Authorization Rule list.
To replace one operator with another, you swap the two operators directly by selecting one operator and clicking the button for the replacement operator.
Delete: Deletes any selected item—a rule, an operator, or an open or close parenthesis—from the Select Authorization Rule list.
Delete All: Clears the entire content of the authorization expression.
To replace one authorization rule with another
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain whose authorization expression you want to modify.
Select Default Rules.
Select the Authorization Expression tab.
The Authorization Expression view page appears showing the existing authorization expression.
Click Modify.
The Authorization Expression with an active selection list, text entry box, and scrolling list box appears.
Select the rule to be replaced in the Authorization Expression list.
Select the replacement rule in the Select Authorization Rule list.
Click the Modify button.
The old rule in the Authorization Expression list is replaced by the new rule.
To replace one operator with another
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain whose authorization expression you want to modify.
Select Default Rules.
Select the Authorization Expression tab.
The Authorization Expression view page appears showing the existing authorization expression.
Click Modify.
The Authorization Expression page with an active selection list, text entry box, and scrolling list box appears.
Select the operator to be replaced in the Authorization Expression list.
Click the button for the replacement operator.
To replace the OR operator with the AND operator, select OR in the expression, and click the And button.
To replace the AND operator in the expression, select it and click the Or button.
The old operator is replaced by the new one in the Authorization Expression list.
Select the item to be deleted in the Authorization Expression list.
Click the Delete button.
To delete the entire content of an expression
Navigate to the Authorization Expression list.
Click the Delete All button.
As you form the authorization expression by adding rules and operators to the Authorization Expression list, the Authorization Expression in Text box is updated to reflect the additions and modifications.
You can modify the textual content of an authorization expression directly using the Authorization Expression in Text box.
Entering New Text: To modify the text, you use keyboard or keypad keys and symbols to enter new text or to overtype existing text. (In addition to typing the text, the main difference is that you enter symbols to represent operators.) See Table 6-2 for the symbols to use for operators.
Deleting Text: To delete text from the authorization expression, you use any of the standard approaches you take to handle text in a flat text file.
Updating the Authorization Expression List: To update the list with the changes you made in the Authorization Expression in Text Format text box, click the Update button directly beneath the text box.
If an authorization expression exists for the policy domain or for a policy, the Authorization Expression view page displays the entire expression. If the authorization expression is long, the text is wrapped onto the next line, and so on, to display all of the expression.
You can modify an authorization expression after it has been used to protect the policy domain or the policy for which it was created.
When modifying an authorization expression, you follow the same procedures you use to create an expression. This section describes how to navigate to the Authorization Expression page you use to modify an expression for a policy domain and for a policy.
To display the page for modifying the authorization expression for a policy domain
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain for which you want to create an authorization expression.
Select Default Rules.
Select the Authorization Expression tab.
The Authorization Expression view page appears showing the existing authorization expression.
Click Modify.
The Authorization Expression page with an active selection list and two text entry boxes appears.
For the remainder of this process, see the steps of the following procedures for creating and modifying an authorization expression:
To display the Authorization Expression page for a policy to modify the expression
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain containing the policy for which you want to create an authorization expression.
Select the Policies tab.
Select the name of the policy whose authorization expression you want to modify.
Select the Authorization Expression tab.
The Authorization Expression view page appears showing the existing authorization expression.
Click Modify.
The Authorization Expression with an active list box, text entry box, and scrolling list box appears.
For the remainder of this process, see the steps of the following procedures for creating and modifying an authorization expression:
Before you can create a new authorization expression for a policy domain or for one of its policies, you must delete the existing one.
To delete the authorization expression for a policy domain
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain whose authorization expression you want to delete.
Select Default Rules.
Select the Authorization Expression tab.
The Authorization Expression view page appears showing the existing authorization expression.
Click Modify.
The Authorization Expression edit page appears showing the content of the existing authorization expression.
Click the Delete All button beneath the Authorization Expression text box.
To delete the authorization expression for a policy
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain containing the policy whose authorization expression you want to delete.
Select the Policies tab.
Select the name of the policy whose authorization expression you want to delete.
Select Default Rules.
Select the Authorization Expression tab.
The Authorization Expression view page appears showing the existing authorization expression.
Click Modify.
The Authorization Expression edit page appears showing the content of the existing authorization expression.
Click the Delete All button beneath the Authorization Expression list box.
For every authorization rule, you can configure both a set of actions to be taken if a user is granted access to the requested resource as a result of evaluation of the rule and a set of actions to be taken if a user is denied access to the resource. You can also configure sets of actions to be taken depending on the result of the authorization expression itself.
For both entities—rules and expressions—the definitive result of evaluation of the expression determines which actions are taken. Not all rules of an authorization expression contribute to the definitive result of the expression. The only actions taken are for the rules that led up to the definitive result of the expression. For explanation of the definitive result, see "About Evaluation of the Rules of an Expression".
This section includes the following topics pertaining to actions:
In addition to being able to define to whom the Allow Access part and the Deny Access part of a rule applies when you configure the rule, you can also specify separate sets of actions for each result of the rule. You can configure actions for the following results of evaluation of rules and expressions:
Authorization Success: For both rules and expressions
Authorization Failure: For both rules and expressions
Authorization Inconclusive: For expressions only
This result occurs when evaluation of the rules of the expression for which the user qualifies produce conflicting results, or the user does not qualify for any rules of the expression.
Additional information about these conditions is provided in the following sections:
For a description of the results of rules of an expression, see "About Authorization Rule Evaluation".
For a description of the results of expressions, see "About Authorization Expression Evaluation".
Actions allow you to:
Redirect the user's browser to another URL.
You can redirect URLs from the Access Server to an AccessGate or a WebGate.
Pass information about the user to downstream applications in the same policy domain or a different one.
Using HTTP header variables or cookies, you can use actions to pass the following kinds of information:
User profile
User's DN
Static text strings
See "About the Use of HTTP Header Variables and Cookies" for details about using header variables to pass information to downstream applications.
Consider the 4K size limit of the HTTP header when you use HTTP header variables and cookies to pass information to downstream applications. This HTTP header size limit includes all cookies, server variables, environment variables—that is, all of the content of the HTTP header. There is no constraint on the number of individual elements an HTTP header can contain, as long as the content does not exceed the 4K limit. When assessing the amount of available space in the HTTP header, take into account the byte size of the data used by the Access System and other applications. For example, if the Access System and other applications combined use 1K in the HTTP header, you would have 3K for your data.
If a header variable's value is dynamic, the value is not available until the Access Server cache is refreshed.
The refresh frequency is set in the Policy Cache Timeout field in the Access Server Configuration/Name of Access Server screen. If you plan to use header variables with dynamic values, ask your Master Administrator about the refresh frequency.
Web servers process header variables differently. This variability affects how you must implement header variables in your applications.
Here are some examples:
Netscape/iPlanet Web servers precede Oracle Access Manager variables with the string, HTTP:
If you define a variable called HTTP_CN, Netscape/iPlanet produces a variable called HTTP_HTTP_CN.
When you write an application that needs to read a header variable, the application must look for a variable called HTTP_HTTP_CN and not HTTP_CN.
Microsoft IIS expects header variables to be defined with a dash, not an underscore. You would enter HTTP–CN, not HTTP_CN.
The receiving application must read the variable as if it had an underscore. It looks for HTTP_CN, not HTTP–CN.
The Lotus Domino Web server cannot pass Oracle Access Manager header variables.
For information about how to use header variables for various servers, refer to your Web server's documentation.
Actions can pass information about users to other applications in the same or a different policy domain.Table 6-3 provides examples of how to use actions.
Table 6-3 Using Actions to Pass Information to Other Applications
| Task | Example |
|---|---|
|
Personalizing the end-user's interaction with the receiving application |
You can use an action to send the user's name to a downstream application. The application could use the name to greet the user with a personalized message when the user logs in. |
|
Passing information in a header variable |
You can use a header variable: For SSO to work, the target application must be able to use the variable. |
|
Redirecting users to a specific URL upon failure or success of the attempt to authorize |
You can use redirection to send the user to another location. For example, you can redirect the user to your portal page following authorization |
Different actions are returned, depending on the result of the authorization expression and the rule or rules that were decisive in producing the definitive result. The Access Server returns the actions for the results of the definitive rules—the final definitive rule and those of the rules that led up to it. It determines the actions to return based on the following considerations:
If the result of an authorization expression is Deny Access, the Authorization Failure actions for all of the definitive rules are returned.
For example, for the following compound complex authorization expression, the user qualifies for the Deny Access conditions of Rule 5, Rule 6, and Rule 7. The Authorization Failure actions are returned for all of these rules, but no actions for Rule 3 are returned.
(R5 AND R6) AND (R3 OR R7)
If the result of the authorization expression is Allow Access, the Authorization Success actions for the definitive rules are returned.
For example, for the following compound complex authorization expression, the user qualifies for the Allow Access conditions of Rule 1, Rule 2, and Rule 4. The Access Server returns the Authorization Success actions for Rule 1, Rule 2, and Rule 4, which are the definitive rules.
(R1 AND R2) AND (R4 OR R3)
Because Rule 4 is the final definitive rule, the Access Server stops evaluating the expression after it. It does not evaluate Rule 3 because it has no effect on the outcome.
You can combine the actions resulting from evaluation of two or more rules to produce a desired result. For example, the Authorization Success actions for Rule 1 and Rule 2 in the following expression are combined to present a personalized greeting to the user for authorized users.
Rule 1 AND Rule 2 OR Rule 3
Here is how the actions for the rules are specified:
For Rule 1, the Authorization Success action directs the Access Server to return the user's cn in the HTTP_CN header variable.
For Rule 2, the Authorization Success action directs the Access Server to return the text 'Hello' in the header variable HTTP_GREETING.
For example, Sonal qualifies for both rules of the compound condition of the expression. She is a member of the marketing department group and the IP address of her computer is 192.168.2.123. Because she was successfully authorized as a result of evaluation of the expression, Sonal is presented with a personalized greeting when she logs into the downstream application, the resource she requested.
When you set actions in the default authorization policy and in specific policies for a policy domain, the action that is applied to a user depends on what policy is enforced. For example, suppose that you define three policies in a policy domain:
Policy 1
Policy 2
Policy 3
Each policy is checked in order, from top to bottom. If the third policy listed in the domain is the one that is enforced, the actions (for example, header variables) are taken from Policy 3. If you want to ensure that a particular action is always used, add the action to each policy in the policy domain.
Adding an action to multiple policies should not cause the action to be returned more than once. The topic of returning the same action multiple times is covered in "About Duplicate Actions".
Following discussions provide procedures to work with authorization actions:
Use the Actions feature to define an authorization rule's actions for responding to authorization success and authorization failure results. An action returns a specific value, such as the value of an attribute.
Actions you specify correspond with access conditions in the following way:
Authorization success actions apply to Allow Access conditions.
Authorization failure actions apply to Deny Access conditions.
To create an action for an authorization rule
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain containing the authorization rule whose actions you want to set.
Select the Authorization Rules tab.
A page appears listing the authorization rules for the policy domain.
|
Note: If you are just now creating a policy domain, you do not see any authorization rules. |
Select the authorization rule for which you want to set actions.
Click Actions.
Click Add.
For each of the following conditions, configure the actions to be taken—the RedirectURL and the user information to be returned:
Authorization Success
Authorization Failure
Click Save.
If you have disjoint domains, you need to configure an authorization scheme that enables searches for users with identical user IDs who reside in disjoint domains.
To configure an authentication scheme for disjoint domains
In the action that you define upon success, you need to set the following values:
Type: HEADERVAR
Name: HTTP_OBLIX_UID
Return Attribute: obuniqueid
|
Note: This must be done for both the default identity and access policy domains. |
In addition you need to make the following configuration file changes:
In the following file:
PolicyManager_install_dir/access/oblix/apps/common/bin/globalparams.xml
change the value of whichAttrIsLogin to ObUniqueID
Make the same change in the following file:
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xm
You can define actions for three kinds of results of evaluation of an authorization expression: authorization success, authorization failure, and inconclusive results of the expression evaluation.
To create an action for an authorization expression
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain that the authorization expression whose actions you want to set belongs to.
Select Default Rules.
Select the Authorization Expression tab.
Click Actions.
Click Add.
For each of the following conditions, configure the actions to be taken depending on the result of evaluation of the expression (that is, the RedirectURL to use and the user information to return):
Authorization Success
Authorization Failure
Authorization Inconclusive
Click Save.
An inconclusive result can be returned for an authorization expression under the following two conditions:
The user qualified for conflicting Allow Access and Deny Access rules.
The user did not qualify for any rules of the expression.
For information about the status codes the Access Server returns when an expression is evaluated to a result of inconclusive, see "Status Codes for an Inconclusive Result".
Because an authorization rule can be reused within an authorization expression, it is possible that evaluation of each instance of the authorization rule producing the same result can cause the Access Server to return the same action more than once.
It is also possible that different rules of an expression could return the same actions. Conflict can occur when, as a result of evaluation of the expression, two or more rules contributing to the definitive result produce the same actions. (See "About Evaluation of the Rules of an Expression" for an explanation of the definitive result.)
For example, if the action of one rule is to set the HTTP_GREETING variable text string, and the action of another rule is to set the variable to a different value, a conflict occurs if the actions of both rules are returned. Because HTTP_GREETING can be set to only one text string, the Access Server must determine which one to use.
For all cases except RedirectURLs, you can set an option that determines how the Access Server should handle duplicate actions.
|
WARNING: For RedirectURL, the Access Server always returns the last URL it encounters. You cannot override this behavior. |
How the Access Server handles duplicate actions is defined by a system default setting, which you can configure. However, you can override the system default behavior for the individual authorization expressions of policy domains and policies. Here are the three behaviors from which you can choose:
Duplicate—If you choose this option, the Access Server appends each new value it encounters to the information it returns to the application requesting authorization for the user. (The Access Server does not check for duplicate information.) Select this option if the application expects to receive information for all instances of the action. In this case, the application must process the values of all duplicate actions returned to it. Use of this option may incur performance issues.
Ignore Duplicate—If you choose this option, the Access Server removes all duplicate actions, and only the first instance of the action is returned to the application requesting authorization for the user. Each time an action value is added, the Access Server checks existing values to determine if the new action duplicates an existing one. If the Access Server finds one, it does not add the new value to those it returns to the application. In this case, any information inherent to the value of the repeated action is lost.
Because the Access Server must check for duplicate actions, use of this option may incur performance costs.
Override—If you choose this option, only the value of the last instance of the action is returned. Each new value overwrites the previous one, and previous values are lost. Do not select this option if the application requesting the authorization expects the results of all duplicate actions. This option is the most efficient one.
The ability to process duplicate actions applies to AccessGates only. The Access Server sends to the WebGate the actions as specified by the duplicate actions policy—whether Duplicate, Ignore Duplicate, or Override. However, the WebGate supports only a single value for a header variable. Although it receives the duplicate actions, the WebGate overrides duplicates so that the last value set for the header variable is used. Values set for the same header variable by previous actions are lost.
You can specify a system default setting for how the Access Server should handle duplicate actions, if any occur. By default, the system setting applies to handling of duplicate actions resulting from evaluation of all authorization expressions under control of the Access Server. However, you can override it for an individual authorization expression.
To set the system default duplicate actions behavior for the Access Server
Launch the Access System, select the Access System Console, and select Access System Configuration.
Select Common Information Configuration.
Click Duplicate Actions.
Select the radio button to set the duplicate action behavior: Duplicate, Ignore, or Override.
Click Save.
Restart the server for the duplicate actions policy change to take effect.
For each authorization expression, you can specify how you want the Access Server to handle duplicate actions if any occur as result of evaluation of the expression. By setting the authorization expression's Duplicate Actions value, you override the system default Duplicate Actions behavior.
To set the behavior for handling duplicate actions for an expression
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain that the authorization expression belongs to.
Select Default Rules.
A page appears listing the default rules and the authorization expression for the policy domain.
Select the Authorization Expression tab.
Click Duplicate Actions.
The Duplicate Action Headers page appears.
Select the radio button for the duplicate actions behavior for the expression: Duplicate, Ignore, or Override.
You can specify customized actions to be performed following successful authorization of a user or failure to authorize the user. Implementing a custom action requires an authorization plug-in. When defining a customized action:
Authorization success actions apply to Allow Access conditions.
Authorization failure actions apply to Deny Access conditions.
Refer to the Oracle Access Manager Developer Guide for details on creating a plug-in. For information about actions, see "Authorization Actions".
Launch the Access System, select the Policy Manager, and select My Policy Domains.
Select the policy domain that the authorization rule belongs to.
Select the Authorization Rules tab.
A page appears listing the authorization rules for the policy domain.
If you are creating a policy domain, you do not see any configured authorization rules.
Select the authorization rule for which you want to set custom actions.
Click Custom Actions.
You are not able to select Custom Actions unless at least one authorization plug-in has been defined.
Click Add.
Enter the information for the custom action to be taken following successful authorization of a user or failure to authorize the user.
Click Save.
|
Note: You can define multiple custom actions for Authorization Success or Authorization Failure. |
You can create authorization schemes for custom plug-ins that perform authorization tasks. You must be a Master Access Administrator to create and manage authorization schemes. After you create an authorization scheme, a Delegated Access Administrator can include the scheme in an authorization rule.
The Access System provides a default authorization scheme called Oracle Authorization Scheme that you can use for any authorization rules you create. However, you can create custom authorization schemes that include custom plug-ins used to perform different or additional tasks from those of the default scheme. After you create a custom authorization scheme, Delegated Access Administrators can include the plug-in in an authorization rule.
The Access System supports writing authorization plug-ins in C and any language supported by the Microsoft .NET framework, including C, C++, and Visual Basic. For details about managed code for authorization plug-ins, see the Oracle Access Manager Developer Guide.
A custom authorization plug-in is a shared library (.dll or .so) that the Access Server uses to make outbound calls to external business logic for determining user authorization privileges and actions.
You can write a custom plug-in for any purpose. For example, you may want to look up a user's bank balance from a mainframe application to determine authorization privileges.
In some cases, the plug-in may pass authorization actions in addition to other parameters. The types of information a custom plug-in can pass are the same as those you can configure for an authorization rule. They are:
User profile attributes
Configuration parameters, required or optional
Context-specific information, such as HTTP header information
Task overview: Providing customized authorization plug-ins
Write the custom authorization plug-in.
See the Oracle Access Manager Developer Guide for details.
An Oracle Access Manager developer at your organization writes the custom authorization plug-in using the authorization plug-in application programming interface (API). The authorization plug-in API enables the Access Server to call external business logic to determine if a user is authorized to access a resource.
A Master Access Administrator configures an authorization scheme for each custom plug-in you want to use. See "Authorization Schemes for Custom Plug-Ins".
The scheme specifies information about the custom plug-in such as the location of the plug-in and the parameters it takes.
A Delegated Access Administrator with management rights for the policy domain can include the authorization scheme in an authorization rule. The authorization rule can then be included in one or more authorization expressions for a policy domain or any of its policies.
|
Note: A custom plug-in for authorization must be installed on each application server you want to protect. |
This section includes the following sections which describe how to create and configure an authorization scheme for custom plug-ins.
To create an authorization scheme, you use the Authorization Management feature in the Access System Configuration component of the Access System Console. When you create a scheme, you enter information to be passed to the shared library in the User Parameter, Required Parameter, and Optional Parameter fields. You also specify one or more custom plug-ins in an authorization scheme.
When you specify a shared library for your plug-in, you can enter a complete path or a relative path to the plug-in. A relative path is evaluated with regard to the Access Server's installation directory.
For example:
lib/myplug_in
is evaluated as
AccesServer_install_dir/access/oblixaccess/oblix/lib/my_plug_in
For information on how to create shared libraries, see the Oracle Access Manager Developer Guide.
User parameters are user attributes that are passed to the shared library when the authorization scheme is invoked.
By default, the user's DN (distinguished name) and IP address are passed to the shared library. You cannot change this setting. However, you can select other attributes to help identify the user requesting the protected resource.
All parameters are name-value pairs. Required parameters for a plug-in are configured by the Master Access Administrator. Parameters can be passed at the authorization scheme level or at the rule level.
If you pass the parameter name-value pair at the authorization scheme level, it cannot be overridden at the rule level.
When a Delegated Access Administrator configures an authorization rule using the plug-in, he or she must provide values in the rule for each required parameter not supplied at the scheme level. The parameters are then passed to the plug-in at runtime.
If you do not pass a required parameter name-value pair at the scheme level, you must provide it at the rule level.
Optional parameters help to define more fully the behavior of a plug-in. Optional parameters for a plug-in are configured by the Master Access Administrator. When a Delegated Access Administrator configures an authorization rule that uses the plug-in, he or she can choose to provide a name-value pair for each of these parameters. If optional parameters are specified, they are passed to the plug-in at runtime.
For example, suppose a user allowed to access a bank account wants to withdraw more money than exists in the account. The optional parameters may specify that this account does not include overdraft protection and it may deny the user's request.
You may want to view the contents and definition of existing authorization schemes before you create new ones.
To view configured authorization schemes
Launch the Access System and select Access System Console, select Access System Configuration, and then select Authorization Management.
The Authorization Management: List all authorization schemes screen appears.
Click the link for the scheme you want to view.
The Details for Authorization Scheme page appears with the scheme's settings.
If the existing authorization scheme does not meet your requirements, you may want to create a new one. In this case, as described in the previous sections, custom plug-ins must be available for the new scheme. Only a Master Access Administrator can create authorization schemes.
To create an authorization scheme
Launch the Access System and select Access System Console, select Access System Configuration, then select Authorization Management.
The Authorization Management: List all authorization schemes page appears.
Click Add.
The Define a new authorization scheme page appears.
In the Name field, type the name of the authorization scheme.
In the Description field, type a brief description of the scheme.
For the Plugin is managed code entry, if you are developing the plug-in using managed code, select Yes.
In the Managed Code Name Space field, enter the name space if you are using managed code. (If not, leave this field blank.)
In the Shared Library field, type the full path to the plug-in file or a path relative to the Access Server's installation directory without specifying the file extension.
In the User Parameter field, type the LDAP attributes to be passed to the plug-in.
To pass context-specific data such as HTTP header variables to the plug-in, see "Retrieving External Data for an Authorization Request".
In the Required Parameter field, type the name and value of parameters the policy domain authorization rule must send to the plug-in.
If you specify the value for a parameter here, end users cannot change the value.
In the Optional Parameter field, type the name and value of parameters the policy domain authorization rules may send to the plug-in.
If you specify the value for a parameter here, end users cannot change the value.
For the User Parameter, Required Parameter, and Optional Parameter fields, click the plus (+) or minus (-) symbols to add or delete fields.
Click Save.
A Master Access Administrator is the only one who can modify an authorization scheme.
To modify an authorization scheme
Launch the Access System select Access System Console, select Access System Configuration, then select Authorization Management.
The Authorization Management: List all authorization schemes page appears.
Click the link for the scheme you want to modify.
The Details for Authorization Scheme screen appears.
Click Modify.
The Modify Authorization Scheme screen appears.
Modify the parameters as necessary.
Click Save.
A Master Access Administrator is the only one who can delete an authorization scheme.
To delete an authorization scheme
Launch the Access System and select Access System Console, select Access System Configuration, then select Authorization Management.
The Authorization Management: List all authorization schemes page appears.
Select the scheme you want to delete.
Click Delete.
Click OK to confirm your decision.
An audit rule causes event-based data to be written to the audit log file. As a Master Access Administrator, you must create a Master Audit Rule in the Access System Console. As a Delegated Access Administrator, you can derive audit rules from the Master Audit Rule for your policy domains and policies, but you cannot create an alternative Master Audit Rule.
There is one audit log for each Access Server. You can configure the size of the audit log file and the rotation interval for a server. Depending on events, the audit log may contain some duplicate audit entries.
Different information is written to the audit log depending on whether the user was authorized to use the requested resource.
For authorization failure, if information for a user does not exist in the directory, the Access Server denies the user access to a resource. In this case, the cn attribute is written in the log entry. No other attributes are written, because none are available. Because there is not an entry for the user, attributes such as givenname have no meaning. In this case, the user requesting access to a resource had not previously been authenticated.
You can define audit rules for a policy domain and its policies. Any audit rules you define must be derived from a Master Audit Rule. A Master Audit Rule must be created by a Master Access Administrator. Delegated Access Administrators can derive access rules from the Master Audit Rule, but they cannot create them.
For details explaining how to create and define these audit rules for policy domains and their policies, see the following sections in the policy domain chapter:
An authorization scheme can obtain data from an external source. This data is passed to a custom authorization plug-in. By obtaining external data (usually in the form of information about the user) authorization decisions can be made dynamically, based on user input. For example, if a user goes to a form to purchase an item for $1000, this $1000 amount can be dynamically evaluated against a limit—perhaps stored in a database—to determine if the purchase is authorized.
Oracle Access Manager obtains the external data using a "reverse action" in an authorization request. A reverse action refers to the process for obtaining data. Usually, when you use Oracle Access Manager, the data flows from the Access Server to the AccessGate or WebGate. In contrast, a reverse action sends data from the AccessGate or WebGate to the Access Server.
The reverse action feature can be used with WebGates and with custom AccessGates. For both cases, you must write a custom authorization plug-in. See the source code example that can be the basis for this plug-in:
Access_Server_install_dir\oblix\sdk\authorization\samples\ req_context.c
Note that when you configure the authorization scheme, you must supply a path and a name for the shared library that is created when the code is compiled. If you have Access Servers on different platforms that access this library, the path and the name must be identical on both servers.
See the Oracle Access Manager Developer Guide for details. In particular, refer to the information on the isAuthorized call for the ObUserSession class.
When writing a custom AccessGate that correctly handles a reverse action, error processing for this plug-in is as follows. If an isAuthorized call fails to pass required data to the authorization plug-in, the Access Manager SDK returns ObUser_ERR_NEED_MORE_DATA. In this case, the AccessGate can use the getAuthorizationParameters call in the ObResourseRequest structure to discover what data is required, gather the data, and reissue the isAuthorized call. The access_test_cplus program in the Access Manager SDK installation directory contains examples of these calls.
To retrieve external data for an authorization request
Create an authorization scheme as described in "Authorization Schemes for Custom Plug-Ins".
In the User Parameter field, enter the following:
RA_source$name
or
RA_name
where source is one of the following:
server
header
post
query
cookie
For information about the User parameter, see "User Parameters".
If you omit the value for source, sources are searched in the order shown in the list. Note that the Web server source (the server parameter) takes precedence over other sources. This prevents the request data, which is under control of the user, from overriding Web server data. For example, a remote_user cookie sent from a user does not override a remote_user variable sent by the Web server. The WebGate automatically extracts the requested data from the HTTP request.
If the custom client or AccessGate is created using the Access Manager SDK, it is up to the application program calling the Access Manager API to collect this data.
Create a custom authorization plug-in to process the external data sent by the WebGate or custom AccessGate and to return an authorization decision and optionally, action data.
Note that in the authorization scheme that you defined in this procedure, the RA prefix for the user parameter instructs the Access Server to go to the plug-in to make the external request.
Most browsers accept a number of standard headers in the HTTP requests that they send to servers. In this example, an authorization scheme uses the accept-language header, tells the WebGate to obtain the value of the header that is sent from the user's browser, and authorizes users if the browser language is set to en-us.
In the following example, the distributed example authorization plug-in named req_context compares the value in an incoming header against another value.
The req_context authorization plug-in is a general purpose plug-in to check external data, for example, HTTP headers retrieved by an authorization action that looks for external data. The plug-in compares the external data to specified values, either fixed values or user attribute values. A type parameter of "fixed" means that the data specified by the Name parameter is to be checked against the actual string in the Value parameter. A Type parameter of "attribute" means that the named external data is to be checked against the value of the user attribute specified in the Value parameter. In this example, a fixed value is used, however, the target value could be an attribute.
For example, the req_context plugin parameters for one authorization rule that allows only American English browsers could be specified as follows:
In this example, the value of the accept-language header is to be checked against the absolute (or fixed) value "en-us".
An authorization rule to allow only French browsers could specify the following:
You could use the req_context plug-in to check if the user's browser language matches a language configured for the user in an "expected-language" attribute in the user's directory entry, as follows:
As an alternative method for finding a fixed value, you also could write a special purpose plug-in that only checks for "en-us", in which case the only required parameter would be the user attribute "RA_accept-language".
|
Note: Note that if you try to test the scheme shown in the following procedure, retrieval of the accept-language header may be case-sensitive on some browsers. |
To configure a sample scheme to obtain external authorization data
In the Access System Console, create an authorization scheme named Browser Language:
Once you have defined the Browser Language authorization scheme, it appears in the list of schemes in the Authorization Management page. The details of the authorization scheme are as follows:
Note that the shared library is based on the sample code in the following plug-in:
oblix\sdk\authorization\samples\req_context.c
See "To retrieve external data for an authorization request" on page 6-50 for details. Note also that this scheme makes use of the RA_accept_language user parameter. In the required parameters for this scheme, the name accept-language is provided, with a type of fixed and no value.
In the Policy Manager, define a new policy domain.
The authorization rule in this policy domain looks for the language setting of the user's browser and authorizes the user if the browser language value is en-us, as follows:
Name: Browser language
Resource: http (/protected)
Authorization Rule Name: Browser Language English
Authorization Rule General: The authorization scheme (that was defined in the Access System Console) is Browser Language
Authorization Rule Plug-in Parameters: The profile attribute that is passed is RA_accept-language, and the value is en-us
The plug-in parameters for this policy domain appear as follows:
