Summary

Expand the security and permissions infrastructure in Concourse Server to respect environments and have a (limited) notion of user roles.

Motivation

While Concourse has a notion of security (e.g. all users are authenticated using a password, there isn't a strong notion of permissions because all users have the exact same access to all data, operations, etc. We don't want to overwhelm the system with permissions that are unnecessarily granular, but it is important to have some basic controls in place. For instance, its possible that a server administration wants to limit the ability of other users to create environments on the fly. More importantly, the server administrator might want to limit the ability of some users to access sensitive data (i.e. data in a production environment).

Use Cases

• User A can create a new environment, but User B cannot
• User A can access environment X, but User B cannot
• User A can delete an environment, but User B cannot
• User A can manage users, dump storage blocks, etc, but User B cannot

Effects on Public API

In general, the management CLIs will need to check if the authenticating user has the ADMIN role. This is more of a behind the scenes change, but we will need an effective error message to display in the case where a non-admin user tries to perform a management function.

ManageUsersCli

The useradmin CLI will need new options to support the additional workflows.

• --role <role_identifier>
• --add-access <environment>
• --remove-access <environment>

Each of those new options will be usable with the --edit-user <username> option to make some modification to the user.

Effects on AccessManager API

Additions:

• public Role getRole()
• public boolean hasAccess(String username, String environment)

Upgrade Considerations

• All existing users will need to be given a uid
• All existing users will need to be given a role [probably makes sense to make everyone an ADMIN]
• The serialization format will also change, so we'll need to replace the .credentials file on disk

Important Questions and Semantics

• A major design decision is the fact that we are not going to distinguish between read/write permissions when it comes to environment access. We are doing this because Concourse has the built in ability to audit changes and revert to previous states, so we don't really need to protect the system by limiting the ability of certain users to write.

UID

• Each user must be given a UID.
• The uid will be represented in memory and on disk using a short.
• The AccessManager will store a map from username to uid. Every other collection in the AccessManager that associates the user to something (e.g. the mapping from user to credential) will use the uid instead of the username.
• The UID should be an incrementing number. The "next" UID should be stored in the first 2 bytes of the servers .credentials file and held in memory by the AccessManager.

Roles & Access

We are adding notions of "roles" and "access" to Concourse Server. In most case, the role is all that is necessary to determine if a user can do something. In the case of connecting to an environment, we must also use the notion of "access", unless the user has the ADMIN role, in which case they have access to everything.

	Create Environment	Connect to Environment X	Delete an Environment	Use Management CLIs
ADMIN
NORMAL		If explicitly granted permission
LIMITED		If explicitly granted permission

• Since an ADMIN user can access everything, we won't store their UID in the list of those that can access an environment. A side affect of this is that if an ADMIN user is reduce to a non-admin role, they won't have access to anything unless they did before being promoted to an ADMIN (because I'm assuming we won't delete them from the list of UIDs with access upon promotion) or they're explicitly given access.

New data to store in AccessManager

• Map<String, Short> uids
• Map<String, Set<Short>> access
• Map<Short, Role> roles
• Map<Short, Credential> credentials

Implementation Plan