Access Manager Authorization Engine
The Access Manager authorization service performs authorization decisions based on the policies applied to the objects as explained earlier. For each request for access to an object inside the protected object space the request will be evaluated against the ACL, the POP and the Authorization rule attached to the object or inherited by it, in the order described. A single object can have none, one, two, or all three types of rule attached to it but only one of each type.
Access control list (ACL)
An access control list policy, or ACL policy, is the set of rules (permissions) that specifies the conditions necessary to perform certain operations on a resource. ACL policy definitions are important components of the security policy established for the secure domain. ACL policies, like all policies, are used to stamp an organization's security requirements onto the resources represented in the protected object space. An ACL policy specifically controls:
- What operations can be performed on the resource.
- Who can perform these operations.
An ACL policy is made up of one or more entries that include user and group designations and their specific permissions or rights. An ACL can also contain rules that apply to unauthenticated users.
Protected object policies (POP)
ACL policies provide the authorization service with information to make a "yes" or "no" answer on a request to access a protected object and perform some operation on that object. POP policies contain additional conditions on the request that are passed back to the Access Manager Base and the resource manager (such as WebSEAL) along with the "yes" ACL policy decision from the authorization service. It is the responsibility of Access Manager and the resource manager to enforce the POP conditions.
Authorization rules
An Access Manager authorization rule is a policy type similar to an access control list (ACL) or a protected object policy (POP). Authorization rules provide the flexibility needed to extend an ACL or POP by tailoring security policy to your needs. The rule is stored as a text rule within a rule policy object and is attached to a protected object in the same way and with similar constraints as ACLs and POPs.
Rules allow you to make decisions based on the attributes of a person or object and the context and environment surrounding the access decision. For example, we can use a rule to implement a time-of-day policy that depends on the user or group. You also can use a rule to extend the access control capabilities that ACLs provide by implementing a more advanced policy, such as one based on quotas. While an ACL can grant a group permission to write to a resource, a rule can go a step further by allowing you to determine if a group has exceeded a specific quota for a given week before permitting that group to write to a resource.
For more detailed information about Tivoli Access Manager security and administration, refer to the following documents:
- Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360
- WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,SC32-1359
- Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014
- IBM Tivoli Access Manager for e-business, REDP3677
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.
