28.6 Sample Policies

The following samples are provided so you can comprehend the variety of ways you can use the conditions to control access. The biggest difference between a J2EE Agent Authorization policy and an Access Gateway Authorization policy is that an Access Gateway Authorization policy allows a redirect action. J2EE Agent Authorization policies allow only a deny or permit action.

28.6.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. The policy can be created as an Access Gateway Authorization policy and as a J2EE Agent Authorization policy:

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 > 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 Section 13.4.3, Assigning an Authorization Policy to a Protected Resource).

  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 Section 27.3.2, Creating a Role 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 Access Manager > 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 for Current User.

  5. Fill in the following fields:

    If/If Not: Select If.

    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 Section 13.4.3, Assigning an Authorization Policy to a Protected Resource).

28.6.2 Sample Workflow Policy

This sample policy can only be created as an Access Gateway Authorization policy because it relies on a redirect action.

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, let’s 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 28-8 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 28-9 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 28-10 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 28-11 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.

28.6.3 Sample Date and Time Policy

If you have an application or data that is highly sensitive, you might want to limit access so that it is only available during core work hours, for example Monday through Friday from 8:00 a.m. to 5:00 p.m. This type of policy can be created as either an Access Gateway Authorization policy or as a J2EE Agent Authorization policy.

The policy requires the use of the Current Day of Week and the Current Time of Day conditions.

The first rule in the policy has its priority set to 1, adds both conditions to Condition Group 1, uses a comparison type of In Range, and selects Data Entry Field for the value. Such a rule looks similar to the following:

Figure 28-12 Day and Time Policy Rule

You might need to add user conditions to this rule, if you don’t want all authenticated users to have access to the resource. Figure 28-13 shows a condition added to the rule that requires users to have the security_level_1 role.

Figure 28-13 Day and Time Rule with a Role Condition

You can add multiple condition groups, each with the Current Day of Week and Current Time of Day conditions, and each with a different user condition that must be met to permit access. The rule is configured so that a user must match all the conditions in a Condition Group. The Condition Groups are ORed, so the user needs to match the conditions in only one Condition Group for a match.

The rule can be configured to OR conditions and AND groups. In this type of rule, the user must match at least one condition in each Condition Group. With this configuration, the rule looks similar to the following.

Figure 28-14 A Rule with Multiple ANDed Condition Groups

All users must match the conditions in Condition Group 1 and 2, but only one of the conditions in Condition Group 3.

If the user does not match conditions in Rule 1, the next rule in the policy is evaluated. You need to add a general deny rule set to a lower priority. A general deny rule has no conditions, and the action is set to deny. Thus all users who do not match Rule 1 match this rule and are denied access.

28.6.4 Controlling Access Based on IP Addresses and Roles

In this scenario, the company has multiple offices. Headquarters are in New York, and you want users at this office to authenticate using a username/password contract before accessing the corporate site. The users at branch offices need to use a smart card to authenticate before accessing the corporate site.

To create such a configuration, you need to create Web pages, an Access Gateway Authorization policy, protected resources, and a smart card contract.

Web Pages

You need three Web pages:

  • Initial Access URL: The content of this page isn’t important. No one should ever see the page, but it should exist and should probably contain a warning that if you see this page, you should call the help desk.

  • Outside Headquarters Redirect URL: This page needs to contain a redirect to the corporate site.

  • Corporate Site: This should be the main page of your site, with links to the resources your users need.

Protected Resources

You need three protected resources with the following policy or contracts:

  • Initial Access URL: With the Redirect policy, but no contract.

  • Outside Headquarters Redirect URL: A smart card contract.

  • Corporate Site: A username/password contract. The username/password contract needs to be configured so that it is satisfied by a contract of equal or higher value. If you set the username/password contract to an Authentication level of 1 and the smart card contract to an Authentication level of 2, the smart card contract is at a higher level and therefore satisfies the requirements of the username/password contract.

Characteristics of Rule 1

The first Web page needs to be a URL that all users specify to access the corporate site. This page needs to be protected by an Authorization policy with at least four rules. You need to configure Rule 1 to have the following conditions, actions, and characteristics:

Characteristics

User Experience

Condition Group 1 sets the following:

  • Uses the Roles for Current User condition to match users who do not have the authenticated role.

  • Uses the Client IP condition to match the users who have an IP address from the New York office.

The Action is set to Redirect with a URL to the corporate site that is protected by a username/password contract.

The priority of the Rule is set to 1.

The rule description indicates that this rule redirects the New York users.

A New York user, who is unauthenticated, sees the redirect, is prompted for a username and password, then is granted access to the corporate site.

Figure 28-15 Rule 1 with the Conditions for the New York Office

In Rule 1, the Roles for Current User condition is set to be an If Not condition so that users who are not authenticated match this condition. The second condition, Client IP, is an And If condition, because the IP address of the user needs to match a value in the Data Entry Field.

Characteristics of Rule 2

You need to configure Rule 2 to have the following conditions, actions, and other characteristics:

Characteristics

User Experience

Condition Group 1 sets the following:

  • Uses the Roles for Current User condition to match users who do not have the authenticated role.

  • Uses the Client IP condition to match users who do not have an IP address from the New York office.

The Action is set to Redirect with a URL to the resource protected by a smart card contract.

The priority of the Rule is set to 2.

The rule description indicates that this rule redirects non-headquarter users.

A user, who is at a branch office and is unauthenticated, sees the redirect, is prompted for smart card credentials, and then is granted access to the resource.

The page redirects the user to the corporate site.

Figure 28-16 Rule 2 with Conditions for the Branch Office Users

In Rule 2, both conditions are configured to be If Not conditions. Users match the conditions when they are not authenticated and when they do not have a corporate IP address.

Characteristics of Rule 3

You need to configure Rule 3 to have the following conditions, actions, and other characteristics:

Characteristics

User Experience

Condition Group 1 sets the Roles for Current User condition to check for the authenticated role.

The Action is set to Redirect with a URL to the corporate site.

The priority of the Rule is set to 3.

The rule description indicates that this rule redirects authenticated users.

The authenticated user is automatically granted rights to the corporate site if the contract that was used for authentication can satisfy the requirements of the username/password contract.

Figure 28-17 Rule 3 for Already Authenticated Users

If your branch office users have a method of getting to the Identity Server and logging in with a username/password instead of a smart card contract, you need to modify Rule 3 to accommodate this situation. You need to create two Condition Groups. The first one checks for the authenticated role and the IP address of a corporate user. The second condition group checks for the authenticated role, the IP address of a branch office user, and for the smart card authentication contract. If the user matches either of these Condition Groups, the user is redirected to the corporate site. You need to add another rule to redirect the authenticated branch office users who authenticated with the username/password contract. This rule needs to redirect these users to the site that requires a smart card authentication. This can be the same URL you used for Rule 2.

Characteristics of Rule 4

You need to configure Rule 4 to have the following conditions, actions, and other characteristics:

Characteristics

User Experience

No conditions are specified.

The Action is set to Deny.

The priority of the Rule is set to 10.

The rule description indicates that this rule is a general deny rule.

If the user does not match Rule 1 through 3, the user is denied access.

Figure 28-18 Rule 4 with a Deny Message

The deny message in Rule 4 can contain plain text or text with HTML tags.

Other Considerations

If you want to control which resources users are allowed access based on the contract the user used for authentication, you can use the Contract condition to create a Role policy. The role, which is assigned when the user authenticates, can then be used in Authorization policies to permit or deny access.

This scenario only works if your users have IP addresses. If your users are behind a forward proxy, you might want to consider using the X-Forwarded-For IP condition. The forward proxy fills in this HTTP header value. If you know the IP addresses of all the forward proxies at the branch offices, you can use this condition to configure the rules to redirect the users to the appropriate resource and contract for authentication.