If you have already created the policy, click the name of the policy for which you wish to add the rule. If not, see To Create a Normal Policy With the Access Manager Console.
Under the Rules menu, click New.
Select one of the following default service types for the rule. You may see a larger list if more services are enabled for the policy:
Defines the authorization actions for Discovery service query and modify protocol invocations by web services clients for a specified resource.
Defines the authorization actions for Liberty Personal Profile service query and modify protocol invocations by web services clients for a specified resource.
Provides the URL Policy Agent service for policy enforcement. This service allows administrators to create and manage policies through a policy enforcer or policy agent.
Enter a name and resource name for the rule.
Currently, Policy Agents only support http:// and https:// resources and do not support IP addresses in place of the hostname.
Wildcards are supported for host, port, and resource names. For example:
For the URL Policy Agent service, if a port number is not entered, the default port number is 80 for http://, and 443 for https://.
Select the action for the rule. If you are using the URL Policy Agent service, you can select the following:
Select the Action Values.
Allow — Enables you to access the resource matching the resource defined in the rule.
Deny — Denies access to the resource matching the resource defined in the rule.
Denial rules always take precedence over allow rules. For example, if you have two policies for a given resource, one denying access and the other allowing access, the result is a deny access (provided that the conditions for both policies are met). It is recommended that deny policies be used with extreme caution as they may lead to potential conflicts between the policies. The policy definition process should only use allow rules. If no policy is applicable to a resource, access is automatically denied.
If explicit deny rules are used, policies that are assigned to a given user through different subjects (such as role and/or group membership) may result in denied access to a resource even if one or more of the policies allow access. For example, if there is a deny policy for a resource applicable to an Employee role and there is another allow policy for the same resource applicable to Manager role, policy decisions for users assigned both Employee and Manager roles would be denied.
One way to resolve such problems is to design policies using Condition plug-ins. In the case above, a “role condition” that applies the deny policy to users authenticated to the Employee role and applies the allow policy to users authenticated to the Manager role helps differentiate the two policies. Another way could be to use the authentication level condition, where the Manager role authenticates at a higher authentication level.