10.3.3 Sample Access Gateway Authorization Policies

Sample Policies Based on Organizational Rules

Suppose that the company LDAP directory has the following organization:

ou=sales,o=acme
ou=dev,o=acme
ou=hr,o=acme

Suppose that this company has the following configuration and requirements:

Under each branch of the tree, the system administrator has created users who work in these departments.
Each department has its own web resources and other departments must be denied access to these resources.

With this type of configuration, you can use the LDAP context condition to create authorization policies or you can create role policies that are used in conjunction with authorization policies.

LDAP Context Policies

Create a policy that allows or denies access based on the LDAP context of the user’s DN. You can use the LDAP context of the user DN to group users based on their departments and then grant access based on the context match. You need to create protected resources for the web resources of the department, create a policy for each protected resource, and assign a policy to the protected resources.

Perform the following steps to configure a policy for the sales department:

Click Policies > Policies > New, specify a name for the policy, select Access Gateway: Authorization as the type, and click OK.
For Condition Group 1, click New, then select Credential Profile.
Specify the following details:

LDAP Credentials: Select LDAP User DN.

If/If Not: Select If Not.

Comparison: Select Contains Substring.

Mode: Select Case Insensitive.

Value: Select Data Entry Field and specify ou=sales,o=acme.

Result on Condition Error: Select True.
In the Actions section, select Deny.

Your policy must look similar to the following:

The following are the results of this configuration:
- When a user does not belong to the sales department, the user is denied access.
- When a user belongs to the sales department, the user is granted access.
- When an error occurs evaluating the conditions in the rule, the user is denied access.
Assign the policy to the protected web resources of the sales department. See Assigning an Authorization Policy to a Protected Resource.
Repeat the steps for other two departments and specify the appropriate department in Value.

Role Policies with Authorization Policies

Because of the company’s organization, you need to create three role policies for the following users:

Sales users
Development users
Human resource users.

You can then use these roles as conditions in authorization policies to allow and deny access. The first time you use roles in an authorization policy, there is extra setup because you must create the role policies. However, after the role policies are created, you can use them in multiple authorization policies.

For information about how to create the Sales role, see Creating a Role by Using the Location of the User Objects.

You need to decide on the type of Authorization policy you want to create. For example, you can create a Deny policy that denies access to everyone who does not match the condition (in this case, the Sales role). Alternatively, you can create a two-rule policy that allows access to everyone that matches the condition.

The first rule grants access to everyone who has the Sales role, and the second rule denies access to everyone who did not match the conditions of the first rule. (Other methods are also possible.) Because the proposed Deny policy is very similar to the LDAP Context Policies example, the following procedures explain how to create the two-rule policy:

Click Policies > Policies > New.
Specify a name for the policy, select Access Gateway: Authorization as the type, then click OK.
(Optional) Provide a description for the rule.
In Condition Group 1, click New, and select Roles.
Specify the following details:

If/If Not: Select If.

Roles: Select [Current].

Comparison: Select String: Equals.

Mode: Select Case Insensitive

Value: Select Roles, then select Sales.

Result on Condition Error: Select False.
Under Actions, select Permit, then click OK.

These steps create the Permit rule and set up the condition so that the following occurs:
- When the user does not match the condition because the user does not belong to the Sales role, the policy engine moves to the next rule in the policy.
- When the user does match the condition because the user belongs to the Sales role, the user is granted access.
- If an error occurs when evaluating the condition of the policy, the user does not match the condition and the policy engine moves to the next rule in the policy.
In the Rule List, click New.

This second rule is for denying access to everyone who does not match the condition in Rule 1. Processing of the policy stops when a user matches a rule; therefore all users who match Rule 1 are granted access and the policy engine does not evaluate the second rule.
Set the Priority to be 2 or greater.

You want the Permit rule to be processed first, so it must have a priority of 1. The Deny rule needs to be processed last, so it needs a lower priority than the Permit rule.
Leave the Condition Group 1 empty.

The Conditions section is left empty so that everyone who does not match the conditions of the Permit rule is denied access to the resource.
In the Actions section, select Deny and either accept the default action or select one of the other actions.
Click OK twice.
Click Apply Changes on the Policies page.
Assign the policy to the protected web resources of the sales department (see Assigning an Authorization Policy to a Protected Resource).

Sample Workflow Policy

One of the common workflow problems that an Authorization policy can solve is what to do with users who are denied access to resource. Most of the time they have a legitimate reason for trying to access the resource and need contact information to request access to the resource. You can add this contact information to a web page and redirect the users to this page when the policy denies the user access.

To create such a workflow, you need to create an HTML page with the necessary information for making the request for access. It can be as simple as a contact name or it can be an actual form that the user submits to the organization that controls access to the resource.

You then need to create an Authorization policy that redirects the denied users to this page. The following sample policy uses a role for Access condition, but the same workflow can be created using any of the other conditions available for an Authorization policy. For this example, assume that the user is granted a Master role if the user is a member of the Master group. The organization that controls access to the resource is the owner of the Master group and can add and delete members from the group. When the owner of the Master group receives a request for access to the resource, the owner can evaluate the user, and if the user meets their standards, the owner adds the user to the Master group.

You can use the Master group to create an Access Manager Role policy.

This policy for the Master role must look similar to the following:

This rule grants a user the Master role if the user belongs to the cn=Master,o=novell LDAP group. If the user does not belong to this group or if an error occurs trying to get the data, the user is not assigned the role. This occurs because both the condition and Result on Condition Error evaluate to false, which prevents the Action from being applied. After creating the Role policy, apply the changes and enable the Role for Identity Server.

You can then use this role to create an Authorization policy containing two rules. The first rule grants access to users with the Master role (and are therefore members of the Master group). This rule must look similar to the following:

This rule allows users with the Master role to access the resource. If the user does not match the condition or if an error occurs accessing the user’s role information, the user is sent to the next rule because both the condition and the Result on Condition Error evaluate to False.

The second rule in the policy must deny access to those who are not assigned the Master role and must redirect them to the page where they can request access. Create a rule that checks to see if they are assigned the Master role. In this type of rule, the condition needs to be an If Not condition.

With an If Not condition, the condition evaluates to True when a user does not match the condition. With such a rule, you want Result on Condition Error to also evaluate to True. If an error occurs obtaining role information for the user, the rule must not assume that the user had the Master role. The rule needs to assume that the user had no roles. You want the error condition to evaluate to True. Because the condition evaluated to True, the Action is applied to the user. The value specified in Redirect to URL must specify the page that contains the information about how to request access.

This redirect rule can be the only rule in the policy, because the users who are assigned to the Master role do not match the rule and are allowed access.

If you create the first rule to grant users with the Master role access, use a general Deny rule as the second rule.

A general Deny rule has no conditions, so it matches everyone that does not match the first rule in the policy. You can add more rules to this policy so that not all users are redirected to the site that contains the information about how to request access. For this type of policy, the last rule would be a general Deny rule with no conditions and without a redirect. The rules between Rule 1, which granted access to people assigned to the Master role, and the last rule, which denies everyone, must be rules that identify the types of users who have legitimate reasons for requesting access, and these rules must contain the redirect action.

After you save the Authorization policy, you need to assign it to the protected resource or resources that require the Master role, then update Access Gateway.