Overview

Using CA AppLogic® › Grid Administration Guide › Role-Based Access Control › Overview

Overview

This section contains the following topics:

CA AppLogic® ruses role-based access control (RBAC) to control which users can perform which actions to which objects on a grid. The allows many users to work on a single grid without interfering with each other. RBAC does not enable multi-tenancy. For example, all users can view the list of all applications including those to which they have no access. Object name spaces are not segregated.

RBAC authorizes user actions for individual users and user groups. User groups can include individual users or other groups as members. Users and groups are specific to a particular grid are created using the CA AppLogic® command-line interface (CLI). User and group information is maintained in a directory service included with the grid controller.

RBAC supports the optional use of an external directory service such as Microsoft Active Directory. In this case, user and group information is obtained from the external directory service when authentication is required.

CA AppLogic® refers to users and groups that are specific to a grid as local and those maintained in an external directory service as global. The respective directory services are also distinguished as local or global. A grid can be configured to use only local users and groups, or to use both local and global users and groups.

Users and groups are also referred to as principals. To identify a principal uniquely, each principal is assigned a unique principal ID. If the principal is a user, the principal ID is often named the user ID. If the principal is a group the principal ID is often named the group ID. The principal ID can be used to look up the following principal details:

Scope—Indicates whether the principal is local or global.
Type—Indicates whether the principal is a user or group.
Name—Specifies the common human-usable name. For example, the local user John is a principal with a scope of local, a type of user and a name of John.

To facilitate user authorization, RBAC uses Access Control Lists (ACLs). There are three grid objects that have an associated ACL: applications, global catalogs, and the grid itself. An ACL includes an owner and a list of entries. The owner is a principal and has the implicit right to modify the ACL. Each entry is comprised of a principal and a corresponding access level that governs how that principal is authorized to perform actions on the object. An access level is a named collection of permissions. For example, the grid object has an access level named grid_administrator and one of the permissions included in this access level is the permission to log in to the grid. A unique principal ID represents each principal in an ACL.

ACL Overview

Note: RBAC does not eliminate maintainer access to a grid. Operations that a maintainer performs are not subject to authorization.

An ACL is a list of all the ways access is granted to an object. This list includes permission levels for individuals and groups. A user can be listed both as an individual and a member of one or more listed groups. Therefore, the system evaluates each relevant ACL entry while granting access to the object. The system grants the user the most permissive access for which they qualify by being a group member or a listed individual. If the most permissive access provides the necessary permission on the object, the authorization succeeds.

The system considers group membership recursively. Therefore, the system considers a user to be a member of a group in the following two cases:

A user who is listed directly in a group is a member of that group.
A user who is listed in a group which is listed in a second group is a member of the second group.

Recursive group membership extends to as many levels of nested groups within groups as are defined.

Example: User with Group and Individual Access on a Grid ACL

Jan is a member of the financial_operators group on the grid ACL. This group is assigned the grid_user access level on the grid object. This access level includes permission to provision applications. This access level does not include permission to create a local user.

Jan also has an individual entry on the grid ACL. This individual entry is assigned the grid_administrator access level on the grid object. This access level includes permission to create a local user. This access level does not include permission to provision applications.

Jan logs on to the grid. In the same session, Jan wants to create a local user and provision an application. The authorization check allows Jan to perform both actions. The group membership allows Jan to provision an application. The individual ACL entry allows Jan to create a local user.

Example: Recursive Group Membership

Robin wants to delete a local user from the grid. Only members of the grid_administrators group have permission to delete local users. Robin is not a member of the grid_administrators group. However, Robin is a member of the al_senior_admins group. This group is a member of the grid_administrators group. Therefore, the system considers Robin to be a member of the grid_administrators group and can delete a local user.