The Policy Service authorizes a user based on the policies stored in the access control information tree. You can create two types of Access Manager policies: normal policies and referral policies. Create a normal policy when you want to define access privileges for a resource. Create a referral policy when you want to delegate policy creation to another entity such as a peer realm, a subrealm, or a third-party product.
A normal policy specifies a protected resource and also specifies who is allowed to access the resource. The protected resource can be anything hosted by a protected server. Examples of protected resources are applications, content such as document files, or the server itself. Only a Top-Level Realm or Policy Administrator can create or manage polices that apply to any resource.
A normal policy consists of rules, subjects, conditions, and response providers.
A rule defines a policy by specifying a resource, one or more sets of an action, and values for each action.
A resource defines the specific object that is being protected. Examples of protected objects are an HTML page on a website, 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 page actions are POST and GET. An allowable action for a human resources service might be canChangeHomeTelephone.
A value defines the permission for the action. Examples are allow anddeny.
A subject specifies by implication the user or collection of users that the policy affects. You can implement custom subjects by using Policy APIs. You can assign subjects to policies. Access Manager includes the following subjects:
The roles you create and manage under the Realms Subject tab can be added as a value of the subject.
The identities you create and manage under the Realms Subject tab can be added as a value of the subject.
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 a realm that is different from the realm 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 realms.
Any member of an LDAP group can be added as a value of this subject.
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.
Any LDAP user can be added as a value of this subject.
Any organization can be added as a 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. 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.
A condition specifies additional constraints that must be satisfied for a policy be applicable. For example, you can define a condition to limit a user’s network access to a specific time period. The condition might state that the subject can access the network only between 7:00 in the morning and 10:00 at night. You can implement custom conditions using the Policy APIs. Access Manager provides the following conditions:
The policy applies if the user's authentication level is greater than or equal to the Authentication level set in the condition. The Authentication Level attribute indicates the level of trust for authentication.
Policy is applicable based on which authentication scheme is specified.
Policy is applicable based on a range of IP Addresses.
Policy is applicable if the user's authentication level is less than or equal to the Authentication level set in the condition.
Policy is applicable based on user session data such as Max Session Time.
Policy is applicable based on values of properties set in the user's Access Manager session.
Policy is applicable based on time constraints.
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.
A referral policy enables a Realm Administrator or a Policy Administrator to delegate policy configuration tasks. A Realm Administrator or Policy Administrator at the root or top level of the Access Manager information tree can create policy for any resource. An administrator or Policy Administrator for realms below the top level have permissions to create policies for only resources delegated to the realm. The Realm Administrator or Policy Administrator can use referral policies to delegate policy management privileges for a collection of resources to other realms.
You can implement custom referrals by using the Policy APIs. Access Manager provides the following referrals:
Administrator can delegate policy management privileges to a peer realm.
Administrator can delegate policy management privileges to a subrealm.
A referral policy delegates both policy creation and policy evaluation. A referral policy consists of one or more rules and one or more referrals.
A rule defines the resource whose policy creation or evaluation is being referred.
A referral defines the identity object to which the policy creation or evaluation is being referred.
For example, a top-level realm exists named ISP. It contains two subrealms named company1 and company2. The Top-Level Administrator for ISP wants to delegate policy management privileges so that a Realm Administrator in company1 can create and manage policies only within the company1 realm, and a Realm Administrator in company2 can create and manage policies only within the company 2 real. The Top-Level Administrator creates two referral policies:
Referral Policy 1
Resource Name: http://company1.com
Subrealm Referral Value: company1
Referral Policy 2
Resource Name: http://company2.com
Subrealm Referral Value : company2