ACL policies

The ACL policy defines who has access to and what operations can be performed on the object. Each ACL policy has a unique name and can be applied to multiple objects within a domain. An ACL policy consists of one or more of the following entry descriptions:

• The names of users and groups whose access to the object is explicitly controlled
• The specific operations that each user, group, or role can do
• The specific operations the special any-other and unauthenticated user categories can do

ACL policies with the authorization service

Security Verify Access relies on ACL policies to specify the conditions for a particular user to do an operation on a protected object. When you attach an ACL policy to an object, entries in the ACL specify what operations are allowed on it. The entries in the ACL policies also specify who can do the operations.

Web Portal Manager can group ACL policies based on:

• Use of policies in a particular part of the object space such as WebSEAL
• Use across the entire object space such as Base or Generic

ISAM uses a default set of actions that cover a wide range of operations. Actions, or permissions, are represented by single alphabetic ASCII characters (a-z, A-Z). Each permission is displayed by the pdadmin utility with a label describing the operation it governs. A resource manager software typically contains one or more operations that are done on protected resources. ISAM requires that resource managers make calls to the authorization service before the requested operation is allowed to progress. This call is made through the authorization application programming interface (authorization API) for both ISAM services and other applications. The authorization service uses the information contained in the ACL entry to make a simple yes or no response to the following question:

Does this user or group have the appropriate permission to do the requested operation on the requested object? For example, does the user have the view (r) permission to view an object?

The authorization service has no knowledge about the operation that requires the read (r) permission. It merely notes the presence or absence of the r action bit in the ACL entry of the requesting user or group. The authorization service is independent of the requested operations. This independence is why we can extend the benefits of the authorization service to other applications.

Evaluation of ACL policies

Evaluate authenticated requests

ISAM evaluates an authenticated user request by matching attributes of the user requesting access with criteria defined in the ACL entries. ISAM evaluates an authenticated user request in the following order:

1. Match the user ID with the user ACL entries. The permissions granted are the permissions in the matching entry.

   Successful match	Evaluation stops here.
   Unsuccessful match	Continue to the next step.

2. Determine the groups to which the user belongs and match group ID with the group ACL entries. If more than one group entry is matched, the resulting permissions are a logical or operation (most permissive) of the permissions granted by each matching entry.

   Successful match	Evaluation stops here.
   Unsuccessful match	Continue to the next step.

3. Grant the permissions of the any-other entry, if it exists.

   Successful match	Evaluation stops here.
   Unsuccessful match	Continue to the next step.

4. An implicit any-other entity exists when there is no any-other ACL entry. This implicit entry grants no permissions.

   Successful match

   No permissions granted. End of evaluation process.

Evaluate unauthenticated requests

ISAM evaluates an unauthenticated user by granting the permissions from the unauthenticated ACL entry. The unauthenticated entry is a mask (a bit-wise and operation) against the any-other entry when permissions are determined. A permission for unauthenticated is granted only if the permission also is defined in the any-other entry. Because unauthenticated depends on any-other, it makes little sense for an ACL entry to contain unauthenticated without any-other. If an ACL entry contains unauthenticated without any-other, the default response is to deny permissions to unauthenticated.

Parent topic: Security Verify Access administration