A rule contains a service type and one or more actions with an appropriate value that, in effect, defines the intent of the policy. The service type defines the policy-enabled resource that is being protected. An action is the operation that can be performed on the resource; examples of web server actions are POST or GET. A value defines the permission for the action, for example, Allow or Deny. An example of an allowable action for a human resources service might be to change a home telephone number.
For some services, it is acceptable to define an action without resources.
By default, there are three OpenSSO Enterprise services enabled for policy protection. The following sections explain these policy-enabled service types and the actions that can be applied to each.
When assessing policy, deny rules always take precedence over allow rules. For example, if you have two policies for a given resource, one with a rule denying access and the other with a rule allowing access the result, provided that the conditions for both policies are met, is deny. Thus, it is recommended that deny policies be used with extreme caution as they may potentially lead to conflicts. For example, if explicit deny rules are used, policies that are assigned to a given user through different subject types (such as a role or group membership) may result in denied access to a resource. This is illustrated if there is a deny policy for a resource applicable to an Employee role and an allow policy for the same resource applicable to Manager role; policy decisions for users assigned both Employee and Manager roles would be denied. Typically, the policy should use allow unless there are no policies to accomplish the deny case.
One way to resolve this issue is to design policies using Condition plug-ins. In the example, 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 to differentiate subjects. Another option is to use the Authentication Level condition stipulating that subjects with the Manager role authenticate at a higher authentication level.
Discovery Service (with resource name) allows administrators to create and manage policies corresponding to the LOOKUP and UPDATE actions that can be performed on the Discovery Service.
LOOKUP
Allow: Enables access to the resource defined in the Rule.
Deny: Denies access to the resource defined in the Rule.
UPDATE
Allow: Enables access to the resource defined in the Rule.
Deny: Denies access to the resource defined in the Rule.
Liberty Personal Profile Service (with resource name) allows administrators to create and manage policies corresponding to the MODIFY and QUERY actions that can be performed on the Liberty Personal Profile Service.
MODIFY
Interact for Value: Invokes the Liberty Alliance Project Interaction protocol for a value on a resource.
Interact for Consent: Invokes the Liberty Alliance Project Interaction protocol for consent on a resource.
Allow: Enables access to the resource defined in the Rule.
Deny: Denies access to the resource defined in the Rule.
QUERY
Interact for Value: Invokes the Liberty Alliance Project Interaction protocol for a value on a resource.
Interact for Consent: Invokes the Liberty Alliance Project Interaction protocol for consent on a resource.
Allow: Enables access to the resource defined in the Rule.
Deny: Denies access to the resource defined in the Rule.
URL Policy Agent (with resource name) allows administrators to create and manage policies for policy agents that enforce decisions on http/http(s) URLs.