Roles and Permissions

Roles and Permissions

Permissions model descripton and background

The Conductor permissions model is based on an extensible, reusable model that’s applied consistently across all object types for various roles. End users and administrators aren’t special kinds of users, they differ only in the roles they’ve been granted on various resources, and those roles differ only in the collection of allowed actions that they include.

From the ground up, we start with the concept of a “privilege” or allowed action, which represents the ability to perform a particular type of action on a particular object type. The action types are currently limited to “view”, “use”, “modify”, “create”, “view permissions”, and “edit permissions”. The first four control the actions you can perform on the object itself, and the latter two control the level of interaction allowed with the permission system in the context of the object. For example, to launch a deployment a user will need the “create deployment” permission . To see the quota usage in that pool, the user will need “view quota” rights to the pool, and to grant access to other users to this pool, the user will need “edit pool permissions”.

To simplify UI operations, since ordinarily we’d want to grant a group of actions together, we’ve added the concept of a Role. A role is an abstract collection of lower-level privileges or actions. It’s abstract in that the Role itself does not tie to any particular objects or resources -- that only happens when we grant a role to a user on a specific resource. For example, the currently-defined roles on Pools are as follows (details on what each role includes will be defined later):

• Pool Administrator
• Pool Deployable Administrator
• Pool User

In addition to being explicitly granted permission to a specific resource by administrator action, there are other ways a user might grant access to a resource:

1. Permission inheritance from higher-level resources. An Environment/Pool Family administrator also obtains the privileges defined in the role on pools contained within the Environment. Similarly a permission grant to a user on a Deployment will grant rights on instances within the deployment, etc. Full detail included in the role-by-role description further down.
2. Site-wide permissions: Global roles impart the included privileges across all resources (divided by resource type). A Global Pool Administrator has full access to all pools (but not Providers). A Global Provider Administrator has full access to all Providers (but not Pools). An Administrator has full rights to everything, of all object types.
3. Generally speaking, when an object of a given type is created (Instance, Provider Account, Pool, etc), the creating user is automatically granted the appropriate “Owner” or “Administrator” role on the object. One consequence of this is that revoking an administrator’s “Global” roles isn’t guaranteed to revoke everything, as the admin will also have resource-specific permission grants on things he has created. This is also how several users can share a pool without administrator intervention for role-setting. All users have “Deployment Create” permission on the pool, and each user automatically becomes a “Deployment Owner” for any launched deployment. Thus users can’t see each other’s deployments without explicit permission grants -- by default each user’s launched instances/deployments are visible only to the user and to any Pool, Environment, or site-wide Administrators. For each object type, the specific role assigned to the creating user is defined in the Role model as part of the role definition.

So there are a couple additional things of note here:

1. Even though the example roles above are Pool roles , they include actions relating to other object types. However, those actions are meaningful in the context of the Pool in question. i.e. if a user was granted the Pool User role on pool1, this user can create/launch new Deployments in pool1 only .
2. If a user is a Pool Administrator for pool1, then the user can view/modify/delete any instance within the pool, regardless of instance ownership. By contrast, a Pool User has no inherent permissions on instances within the pool. However, the Pool User will automatically be granted the Instance Owner role for any instances created. The net effect is that Pool Users can view/edit their own instances but not those of others in the pool. Pool owners have full rights to all instances within the pool.

More details on site-wide roles

In addition to roles that are assigned to users on particular objects, we also have what we call site-wide roles. Behind the scenes, they are still grants on a single object, but in this case it’s a placeholder object that indicates site-wide permissions. In other words, if a user was assigned a site-wide role that contained “modify providers”, this user would be able to modify any provider in the system, so it would be equivalent to the user being assigned this privilege on each provider in the system. In some cases, the roles only make sense in a site-wide context. “Create providers” allows a user/admin to create a new provider -- this permission can only be granted at the site-wide level, since there is no particular resource that we start with in creating a new provider. The most important use of this is the Administrator role, which grants all privileges across all object types globally. We have more limited admin roles as well which grant global access to a subset of actions, for roles such as Global Provider Administrator or Global Pool Administrator. In addition, there are more end-user-oriented global roles such as “Global Pool User” which grants the same privileges as the “Pool User” role, but to all pools systemwide.

So once we’ve defined the roles available, now we can actually grant permissions to users. A permission grant is essentially a combination of a user, a role, and a resource. For example, when a user launches an instance, the user will be granted the Instance Owner role on the instance. This same user was earlier granted the Pool User role on the pool in which the instance was launched.

Privilege Checking Heirarchy

As mentioned above, object/resource types appear in two different contexts in the permissions system. First of all, the roles themselves are scoped by “role assignment” object type. This is the object type of the object on which an explicit permission grant is made -- i.e. a user may be granted “Pool Administrator” on a pool, or “Provider Account User” on a provider account. This role may contain privileges granted not only on this object type but also on related object type. The ability to include low-level privileges of more than one object type in a specific role on a single resource is useful primarily in two ways. First it lets us have control over a user’s ability to create related objects -- a Provider Administrator can create new Provider accounts on the Provider, but a Provider User (if that role were to exist) cannot. Secondly it allows us to make use of permission inheritance when checking permissions on an object. Taking the Pool Administrator role as an example — the Role object type is ‘Pool’. The role contains various privileges, not only PoolPrivileges (Pool view, Pool modify, etc.) but also Deployment and Instance privileges. (Deployment Create, Deployment View, etc.). When we check permissions on the deployment (“Can Jane modify ‘jboss’ deployment?”), we first check to see if she has permissions on the deployment itself (as would be the case if she had launched it). Then we check permissions on the Pool. If she had a Pool Administrator grant (which includes ‘Deployment modify’) then this would also satisfy the permission check, whereas a Pool role assignment with, say, ‘Quota modify’ but missing ‘Deployment modify’ would not satisfy it. In all cases, once the specific hierarchy for permission checking is exhausted, we check site-wide privileges. If Jane has been assigned any Global role which includes ‘Deployment modify’ the check is satisfied here as well.

The key distinction here is Role object type (scoping of roles used to filter role list for permission grant/assignment) vs. Privilege object type (which refers to the object type associated with the actual granted low-level privilege, used in the various permission checking/filtering methods. When assigning permissions to users we use only Roles. However when checking permissions for an end user to determine available actions, Roles are never used. It doesn’t matter whether a user gets permission for an action via an explicit grant on that object, via a container object, or as a site-wide grant. Likewise it doesn’t matter if a user gets a bunch of privileges in a single role grant or if the privileges are granted via a series of less-inclusive role grants.

Permission inheritence for current object types is defined as follows:

• Pool Family: Check this object, then global permissions
• Pool: Check this object, then the pool family it belongs to, then global permissions
• Catalog: Check this object, then its pool, pool family, and global permissions
• Deployable: Check this object, then the catalog(s), pool(s), pool family, and global permissions
• Deployment: Check this object, then its pool, pool family, and global permissions
• Deployment: Check this object, then its deployment, pool, pool family, and global permissions
• Provider: Check this object, then global
• Provider Account: Check this object, then its provider, then global

Full list of roles.

• Roles list - Full enumeration of current roles defined

Default roles for new users

• Global Hardware Profile User:
  • note: don’t remove this role from a user or the user will no longer have access to hardware profiles, which are necessary for launch
• Pool User on the default pool:
  • For out-of-the-box user ability to launch, this role assignment makes sense. However if most users will be configuring their own pools/environments, then there’s not much point in automatically doing this.
• Pool Family User on the default pool family:
  • For out-of-the-box user ability to launch, this role assignment makes sense. However if most users will be configuring their own pools/environments, then there’s not much point in automatically doing this.

Future Concept: User Groups

Eventually we want to be able to grant permissions to user groups in addition to individual users. This will allow us to manage permissions to a group as a whole, and by adding/removing users from the group we will automatically grant/revoke access to the user on any resources granted to the group. This is out of scope for the current iteration.