Sun OpenSSO Enterprise 8.0 Administration Guide

Policy

In OpenSSO Enterprise, a policy (referred to as a normal policy in previous releases) consists of rules, subjects, conditions, and response providers. A policy can be defined with either binary or non-binary decisions. A binary decision is yes/no, true/false or allow/deny. A non-binary decision represents the value of an attribute. For example, a mail service might include a mailboxQuota attribute with a maximum storage value set for each user. The following sections have more information on the components of a policy.

Rules

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.


Note –

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.


Tip –

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)

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.

Liberty Personal Profile Service (with resource name)

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.

URL Policy Agent (with resource name)

URL Policy Agent (with resource name) allows administrators to create and manage policies for policy agents that enforce decisions on http/http(s) URLs.

Subjects

A subject defines the user or collection of users (for instance, a group or those who possess a specific role) that the policy affects. The general rule for subjects is that the policy would apply only if the user is a member of at least one subject in the policy. The default subjects are:

Authenticated Users

This subject type implies that any user with a valid SSOToken is a member. Thus, all authenticated users are member of this Subject even if they have authenticated to a realm that is different from the one in which the policy is defined. This is useful if the resource owner would like to offer access to resources managed for users from other organizations. To restrict access to protected resources belonging to a specific organization, use the Organization subject.

OpenSSO Identity Subject

This subject type implies that the identities defined under the Subjects tab of a particular realm can be added as a member.

Web Services Clients

This subject type implies that a web services client (WSC) identified by a valid SSOToken is a member IF the Distinguished Name (DN) of any principal contained in the SSOToken matches any value of this subject. Valid values are the DNs of trusted certificates in a local Java keystore that correspond to the certificates of trusted WSCs. This subject type has dependency on the Liberty Alliance Project Web Services Framework and should be used to authorize WSCs only by service providers that implement it. Also, be sure to create the keystore before you add this Subject to a policy.

The following additional subjects are available by selecting them in the Policy Configuration Service of the realm. If you enable any of them, you should also change the values of the LDAP Bind DN and LDAP Bind Password attributes in the Policy Configuration Service of the realm to reflect valid credentials for the LDAP directory. Please note that cn=amldapuser,ou=DSAME Users and the top level suffix is not created in the default configuration directory.

LDAP Groups

This subject type implies that any member of an LDAP group is member of this subject.

LDAP Roles

This subject type implies that any member of an LDAP role is a member of this subject. An LDAP Role is any role definition that uses the Directory Server role capability. These roles have object classes mandated by Directory Server role definition. The LDAP Role Search filter can be modified in the Policy Configuration Service to narrow the scope and improve performance.


Note –

Nested roles can be evaluated correctly as LDAP Roles in the subject of a policy definition.


LDAP Users

This subject type implies that any LDAP user is a member of this subject.

OpenSSO Roles (Legacy Mode)

This subject type implies that any member of an OpenSSO Enterprise role is a member of this subject. An OpenSSO Enterprise role is created using OpenSSO Enterprise running in legacy mode with the AMSDK datastore and has object classes mandated by OpenSSO Enterprise. OpenSSO Roles can only be accessed through the hosting OpenSSO Enterprise Policy Service.

Organization

This subject type implies that any member of a realm is a member of this subject


Note –

All OpenSSO Roles can be used as Directory Server roles. However, all LDAP roles are not necessarily OpenSSO Enterprise roles. LDAP roles can be leveraged from an existing directory by configuring the Policy Configuration Service. OpenSSO Enterprise roles can only be accessed through the hosting OpenSSO Enterprise Policy Service. The LDAP Role Search filter can be modified in the Policy Configuration Service to narrow the scope and improve performance.


Conditions

A condition allows you to define constraints on the policy. For example, if you want to limit access to a paycheck application, you can define a condition specifying the hours; or, you may wish to define a condition that only grants access if the request originates from a given set of IP addresses or from a company intranet. For example, to configure http://org.example.com/hr/*.jsp so that it can only be accessed by users from org.example.com between 9 a.m. to 5 p.m., use an IP Condition along with a Time Condition. By specifying the rule resource as http://org.example.com/hr/*.jsp, the policy would apply to all the JSPs under http://org.example.com/hr including those in the sub directories. The default conditions are:

Active Session Time

Sets the condition based on user session data.

Max Session Time

Specifies the maximum duration to which the policy is applicable starting from when the session was initiated.

Terminate Session

If selected, the user session will be terminated if the session time exceeds the maximum allowed as defined in the Max Session Time field.

Authentication by Module Chain

The policy applies if the user has successfully authenticated to the authentication chain in the specified realm. If no realm is specified, authentication to any realm at the authentication chain will satisfy the condition.

Authentication by Module Instance

The policy applies if the user has successfully authenticated to the instantiated authentication module in the specified realm. If no realm is specified, authentication to any realm at the authentication module will satisfy the condition.

Authentication Level (greater than or equal to)

The policy applies if the user’s authentication level is greater than or equal to the Authentication Level set in the condition. This attribute indicates the level of trust for authentication within the specified realm.

Authentication Level (less than or equal to)

The policy applies if the user’s authentication level is less than or equal to the Authentication Level set in the condition. This attribute indicates the level of trust for authentication within the specified realm.

Current Session Properties

Decides whether a policy is applicable to the request based on values set in the user's OpenSSO Enterprise session. During policy evaluation, the condition returns true only if the user's session has every property value defined in the condition. For properties defined in the condition with multiple values, it is sufficient if the token has at least one value for the property.


Note –

Session properties set by OpenSSO are prefixed with am.protected to ensure that they cannot be edited by the Client SDK.


Identity Membership

Checks if the invocator uuid specified in the environment is a member of at least one AMIdentity object specified in the Condition. The uuid invocator is specified as the key value of Condition. INVOCATOR_PRINCIPAL_UUID in the environment parameter of the evaluation request. This is primarily used to apply authorization rules for WSC (Web Service Client). The identity of the WSC is passed as the value of uuid invocator.

IP Address/DNS Name

Sets the condition based on a range of IP Addresses. The fields you can define are:

IP Address From/To

Specifies the range of the IP address.

DNS Name

Specifies the DNS name. This field can be a fully qualified hostname or a string in one of the following formats:

domainname

*.domainname

LDAP Filter Condition

The policy is applicable when the defined LDAP filter locates the user entry in the LDAP directory that was specified in the Policy Configuration service. This is only applicable within the realm that the policy is defined.

Time (day, date, time, and timezone)

Sets the condition based on time constraints. The fields are:

Date From/To

Specifies the range of the date.

Time

Specifies the range of time within a day.

Day

Specifies a range of days.

Timezone

Specifies a timezone, either standard or custom. Custom timezones can only be a timezone ID recognized by Java (for example, PST). If no value is specified, the default value is the Timezone set in the OpenSSO Enterprise JVM.

If a request for access is negated as determined by the condition, an advice message can be produced to indicate why. Advice messages are propagated in the policy decision and sent to the policy agent which retrieves the advice and takes appropriate action — for example, redirecting the user to the Authentication Service to authenticate to a higher level. If, in this example, the user successfully authenticates to a higher level the policy might then become applicable. See com.sun.identity.policy in the Sun OpenSSO Enterprise 8.0 Java API Reference for more information.


Tip –

Custom conditions can also produce advices. However, the policy agents respond only for Auth Level Advice and Auth Scheme Advice. Custom agents can be written to respond to more advices and existing OpenSSO Enterprise policy agents can be extended to do the same. See the Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for J2EE Agents for more information.


Response Providers

Response providers are plug-ins that provide values, in the final policy decision, for particular attributes in the authorized user's profile. The attributes are sent with the policy decision to the policy agent which, in turn, passes them in headers to an application. The application typically uses these attributes for customizing pages such as a portal page. OpenSSO Enterprise includes one implementation of the com.sun.identity.policy.interfaces.ResponseProvider interface, the IDResponseProvider. Custom response providers can be implemented.