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.