3.3 Sample Access Gateway Authorization Policies

3.3.1 Sample Policy Based on Organizational Rules

The following sections describe a scenario with an organizational division, then describe two types of policies that enforce the requirements of the scenario:

Company Scenario

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 the 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

With such an organization, you can create a policy that either 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 separate the users into 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.

The following procedure explains how to configure such a policy for the sales department.

  1. Click Policies > Policies > New, specify a name for the policy, select Access Gateway: Authorization as the type, then click OK.

  2. For Condition Group 1, click New, then select Credential Profile.

  3. Fill in the following fields:

    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. In the text box, type the following value:

    ou=sales,o=acme
    

    Result on Condition Error: Select True.

  4. In the Actions section, select Deny.

    Your policy should look similar to the following:

    LDAP Context Policy

    This sets up the condition so that the following occurs:

    • When the user does not belong to the sales department, the user is denied access.

    • When the 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.

  5. Assign the policy to the protected Web resources of the sales department (see Assigning an Authorization Policy to a Protected Resource in the Novell Access Manager 3.1 SP2 Access Gateway Guide).

  6. Repeat these steps for the other two departments, changing the Value field to match the appropriate department.

Role Policies with Authorization Policies

Because of the company’s organization, you need to create three role policies, one for the sales users, one for the development users, and one for the 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.

The following instructions explain how to use the Sales role to create a policy that controls access to a protected resource. For instructions on 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). Or 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.

  1. In the Administration Console, click Policies > Policies > New.

  2. Specify a name for the policy, select Access Gateway: Authorization as the type, then click OK.

  3. (Optional) Provide a description for the rule.

  4. In Condition Group 1, click New, and select Roles.

  5. Fill in the following fields:

    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.

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

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

  8. Set the Priority to be 2 or greater.

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

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

  10. In the Actions section, select Deny and either accept the default action or select one of the other actions.

  11. Click OK twice.

  12. Click Apply Changes on the Policies page.

  13. Assign the policy to the protected Web resources of the sales department (see Assigning an Authorization Policy to a Protected Resource in the Novell Access Manager 3.1 SP2 Access Gateway Guide).

3.3.2 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 the 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 should look similar to the following:

Figure 3-7 A Role Policy with an LDAP Group Condition

This rule grants the user the Master role if the user belongs to the cn=Master,o=novell LDAP group. If the user doesn’t 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 the 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 the Identity Server.

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

Figure 3-8 A Permit Rule with a Role Condition

This rule permits users who are assigned the Master role to have access to 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 should deny access to those who are not assigned the Master role and should redirect them to the page where they can request access. You can do this with 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.

Figure 3-9 A Deny Rule with a Redirect URL

With an If Not condition, the condition evaluates to True when the user does not match the condition. With such a rule, you want the Result on Condition Error to also evaluate to True. If there is an error obtaining role information for the user, you don’t want the rule to assume that the user had the Master role. You want the rule to assume that the user had no roles, or in other words, 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 the Redirect to URL text box should specify the page that contains the information on how to request access.

This redirect rule could be the only rule in the Authorization policy, because the users who are assigned to the Master role do not match the rule and are thus allowed access. Having the first rule that grants access because they have the Master role just makes the logic of the policy clearer.

If you create the first rule that grants users with the Master role access, you can use a general Deny rule for the second rule. It should look similar to the following.

Figure 3-10 A General Deny 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 to tighten security so that not all users are redirected to the site that contains the information on 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, should be rules that identify the types of users who have legitimate reasons for requesting access, and these rules should contain the redirect action.

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