test

Sun Java System Access Manager 7 2005Q4 Administration Guide

Chapter 8 Managing Policies

This chapter describes the Policy Management feature of Sun Java™ System Access Manager. Access Manager’s Policy Management feature enables 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 realms. It also provides a way for a realm or sub realm administrator or policy administrator to view, create, delete and modify policies at the realm level.

This chapter contains the following sections:

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 defines the resources for a particular principal.

Note –

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 Javadoc.

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 a principal 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. By default, Access Manager uses Sun Java Enterprise System Directory Server for data storage, and provides Java and C APIs for policy evaluation and policy service customization (see the Sun Java System Access Manager 7 2005Q4 Developer’s Guide for more information). It also allows administrator to use the Access Manager console for policy management. Access Manager provides one policy—enabled service, the URL Policy Agent service, which uses down-loadable policy agents to enforce the policies.

URL Policy Agent Service

Upon installation, Access Manager provides the URL Policy Agent service to define policies to protect HTTP URLs. 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.

The most current Access Manager Policy Agents can be downloaded from the Sun Microsystems Download Center.

More information on installing and administrating the policy agents can be found in the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.

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.

Access Manager Policy agents enforce decisions only on web URLs (http://... , or https//...). 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.

  1. 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.

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

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

  3. If the resource matches the non-enforced list, configured at the agent, access is allowed.

  4. The Naming Service returns locators for the policy service, session service and logging service.

  5. The agent sends a request to the Policy Service to get policy decisions applicable to the user.

  6. 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.

Policy Types

There are two types of policies that can be configured using Access Manager:

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, conditions, and response providers.

Rules

A rule contains a resource, one or more actions, and a value. Each action can have one or more values.

Note –

It is acceptable to define an action without resources for some services.

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:

AM Identity Subject

The identities you create and manage under the Realms Subject tab can be added as values of the subject.

Access Manager Roles

Any LDAP role can be added as a value 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.

Authenticated Users

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.

LDAP Groups

Any member of an LDAP group can be added as a value of this subject.

LDAP Roles

Any LDAP role can be added as a value 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

Any LDAP user can be added as a value of this subject.

Organization

Any member of an organization is a member of this subject

Web Services Clients

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

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:

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

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. 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 9 a.m. 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.

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.

The default conditions you can add are:

Authentication Level

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.

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

For LE Authentication, the policy applies if the user’s authentication level is less than or equal to the Authentication level set in the condition. The authentication level condition can be used to specify levels other than those from the registered authentication module levels for that realm. This is useful when a policy applies to user authenticated from another realm.

Authentication Scheme

Choose the authentication scheme(s) for the condition from the pull-down menu. These authentication schemes are the authentication modules defined in the Core authentication service at the realm.

IP Address

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

Session

Sets the condition based on user session data. The fields you can modify are:

  • 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.

    You can use this condition to protect sensitive resources so that the resources are available only for a limited time after authentication.

Session Property

Decides whether a policy is applicable to the request based on values of properties set in the user's Access Manager 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 with multiple values in the condition, it is sufficient if the token has at least one value listed for the property in the condition. For example, you can use this condition to apply policies based on attributes in external repositories. A post-authentication plug-in can set up the session properties based on the external attributes.

Time

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

Response Providers

Response providers are plug-ins that provide policy-based response attributes. The response provider attributes are sent with policy decisions to the PEP. Access Manager includes one implementation, the IDResponseProvider. Custom response providers are not supported in this version of Access Manager. Agents, PEPs, typically pass these response attributes as headers to applications. Applications typically use these attributes to personalize application pages such as a portal page.

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.

More information can be found in the following class:

com.sun.identity.policy.ConditionDecision.getAdvices()

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

AuthLevelCondition advice is associated with the following key:

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_LEVEL_CONDITION_ADVICE

AuthSchemeCondition advice is associated with the following key:

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_SCHEME_CONDITION_ADVICE

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 Sun Java System Access Manager Policy Agent 2.2 User’s Guide.

Referral Policy

An administrator may need to delegate one realm's policy definitions and decisions to another realm. (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 realm and sub realm. They delegate to an realm on the same level and an realm on a sub level, respectively. See Creating Policies for Peer Realms and Sub Realms for more information.

Note –

The realm that is referred to 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 top-level realm.

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:

AccessManager-base/SUNWam/dtd (Solairs)
AccessManager-base/identity/dtd (Linux)
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.

Policy Element

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,Referrals, or response providers. 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.

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.

Rule Element

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.

Note –

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

ServiceName 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.

Note –

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.

Subjects Element

The Subjects sub-element identifies a collection of principals to which the policy applies; this 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:

name. This defines a name for the collection.

description. This defines a description of the subject

includeType. This is not currently used.

Subject Element

The Subject sub-element identifies a collection of principals 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, or whether the policy applies to users who are NOT members of the subject.

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 with includeType set to false, the user should not be a member of that subject for the policy to apply.

Referrals Element

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, and so forth). 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.

Note –

The conditions element is an optional element in a policy.

Condition Element

The Condition sub-element identifies a specific policy restriction (time range, authentication level, and sor forth). 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 Enabled Service

You can define policies for resources of a given service only if the service schema has the <Policy> element configures to sms.dtd .

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

/etc/opt/SUNWam/config/xml/

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.

ProcedureTo Add a New Policy Enabled Service

  1. 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 XML file for the default URL Policy Agent service. It is located in /etc/opt/SUNWam/config/xml/.

    SampleWebService.xml . - This is the sample policy service file located inAccessManager-base/samples/policy .

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


    /config/xml/newPolicyService.xml

  3. 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 /config/xml/newPolicyService.xml

  4. 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. You can also get and list policies in XML using the amadmin utility. 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 Sun Java System Access Manager 7 2005Q4 Developer’s Guide.

Policies are generally created using an XML file and added to Access Manager through the amadmin command line utility and then managed using the Access Manager console (although policies can be created using 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 then add the modified policy using amadmin.

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

ProcedureTo Create Policies with amadmin

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

    AccessManager-base /SUNWam/dtd

  2. Once the policy 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 realm while creating authentication scheme condition; that the corresponding LDAP objects realms, groups, roles and users) exist while creating realms, LDAP groups, LDAP roles and LDAP user subjects; that Access Manager roles exist while creating IdentityServerRoles subjects; and that the relevant realms exist while creating sub realm or peer realm referrals.

    Please note that in the text of Value elements in SubrealmReferral, PeerRealmReferral, Realm subject, IdentityServerRoles subject, LDAPGroups subject, LDAPRoles subject and LDAPUsers subject need to be the full DN.

ProcedureTo Create a Normal Policy With the Access Manager Console

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

  2. Click the Policies tab.

  3. Click New Policy from the Policies list.

  4. Add a name and a description for the policy.

  5. If you wish the policy to be active, select Yes in the Active attribute.

  6. It is not necessary to define all of the fields for normal policies at this time. You may create the policy, then add rules, subjects, conditions, and response providers later. See Managing Policies for more information.

  7. Click Create.

ProcedureTo Create a Referral Policy With the Access Manager Console

  1. Choose the realm for which you would like to create the policy.

  2. Click New Referral from the Policies tab.

  3. Add a name and a description for the policy.

  4. If you wish the policy to be active, select Yes in the Active attribute.

  5. It is not necessary to define all of the fields for referral policies at this time. You may create the policy, then add rules and referrals later. See Managing Policies for more information.

  6. Click Create.

Creating Policies for Peer Realms and Sub Realms

In order to create policies for peer or sub realms, you must first create a referral policy in the parent (or another peer) realm. The referral policy must contain, in its rule definition, the resource prefix that is being managed by the sub realm. Once the referral policy is created in the parent realm (or another peer realm) normal policies can be created at the sub realm (or peer realm).

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

ProcedureTo Create a Policy for a Sub Realm

  1. 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 SubRealmReferral with example.com as the value in the referral.

  2. Navigate to the sub realm example.com.

  3. Now that the resource is referred to example.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 .

    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 Policies tab, you can modify a normal policy that defines access permissions. You can define and configure multiple rules, subjects, conditions and resource comparators. This section lists and describes the steps to do so.

ProcedureTo Add or Modify a Rule to a Normal Policy

  1. 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.

  2. Under the Rules menu, click New.

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

    Discovery Service

    Defines the authorization actions for Discovery service query and modify protocol invocations by web services clients for a specified resource.

    Liberty Personal Profile Service

    Defines the authorization actions for Liberty Personal Profile service query and modify protocol invocations by web services clients for a specified resource.

    URL Policy Agent

    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.

  4. Click Next.

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


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

  6. Select the action for the rule. If you are using the URL Policy Agent service, you can select the following:

    • GET

    • POST

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

  8. Click Finish.

ProcedureTo Add or Modify a Subject to a Normal Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the subject. If you have not yet created the policy, see To Create a Normal Policy With the Access Manager Console.

  2. Under the Subject list, click New.

  3. Select one of the default subject types. For descriptions of the subject types, see Subjects

  4. Click Next.

  5. Enter a name for the subject.

  6. Select or deselect the Exclusive field.

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

    If multiple subjects exist in the policy, the policy applies to the identity when the identity is a member of at least one subject.

  7. 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 entries.

  8. 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 Selected list. This step is not applicable for the Authenticated Users subject.

  9. Click Finish.

  10. To remove a subject from a policy, select the subject and click Delete. You can edit any subject definition by clicking on the subject name.

ProcedureTo Add a Condition to a Normal Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the condition. If you have not yet created the policy, see To Create a Normal Policy With the Access Manager Console

  2. Under the Conditions list, click New.

  3. Select the condition type and click Next.

  4. Define the fields for the condition type. For a description of the condition types, see Conditions.

  5. Click Finish.

ProcedureTo Add a Response Provider to a Normal Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the response provider. If you have not yet created the policy, see To Create a Normal Policy With the Access Manager Console.

  2. Under the Response Providers list, click New.

  3. Enter a name for the response provider.

  4. Define the following values:

    StaticAttribute

    The response attribute with name and values defined in the instance of IDResponseProvider and stored in the policy.

    DynamicAttribute

    The response attributes chosen here need to first be defined in the Policy Configuration Service for the corresponding realm. The attribute names defined should be the same as those existing in the configured datastore. For details on how to define the attributes see the Policy Configuration attribute definitions in the Access Manager online help.

  5. Click Finish.

  6. To remove response provider from a policy, select the subject and click Delete. You can edit any response provider definition by clicking on the name.

Modifying a Referral Policy

You can delegate policy definitions and decisions of a realm to different realms using referral policies. Custom referrals can used to get policy decisions from any policy destination point. Once you have created a referral policy, you can add or modify associated the rules, referrals, and resource providers.

ProcedureTo Add or Modify a Rule to a Referral Policy

  1. 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 Referral Policy With the Access Manager Console.

  2. Under the Rules list, click New.

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

    Discovery Service

    Defines the authorization actions for Discovery service query and modify protocol invocations by web services clients for a specified resource.

    Liberty Personal Profile Service

    Defines the authorization actions for Liberty Personal Profile service query and modify protocol invocations by web services clients for a specified resource.

    URL Policy Agent

    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.

  4. Click Next.

  5. 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 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

  6. Click Finish.

ProcedureTo Add or Modify Referrals to a Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the response provider. If you have not yet created the policy, see To Create a Referral Policy With the Access Manager Console.

  2. Under the Rules list, click New.

  3. Select the Service type.

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

    Referral— Displays the current referral type.

    Name— Enter the name of the referral.

    Resource Name— Enter the name of the resource.

    Filter— 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.

  5. Click Finish.

    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.

ProcedureTo Add a Response Provider to a Referral Policy

  1. If you have already created the policy, click the name of the policy for which you wish to add the response provider. If you have not yet created the policy, see To Create a Normal Policy With the Access Manager Console.

  2. Under the Response Providers list, click New.

  3. Enter a name for the response provider.

  4. Define the following values:

    StaticAttribute

    The response attribute with name and values defined in the instance of IDResponseProvider and stored in the policy.

    DynamicAttribute

    The response attribute with only names selected in the instance of IDResponseProvider in the policy. The values are read from IDRepostitories based on the user identity request during policy evaluation.

  5. Click Finish.

  6. To remove response provider from a policy, select the subject and click Delete. You can edit any response provider definition by clicking on the 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 policy framework. The Directory Server specified in the Policy Configuration Service is used for membership evaluation of LDAP Users, LDAP Groups, LDAP Roles, and organization policy subjects.

Subjects Result Time To Live

To improve policy evaluation performance, membership evaluations are cached for a period of time as defined by the Subjects Result Time To Live attribute in the Policy Configuration service. These cached membership decisions are used until the time defined in the Subjects Result Time To Live attribute has elapsed. Membership evaluation after this is used to reflect the current state of users in the directory.

Dynamic Attributes

These are the allowed dynamic attribute names which are displayed in a list and chosen to define policy response provider dynamic attributes. The names that are defined need to be same as attribute names as defined in the data repository.

amldapuser Definition

amldapuser is a user created during installation used by default to the Directory Server specified in the Policy Configuration service. This can be changed, as necessary, by the administrator or policy administrator of the realm.

Adding Policy Configuration Services

When the realm is created, Policy Configuration service attributes are automatically set for the realm. You can, however, modify the attributes as needed.

Resource—Based Authentication

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. Resource-based authentication is a feature of Access Manager in which a user must authenticate to a specific authentication module protecting the resource, and not to the default authentication module. This feature is only applicable to first time user authentications.

Note –

This is a separate feature than the resource-based authentication described in Session Upgrade. That particular feature does not have any limitations.

Limitations

Resource—based authentication contains the following limitations:

ProcedureTo Configure Resource—based Authentication

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

  1. Open AMAgent.properties.

    AMAgent.properties can be found (in a Solaris environment) in /etc/opt//SUNWam/agents/config/ .

  2. Comment out the following line:

    #com.sun.am.policy.am.loginURL = http://Access Manager_server_host.domain_name:port/amserver/UI/Login.

  3. Add the following line to the file:

    com.sun.am.policy.am.loginURL = http://AccessManager_host.domain_name:port/amserver/gateway

    Note –

    The gateway servlet is developed using the Policy Evaluation APIs and can be used to write a custom mechanism to accomplish resource-based authentication. See the Chapter 6, Using the Policy APIs, in Sun Java System Access Manager 7 2005Q4 Developer’s Guide in the Access Manager Developer's Guide.

  4. Restart the agent.