Skip to content

Access Control System

Altair SLC Hub implements a role-based access control system.

A Role is a named entity that has an associated set of permissions. Multiple Hub roles can be associated with users or groups. The combination of user-assigned roles, and roles assigned to any group they are a member of, form the overall permission a Hub user has when accessing an object.

A Role permission associated with a role consists of

  • A string defining the object or objects that the permission applies to (for example, /Groups/Developers, /Users).
  • The action the role can be performed on the object (for example, Create or Read).
  • The effect of performing the action for the role (either Allow or Deny).

A role bound to a user or group can apply to all namespaces or be bound to a single Namespace.

  • If a role is bound to a specific namespace, the permissions only have an effect for access control requests that explicitly reference that namespace.
  • If a role is bound to all namespaces, the permissions have an effect for any access control request, regardless of the namespace it specifies.
    This includes requests that specify no namespace, for example access control requests for non-namespaced entities such as users and groups.

Access control evaluation requests

When a request is made to a service to perform some kind of action, the service will make a request to the access control service to establish whether the requester has permission to perform the action. This request consists of:

  • The action to perform.
  • The object on which the action is performed
  • The namespace, or any, in which the object exists.
  • The user ID and any group IDs of the user making the request.

This information, along with the database of permissions associated with each role, is used to determine whether the request is permitted. An Allow or Deny decision is then returned to the requesting service reflecting whether the user has permission to perform the action.

See Role permission for information about creating permissions for a role.

Access control decision log

All decisions made by the access control service are logged in a searchable log. Each line in the log records the object, action, decision string, user ID, and the timestamp of when the decision was made. This decision log can then be used to understand why a particular action was permitted or denied.

Access Control Request Evaluation

When an access control request is made, the access controller evaluates such a request as follows:

The list of all relevant roles is calculated. For a role to be relevant it must satisfy a number of requirements:

  • There must be a role binding from the role to one of the principals (that is the user, or one of the groups) provided in the access control request
  • The role binding must apply to either all namespaces or the namespace in the access control request.

Then for each relevant role, each permission rule is evaluated to see whether it matches the access control request. For a permission rule to match the evaluation request, both the action pattern and the object pattern have to match the evaluation request.

If any rules match the request and specify a deny result, then the result of the evaluation is a deny decision. Otherwise, if any rules match the request and specify an allow result, then the result of the evaluation is an allow decision.

If no permission rules match the request, the result is a deny decision.

In the case of access control requests that specify a namespace, there is then an additional access control check for the object /Namespace with the action Use in the same namespace. This ensures that the user making the request also has permission to use the given namespace. That is, in order for a user to make use of any entity within a namespace, they require permission to "use" that namespace, as defined by a successful access control check for the object /Namespace with the action Use.

Note that this check is performed in the context of the specific namespace. That is, regardless of the namespace, the check is on the same object string /Namespace, but the check is a "namespaced" access control check, so it only considers role bindings that explicitly specify the relevant namespace, or specify "all namespaces".

So although namespaces themselves aren't namespaced entities, this access control check is a namespaced access control check. This allows definition of a single Role called NamespaceUser that can be used to grant access to any namespace simply by creating a role binding for a user or group and associating the role binding with the relevant namespace.

General Principles

There are some general principles that apply to the access control checks that Hub performs.

Creation of entities

Creation of entities generally uses the action Create on an "entity" path. So for example, creating a Library Definition called Lib1 performs an access control check for the action Create on the path /LibraryDefinitions/Lib1.

Querying entities

In general, when performing a query, only entities that a user explicitly has read access to are returned. That is, there is no specific access control check for "can this user query entities of this type", instead the result set of the query is filtered by whether the user has read access to each entity.

Reading, writing and deleting entities

Reading, writing and deleting entities uses the actions Read, Update and Delete on an "entity" path. For example, returning the definition of a Library Definition called Lib1 performs an access control check for the action Read on the path /LibraryDefinition/Lib1.

The access control request made will also include the namespace in which the Library Definition is contained, so there is then an additional implied access control request for the action Use on the object /Namespace in the given namespace.

For entities that support folders, such as pipelines, returning the definition of a pipeline within a folder performs an access control check for the action Read on a path such as /Pipelines/Folder/Subfolder/Pipeline1.