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