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.
Defines authorization actions for the URL Policy Agent service. This is used to define policies that protect HTTP and HTTPS URLs. This is the most common use case of Access Manager policies.
Click Next.
Enter a name and resource name for the rule.
Currently, Access Manager Policy Agents only support http:// and https:// resources and do not support IP addresses in place of the hostname.
Wildcards are supported for protocol, host, port and resource name. For example:
http*://*:*/*.html |
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. Depending on the service type, you can select the following:
LOOKUP (Discovery Service)
UPDATE (Discovery Service)
MODIFY (Liberty Personal Profile Service)
QUERY (Liberty Personal Profile Service)
GET (URL Policy Agent)
POST (URL Policy Agent)
Select the Action Values.
Interaction for Consent — Invokes the Liberty interaction protocol for consent on a resource. This is for the Liberty Personal Profile service type only.
Interaction for Value — Invokes the Liberty interaction protocol for a value on a resource. This is for the Liberty Personal Profile service type only.
Allow — Enables you 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 in a policy. 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. Typically, the policy definition process should only use allow rules, and use the default deny when no policies apply to accomplish the deny case.
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.
Click Finish.