Chapter 6 Policy Management

This chapter describes the Policy Management feature of Sun Java™ System Access Manager 6 2005Q1. Access Manager’s Policy Management feature provides a means for: the Top-level administrator or Top-level policy administrator to view, create, delete and modify policies for a specific service that can be used across all organizations. It also provides a way for an organization or suborganization administrator or policy administrator to view, create, delete and modify policies for specific use by the organization.

Overview

A policy defines rules that specify access privileges to an organization’s protected resources. Businesses posses resources, applications and services that they need to protect, manage and monitor. Policies control the access permissions and usage of these resources by defining when and how a user can perform an action on a given resource. A policy, when applied to an object, defines the resources that a particular object can access.


Note	An object is a principal. A principal can be an individual, a corporation, a role, or a group; anything that can have an identity. for more information, see the Java™ 2 Platform Standard Edition Javadocs.

A single policy can define 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. In general, a policy is configured to define what an object can do to which resource and under what conditions.

Policy Management Feature

The Policy Management feature provides a policy service for creating and managing policies. The policy service allows administrators to define, modify, grant, revoke and delete permissions to protect resources within the Access Manager deployment. Typically, a policy service includes a data store, a library of interfaces that allows for the creation, administration and evaluation of policies, and a policy enforcer or policy agent. Access Manager uses Sun Java System Directory Server for data storage, and provides Java and C APIs for policy evaluation and policy service customizaton. (see the Access Manager Developer’s Guide for more information) It also allows administrator to use the Access Manager console for policy management. Access Manager provides one policy service, the URL Policy Agent service, which uses downloadable policy agents to enforce the policies.

URL Policy Agent Service

Out of the box, Access Manager 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.

Policy Agents

The Policy Agent is the Policy Enforcement Point (PEP) for a server on which an enterprise’s resources are stored. The policy agent is installed separately from Access Manager onto a web server and serves as an additional authorization step when a user sends a request for a web resource that exists on the protected web server. This authorization is in addition to any user authorization request which the resource performs. The agent protects the web server, and in turn, the resource is protected by the authorization plug-in.

For example, a Human Resources web server protected by a remotely-installed Access Manager might have an agent installed on it. This agent would prevent personnel without the proper policy from viewing confidential salary information or other sensitive data. The policies are defined by the Access Manager administrator, stored within the Access Manager deployment and used by the policy agent to allow or deny users access to the remote web server’s content.


Note	Policy is evaluated in no particular order although as they are evaluated, if one action value evaluates to deny, subsequent policies are not evaluated, unless the Continue Evaluation On Deny Decision attribute is enabled in the Policy Configuration service. For more information, see Policy Configuration Service Attributes.

Policy agents enforce decisions only on web URLs (http://...). However, agents can be written using the Java and C Policy Evaluation APIs to enforce policy on other resources.

In addition, the Resource Comparator attribute in the Policy Configuration Service would also need to be changed from its default configuration to:

serviceType=Name_of_LDAPService|class=com.sun.identity.policy.plugins.SuffixResourceName|wildcard=*|delimiter=,|caseSensitive=false

Alternately, providing an implementation such as LDAPResourceName to implement com.sun.identity.policy.interfaces.ResourceName and configuring the Resource Comparator appropriately would also work.

The Policy Agent Process

The process for protected web resources begins when a web browser requests a URL that resides on a server protected by the policy agent. The server’s installed policy agent intercepts the request and checks for existing authentication credentials (a session token).

If the agent has intercepted a request and validated the existing session token, the following process is followed.


Note	The fields for the Resource Comparator attribute are explained in Policy Configuration Service Attributes.

If the session token is valid, the user is allowed or denied access. If the token is invalid, the user is redirected to the Authentication Service, as outlined in the following steps.

The Authentication Service verifies that the credentials are also valid and issues a token.

Once the user’s credentials are properly authenticated, the agent issues a request to the Naming Service which defines the URLs used to access Access Manager’s internal services.

The Naming Service returns locators for the policy service, and the agent sends a request to the Policy Service to get policy decisions applicable to the user.

Based on the policy decisions for the resource being accessed, the user is either allowed or denied access. If advice on the policy decision indicates a different authentication level or authentication mechanism, the agent redirects the request to the Authentication Service until all criteria is validated.

Assuming the agent has intercepted a request for which there is no existing session token, the agent redirects the user to their default login page even if the resource is protected using a different authentication method.


Note	Policy-based resource authorization and user authentication are separate types of authentication. More information on this can be found in Policy-Based Resource Management.

Policy Types

There are two types of policies that can be configured using Access Manager: a normal policy or a referral policy. A normal policy consists of rules, subjects and conditions. A referral policy consists of rules and referrals to organizations.

Normal Policy

In Access Manager, a policy that defines access permissions is referred to as a normal policy. A normal policy consists of rules, subjects and conditions.

Rules

A rule contains a resource, one or more actions, and a value. The rule, basically, defines the policy.

A resource defines the specific object that is being protected; for instance, an HTML page or a user’s salary information accessed using a human resources service.

An action is the name of an operation that can be performed on the resource; examples of web server actions are POST or GET. An allowable action for a human resources service might be to be able to change a home telephone number.

A value defines the permission for the action, for example, allow or deny.



Note	It is acceptable to define an action without resources.

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. Subjects are assigned to policies. 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

Access Manager Roles

LDAP Groups

LDAP Roles

LDAP Users

Organization

Web Services Client

Access Manager Roles Versus LDAP Roles

An Access Manager role is created using Access Manager. These roles have object classes mandated by Access Manager. 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. All Access Manager roles can be used as Directory Server roles. However, all Directory Server roles are not necessarily Access Manager roles. LDAP roles can be leveraged from an existing directory by configuring the Policy Configuration Service. Access Manager roles can only be accessed through the hosting Access Manager Policy Service. Evaluating membership in Access Manager roles will be faster as it accesses the Access Manager SDK and cache. The LDAP Role Search filter can be modified in the Policy Configuration Service to narrow the scope and improve performance.

Nested Roles

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

Conditions

A condition allows you to define constraints on the policy. For example, if you are defining policy for a paycheck application, you can define a condition on this action limiting access to the application only during specific hours. Or, you may wish to define a condition that only grants this action if the request originates from a given set of IP addresses or from a company intranet.

The condition might additionally be used to configure different policies on different URIs on the same domain. For example, http://org.example.com/hr/*jsp can only be accessed by org.example.net from 9am to 5 p.m., yet http://org.example.com/finance/*.jsp can be accessed by org.example2.net from 5 a.m. to 11 p.m. This can be achieved by using an IP Condition along with a Time Condition. And 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.

Policy Advices

If a policy is not applicable as determined by the condition, the condition can produce advice messages that indicates why the policy was not applicable to the request. These advice messages are propagated in the policy decision to the Policy Enforcement Point. The Policy Enforcement Point can retrieve this advice and try to take the appropriate action, such as redirecting the user back to the authentication mechanism to authenticate to a higher level. The user may then be prompted for higher level authentication and may be able to access to the resource, if the policy becomes applicable, after proper action for the advice is taken.


Note	The terms referral, rule, resource, subject, condition, action and value correspond to the elements Referral, Rule, ResourceName, Subject, Condition, Attribute and Value in the policy.dtd.

Only AuthLevelCondiiton and AuthSchemeCondition provide advices if the condition is not satisfied.

Custom conditions can also produce advices. However, the Access Manager Policy Agents respond only for Auth Level Advice and Auth Scheme Advice. Custom agents could be written to understand and respond to more advices and existing Access Manager agents can be extended to understand and respond to more advices. For more information, see the Policy Agents documentation at the following location:

Referral Policy

An administrator may need to delegate one organization’s policy definitions and decisions to another organization. (Alternatively, policy decisions for a resource can be delegated to other policy products.) A referral policy controls this policy delegation for both policy creation and evaluation. It consists of one or more rules and one or more referrals.

Rules

A rule defines the resource whose policy definition and evaluation is being referred.

Referrals

The referral defines the organization to which the policy evaluation is being referred. By default, there are two types of referrals: peer organization and suborganization. They delegate to an organization on the same level and an organization on a sub-level, respectively. See Creating Policies for Peer Organizations and Suborganizations for more information.


Note	The referred-to organization can define or evaluate policies only for those resources (or sub-resources) that have been referred to it. This restriction, however, does not apply to the root organization.

Policy Definition Type Document

Once a policy is created and configured, it is stored in Directory Server in XML. In Directory Server, the XML-encoded data is stored in one place. Although policy is defined and configured using the amAdmin.dtd (or the console), it is actually stored in Directory Server as XML that is based on the policy.dtd. The policy.dtd contains the policy element tags extracted from the amAdmin.dtd (without the policy creation tags). So, when the Policy Service loads policies from Directory Server, it parses the XML based on the policy.dtd. The amAdmin.dtd is only used when creating policy with the command line. This section describes the structure of policy.dtd. The policy.dtd exists in the following location:

Policy Element


Note	Throughout the rest of this chapter, only the Solaris directory information will be given. Please note that the directory structure for Linux is different.For more information, please see About This Guide.

Policy is the root element that defines the permissions or rules of a policy and to whom/what the rule applies or the subject. It also defines whether or not the policy is a referral (delegated) policy and whether there are any restrictions (or conditions) to the policy. It may contain one or more of the following sub-elements: Rule, Conditions, Subjects, or Referrals. The required XML attribute is name which specifies the name of the policy. The referralPolicy attribute identifies whether or not the policy is a referral policy; it defaults to a normal policy if not defined. Optional XML attributes include name and description.

Rule Element


Note	When tagging a policy as referral, subjects and conditions are ignored during policy evaluation. Conversely, when tagging a policy as normal, any Referrals are ignored during policy evaluation.

The Rule element defines the specifics of the policy and can take three sub-elements: ServiceName, ResourceName, or AttributeValuePair. It defines the type of service or application for which the policy has been created as well as the resource name and the actions which are performed on it. A rule can be defined without any actions; for example, a referral policy rule doesn't have any actions.

ServiceName Element


Note	It is acceptable to have a defined policy that does not include a defined ResourceName element.

The ServiceName element defines the name of the service to which the policy applies. This element represents the service type. It contains no other elements. The value is exactly as that defined in the service’s XML file (based on the sms.dtd). The XML service attribute for the ServiceName element is the name of the service (which takes a string value).

ResourceName Element

The ResourceName element defines the object that will be acted upon. The policy has been specifically configured to protect this object. It contains no other elements. The XML service attribute for the ResourceName element is the name of the object. Examples of a ResourceName might be http://www.sunone.com:8080/images on a web server or ldap://sunone.com:389/dc=example,dc=com on a directory server. A more specific resource might be salary://uid=jsmith,ou=people,dc=example,dc=com where the object being acted upon is the salary information of John Smith.

AttributeValuePair Element

The AttributeValuePair element defines an action and its values. It is used as a sub-element to Subject Element, Referral Element and Condition Element. It contains both the Attribute and Value elements and no XML service attributes.

Attribute Element

The Attribute element defines the name of the action. An action is an operation or event that is performed on a resource. POST or GET are actions performed on web server resources, READ or SEARCH are actions performed on directory server resources. The Attribute element must be paired with a Value element. The Attribute element itself contains no other elements. The XML service attribute for the Attribute element is the name of the action.

Value Element

The Value element defines the action values. Allow/deny or yes/no are examples of action values. Other action values can be either boolean, numeric, or strings. The values are defined in the service’s XML file (based on the sms.dtd). The Value element contains no other elements and it contains no XML service attributes.

Subjects Element


Caution	Deny rules always take precedence over allow rules. For example, if one policy denies access and another allows it, the result is a deny (provided all other conditions for both policies are met). It is recommended that deny policies be used with extreme caution as they can lead to potential conflicts. If explicit deny rules are used, policies assigned to a user through different subjects (such as role and/or group membership) may result in denied access. Typically, the policy definition process should only use allow rules. The default deny may be used when no other policies apply.

The Subjects sub-element identifies a collection of objects to which the policy applies; this overview collection is chosen based on membership in a group, ownership of a role or individual users. It takes the Subject sub-element. The XML attributes that can be defined are:

Subject Element

The Subject sub-element identifies a collection of objects to which the policy applies; this collection pinpoints more specific objects from the collection defined by the Subjects element. Membership can be based on roles, group membership or simply a listing of individual users. It contains a sub-element, the AttributeValuePair Element. The required XML attribute is type,which identifies a generic collection of objects from which the specifically defined subjects are taken. Other XML attributes include name which defines a name for the collection and includeType which defines whether the collection is as defined, for whether the policy applies to users who are NOT members of the subject.

Referrals Element


Note	When multiple subjects are defined, at least one of the subjects should apply to the user for the policy to apply. When a subject is defined using includeType set to false, the user should not be a member of that subject.

The Referrals sub-element identifies a collection of policy referrals. It takes the Referral sub-element. The XML attributes it can be defined with are name which defines a name for the collection and description which takes a description.

Referral Element

The Referral sub-element identifies a specific policy referral. It takes as a sub-element the AttributeValuePair Element. It’s required XML attribute is type which identifies a generic collection of assignments from which the specifically defined referrals are taken. It can also include the name attribute which defines a name for the collection.

Conditions Element

The Conditions sub-element identifies a collection of policy restrictions (time range, authentication level, et.al.). It must contain one or more of the Condition sub-element. The XML attributes it can be defined with are name which defines a name for the collection and description which takes a description.

Condition Element


Note	The conditions element is an optional element in a policy.

The Condition sub-element identifies a specific policy restriction (time range, authentication level, et.al.). It takes as a sub-element the AttributeValuePair Element. Its required XML attribute is type which identifies a generic collection of restrictions from which the specifically defined conditions are taken. It can also include the name attribute which defines a name for the collection.

Adding a Policy Service

By default, Access Manager provides the URL Policy Agent service (iPlanetAMWebAgentService). This service is defined in an XML file located in the following directory:

You can, however add additional policy services to Access Manager. Once the policy service is created, you add it to Access Manager through the amadmin command line utility.

To Add a New Policy Service

Develop the new policy service in an XML file based on the sms.dtd. Access Manager provides two policy service XML files that you may wish to use as the basis for the new policy service file:

amWebAgent.xml - This the the XML file for the default URL Policly Agent service. It is located in etc/opt/SUNWam/config/xml/.

SampleWebService.xml. - This is the sample policy service file located in /etc/opt/SUNWam/samples/policy.

Save the XML file to the directory from which you will load the new policy service. For example:

/etc/opt/SUNWam/config/xml/newPolicyService.xml

Load the new policy service with the amadmin command line utility. For example:

AccessManager-base/SUNWam/bin/amadmin

--runasdn “uid=amAdmin,ou=People,default_org,root_suffix

--password password

--schema /etc/opt/SUNWam/config/xml/newPolicyService.xml

After you load the new policy service, you can define rules for the policy definitions through the Access Manager console or by loading a new policy through amadmin.

Creating Policies

You can create, modify and delete policies through the Policy API and the Access Manager console, and create and delete policies through the amadmin command line tool. This section focuses on creating policies through the amadmin command line utility and through the Access Manager console. For more information on the Policy APIs, see the Access Manager Developer’s Guide.

Policies are generally created through and XML file and added to Access Manager through the amadmin command line utility and then managed through the Access Manager console (although policies can be created through the console). This is because policies cannot be modified using amadmin directly. To modify a policy, you must first delete the policy from Access Manager and the add the modified policy using amadmin.

In general, policy is created at the organization (or suborganization) level to be used throughout the organization’s tree.

Creating Policies With amadmin

Create the policy’s XML file based on the policy.dtd. This file is located in the following directory:

AccessManager-base/SUNWam/dtd

Once the policy’s XML file is developed, you can use the following command to load it:

AccessManager-base/SUNWam/bin/amadmin

--runasdn "uid=amAdmin,ou=People,default_org,root_suffix"

--password password

--data policy.xml

To add multiple policies simultaneously, place the policies in one XML file, as opposed to having one policy in each XML file. If you load policies with multiple XML files in quick succession, the internal policy index may become corrupted, and some policies may not participate in policy evaluation.

When creating policies through amadmin, ensure that the authentication module is registered with the organization while creating authentication scheme condition; that the corresponding LDAP objects (organizations, groups, roles and users) exist while creating organizations’, LDAP groups’, LDAP roles’ and LDAP users’ subjects; that Access Manager roles exist while creating IdentityServerRoles subjects; and that the relevant organizations exist while creating sub organization or peer organization referrals.

Please note that in the text of Value elements in SubOrgReferral, PeerOrgReferral, Organization subject, IdentityServerRoles subject, LDAPGroups subject, LDAPRoles subject and LDAPUsers subject need to be the full DN.

To Create Policies With the Access Manager Console

Navigate to the Identity Management interface.

Choose the organization for which you would like to create a policy.

Ensure that the location of the Policy Management window is correct for your organization.

Choose Policies from the View menu.

By default, the Organizations view is visible in the View menu. All suborganizations configured, if any, will be visible below it. If creating policies for a suborganization, choose the suborganization and then choose Policies from the View menu.

Click New in the Navigation frame. The New Policy window opens.

Select the type of policy, normal or referral, that you wish to create.

If a referral policy that refers to a suborganization does not exist, you will not be able to create any polices for that suborganization.

It is not necessary to define all of the fields for normal or referral policies at this time. You may create the policy, then add rules, subjects, referrals, and so forth, later.

Type a name for the policy and click OK.

By default, the General view is displayed.

The General view displays the name of the policy and allows you to enter a description of the policy that is to be created.

Click Save to complete the policy’s configuration.

Creating Policies for Peer Organizations and Suborganizations

In order to create policies for peer or suborganizations, you must first create a referral policy in the parent (or another peer) organization. Also, the Policy Configuration service should be registered and the template created in the suborganizations. The referral policy must contain, in its rule definition, the resource prefix that is being managed by the suborganization. Once the referral policy is created in the parent organization (or another peer organization), normal policies can be created at the suborganization (or peer organization).

In this example, o=isp is the parent organization, o=example.com is the suborganization and manages resources and sub-resources of http://www.example.com.

To Create a Policy for a Suborganization

Create a referral policy at o=isp. For information on referral policies, see the procedure Modifying a Referral Policy.

The referral policy must define http://www.example.com as the resource in the rule, and must contain a SubOrgReferral with example.com as the value in the referral.

Go to the Organization view and navigate to the suborganization example.com.

Ensure that the policy configuration service is registered at the suborganization level, example.com. For information, see Adding Policy Configuration Services.

Now that the resource is referred to sun.com by isp, normal policies can be created for the resource http://www.example.com, or for any resource starting with http://www.example.com.

See the procedure Modifying a Normal Policy for information on creating normal policies.

To define policies for other resources managed by example.com, additional referral policies must be created at o=isp.

Managing Policies

Once a normal or referral policy is created and added to Access Manager, you can manage the policy through the Access Manager console by modifying the rules, subjects, conditions and referrals.

Modifying a Normal Policy

Through the Identity Management interface, you can create a policy that defines access permissions. Such a policy is referred to as a normal policy. A normal policy can consist of multiple rules, subjects, and conditions. This section lists and defines the default fields that you can specify when creating a normal policy.

To Modify Rules

From the Identity Management interface, select Policies from the View menu.

The policies that were created for that organization are displayed.

Choose the policy you wish to modify and click the Properties arrow. The Edit Policy window is opened in the Data frame.

By default, the General view is displayed. The attributes contained in the General view are described in Creating Policies.

Select Rules from the View menu and click New.

If more than one service exists, they will be listed in the Data pane. Choose the service for which you wish to create a policy and click Next. The New Rule window is displayed.

Define the resource, actions and action values in the Rules fields. The fields are:

Type. Displays the service for the policy to be created. The default is URL Policy Agent.

Rule Name. Enter the name of the rule.

Resource Name. Enter the name of a resource. For example:

http://www.example.com

Currently, Policy Agents only support http:// and https:// resources and do not support IP addresses in place of the hostname.

Wildcards are supported for resource names, port number and protocol. 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://.

To allow the management of resource for all servers installed on a specific machine, you can define the resource as http://host*:*. Additionally, you can define the following resource to grant an administrator to a specific organization authority for all of the services in that organization:

http://*.subdomain.domain.topleveldomain

Select Actions. For the URL Policy Agent Service, you can select either or both of the following default actions:

GET

POST

Select Action Values. For the URL Policy Agent Service, you can choose one of the following action values:

Allow lets 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. See To Add or Modify Conditions for more information.



Note	If the service is defined so that an action does not need resource definitions, the resource field will not be displayed. If the service contains both types of actions (some requiring resources, some without resources), an option is displayed to select rules with actions requiring no resources, or rules with actions requiring resources.

Click Finish to save the rule. This only saves the configuration in memory. Follow step 7 to complete the process.

Repeat steps 1 through 5 to create additional rules.

All of the rules created for that policy are displayed in the table in the Rules view. Click Save to add the rules to the policy.

To remove a rule from a policy, select the rule and click Remove.

You can edit any rule definition by clicking on the Edit link next to the rule name.

To Modify Subjects

To define the subject for the policy, select Subject from the View menu and click New.

Select one of the default subject types:

Authenticated Users. This subject type implies that any user with a valid SSOToken is a member of this subject.

All authenticated users would be member of this Subject, even if they have authenticated to an organization that is different from the organization in which the policy is defined. This is useful if the resource owner would like to give access to resources that is managed for users from other organizations. If you want to restrict access to resources being protected to members of a specific organization, please use the Organization subject.

Access Manager Roles. This subject type implies that any member of an Access Manager role is a member of this subject. An Access Manager role is created using Access Manager. These roles have object classes mandated by Access Manager. Access Manager roles can only be accessed through the hosting Access Manager Policy Service.

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.

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

Organization. This subject type implies that any member of an organization is a member of this subject.

Web Services Client. This subject type implies that a web service client (WSC) identified by the SSOToken is a member of this subject, if the DN of any principal contained in the SSOToken matches any selected value of this subject. Valid values are the DNs of trusted certificates in the local JKS keystore, which correspond to the certificates of trusted WSCs. This subject has dependency on the Liberty Web Services Framework and should be used only by Liberty Service Providers to authorize WSCs.

Make sure that you have created the keystore before you add this Subject to a policy. Information on setting up the keystore can be found in the following location:

AcessManager-base/SUNWam/samples/saml/xmlsig/keytool.html

Click Next to continue.

Enter a name for the subject.

Select or deselect the Exclusive field.

If this field is not selected (default), the policy applies to the identity that is a member of the subject. If the field is selected, the policy applies the identity that is not a member of the subject.

If multiple subjects exist in the policy, the policy applies to the identity when at least one of the subjects implies that the policy applies to the given identity.

Perform a search in order to display the identities to add to the subject. This step is not applicable for the Authenticated Users subject or Web Services Client subjects.

The default (*) search pattern will display all qualified entries.

Select the individual identities you wish to add for the subject, or click Add All to add all of the identities at once. Click Add to move the identities to the Select List Box. This step is not applicable for the Authenticated Users subject or Web Services Client subjects.

Click Finish.

The subject’s names, type and exclusive status are displayed in the table in the Subjects view. Click Save.

To remove a subject from a policy, select the subject and click Delete, then Save.

You can edit any subject definition by clicking on the Edit link next to the subject name.

To Add or Modify Conditions

Select Conditions from the View menu. Click New to add a new condition, or click the Edit link to edit an existing condition.

Select one of the following default conditions:

Authentication Level

Authentication Scheme

IP Address

LE Authentication Level

Session

Time

For Authentication Level, the policy applies if the user’s authentication level is greater than or equal to the Authentication level set in the condition. For LE Authentication Level, the policy applies if the user’s authentication level is less than or equal to the Authentication level set in the condition

Click Next.

Define the values for a given condition. The fields are:

Name. Enter the name of the condition.

Authentication Level

Authentication level. Indicate the level of trust for authentication. The available authentication levels are displayed in the authentication level and authentication module table.

The authentication level condition can be used to specify levels other than those from the registered auth modules levels for that organization. This is useful when a policy applies to user authenticated from another organization.

Authentication Scheme

Authentication scheme. Choose the authentication scheme for the condition from the pull-down menu. These authentication schemes are taken from the Core service template in the organization authentication modules.

IP Address

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

Time

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 Access Manager JVM.

Session

Max Session Time. Specifies the maximum user session time during which a policy applies.

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.

Once you have defined the condition, click Finish.

All of the conditions created for that policy are displayed in the table in the Conditions view.

Click Save.

To remove a condition from a policy, select the condition and click Delete.

You can edit any condition definition by clicking on the Edit link next to the condition name.

Modifying a Referral Policy

Through the Identity Management interface you can delegate an organization’s policy definitions and decisions to another organization. (You can also delegate policy decisions for a resource to other policy products.) A referral policy controls this policy delegation for both policy creation and evaluation. It consists of a rule and the referral itself.

To Modify Rules

Select Rules from the View menu. Click New to add a new rule, or click the Edit link to edit an existing rule.

Select the Service Type. Click Next if you are creating a new rule.

Define the resource in the Rules fields. The fields are:

Type. Displays the policy service for the policy to be created.

Rule Name. Enter the name of the rule.

Resource Name. Enter the name of a resource. For example:

http://www.sunone.com

Currently, Policy Agents only support http:// and https:// resources and do not support IP addresses in place of the hostname.

Wildcards are supported for resource names, port number and protocol.

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://.

http://*.subdomain.domain.topleveldomain

Click Finish.

Repeat steps 1 through 4to create additional rules.

All of the rules created for that policy are displayed in the table in the Rules view.

Click Save.

To remove a rule from a policy, select the rule and click Delete.

You can edit any rule definition by clicking on the Edit link next to the rule name.

To Add Referrals

Select Referrals from the View menu. Click New to add a new referral, or click the Edit link to edit an existing referral.

Define the resource in the Rules fields. The fields are:

Referral. Displays the current referral type.

Name. Enter the name of the referral.

Containing. Specifies a filter for the organization names that will be displayed in the Value field. By default, it will display all organization names.

Value. Select the organization name of the referral.

Click OK and Save.

To remove a referral from a policy, select the referral and click Delete.

You can edit any referral definition by clicking on the Edit link next to the referral name.

Policy Configuration Service

The Policy Configuration service is used to configure policy-related attributes for each organization through the Access Manager console. You can also define resource name implementations and Directory Server data stores for use with the Access Manager Authentication service.

Caching Subject Evaluations

To improve policy evaluation performance, subject evaluations are cached for a period of minutes as defined by the Subjects Result Time To Live attribute in the Policy Configuration service. These cached policy decisions are referred to until the time defined in the Subjects Result Time To Live attribute has elapsed. Once this time has been reached, the next time the policy is evaluated its decision would reflect the user’s changed state, if applicable (for example, if the user has been removed from a group).

amldapuser Definition

amldapuser is a user created during installation that is used to bind and search Directory Server during LDAP and Membership authentication. It is also used in the Policy Configuration service. Once the LDAP, Membership or Policy Configuration services are registered to an organization, the password for this user (configured during installation) must be entered. For more information, see the Sun Java System Access Manager Migration Guide .

Adding Policy Configuration Services

Adding a policy configuration service is the same as adding any type of service; it is done within the Identity Management interface. By default, the Policy Configuration service is automatically added to the top-level organization. Any policy service you create must be added to all organizations. Whenever you add the policy configuration service, you must enter the LDAP bind password in the template.

To Add the Policy Configuration Service

Navigate to the Identity Management interface.

When the console opens, the default interface is Identity Management.

Choose the organization for which you would like to create policy.

If logged in as the Top-Level Administrator, make sure that the location of the Identity Management module is the top-level organization where all configured organizations are visible. The default top-level organization is defined during installation.

Choose Services from the View menu.

If the organization already has registered services, they will be displayed in the Navigation frame.

Click Add in the Navigation frame.

A listing of services not yet registered to this organization is displayed in the Data frame.

From the Add Services window, opened in the Data frame, choose Policy Configuration and click OK.

The Policy Configuration Service is added to the list of services in the Navigation frame.

Click the Properties arrow to configure the policy service.

If the policy template has not yet been configured, you will need to create a service template for the newly registered policy service.

To configure the policy service, click Create.

Modify the Policy Configuration attributes. See Policy Configuration Service Attributes for a description of these attributes.

Click Save.

The policy configuration service is now added to the chosen organization.



Note	Suborganizations must register their policy services independently of their parent organization. In other words, the suborganization o=suborg,dc=sun,dc=com will not inherit the policy configuration service from its parent dc=sun,dc=com.

Policy-Based Resource Management

Some organizations require an advanced authentication scenario where a user authenticates against a particular module based on the resource that they are attempting to access. Policy-based resource management is a function of Access Manager in which the user does not need to pass their default authentication module in order to access a web resource.

Limitations

All policies applicable to the resource require the same authentication scheme or level of authentication. For example, if abc.html is defined in a policy for the LDAP authentication module, it can not be defined in a policy for the Certificate-based authentication module.

Level and scheme are the only conditions that can be defined for this policy.

This feature does not work across different DNS domains.

To Configure Policy-based Resource Management

Once both Access Manager and a policy agent have been installed, policy-based resource management can be configured. To do this, it is necessary to point Access Manager to the Gateway servlet.

Previous Contents Index Next
Sun Java System Access Manager 6 2005Q1 Administration Guide