Roles

A Role is a named entity that has an associated set of permissions. Roles can be associated with users or groups.

A Permission associated with a role consists of a string defining the object or objects that the permission applies to, and the name of an action that is being permitted.

A role typically has one or more permission rules associated with it. Each permission rule consists of an action string pattern and an object string pattern, as well as a resulting effect, either Allow or Deny.

A role bound to a user or group can apply to a specific namespace or all namespaces.

• 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, then the permissions have an effect on any access control request, regardless of the namespace it specifies.
  This includes access control requests that specify no namespace, including access control requests for non-namespaced entities such as Users and Groups.

The Roles page displays a list of current Altair SLC Hub roles.

The page can be used to create new roles by clicking the New button. Existing roles can be modified by clicking the displayed name. This opens the the Edit Role pages. Clicking the more (...) button at the end of the role row enables the role to be deleted, renamed or duplicated.

Role permissions

The Permissions tab in the This opens the the Edit Role pages displays a list of all permissions associated with the currently selected role.

To add a new permission to the role, click New. Existing roles can be modified or deleted using the more (...) option.

Object

An access control request contains a string identifying the object on which the action is being performed. The defined object for the role can be:

• An exact path-like strings, for example, /Group/Developers or /Pipeline/DailyJobs/ManagementReport.
• An path-like expression that evaluates to one or more defined objects.
  For example, /Groups/* will apply this permission to all groups in the Groups object.

Matcher

A permission can define the object or objects to which the permission applies using a variety of matchers:

• Simple
• Doublestar
• Regular expression
• Hierarchy

Simple matcher

The object string can be specified as an exact string or as a wildcard. This is the default.

Some examples of object patterns:

Pattern	Description
/Groups/*	Matches /Groups/Developers, does not match /Groups
/Pipeline/*	Matches /Pipeline/DailyJobs and /Pipeline/DailyJobs/ManagementReport but not /Pipeline

Doublestar matcher

The doublestar matcher recognises that access control object strings are "file path like", that is, they are made up of a sequence of elements separated by forward slashes.

In the doublestar matcher, the following patterns can be used:

Pattern	Description
*	Matches any sequence of characters, not including the path separator (/)
/**/	Matches zero or more complete "directory" path elements
?	Matches a single character, not including the path separator (/)
[class]	Matches a single character in the given character class, not including the path separator (/)

• When specified, the doublestar pattern must be surrounded by path separators (/).
• To match any object string, specify the /**/* pattern.

The following character classes can be used:

Class	Description
[abc]	Matches a single character in the specified set.
[a-z]	Matches a single character in the specified range.
[!class] or [^class]	Matches a single character not in the given class.

Regular expression matcher

The syntax of the regular expressions accepted by the regular expression matcher is defined in RE2 syntax description.

The regular expression matcher matches the complete object string against the provided regular expression. That is, the matcher adds beginning of string and end of string anchors to the provided regular expression.

Hierarchy matcher

The hierarchy matcher recognises that access control object strings are "file path like", that is, they are made up of a sequence of elements separated by forward slashes.

The hierarchy matcher treats both the pattern string and the provided object string as path like strings. A match is retured if the object string is equal to, or a child path of the pattern string.

For example:

Pattern	Object string	Match
/Pipelines	/Pipelines	yes
/Pipelines	/Pipelines/Pipeline1	yes
/Pipelines/Folder	/Pipelines/Folder/Pipeline1	yes
/Pipelines/Folder	/Pipelines/Folder1/Pipeline1	no

Actions

An access control evaluation request contains a string giving the action that is being attempted. Action strings are conventionally single words. Each service defines its own set of action strings, but typical action strings are:

• Create
• Read
• Update
• Delete

Action specification

Permissions can define the actions to which the permission applies either as an exact string, or as a wildcard (*) that matches any action. The asterisk wildcard can be used and added to a string as suffix (for example. Read*) if a partial string match is required.

Effect

Specifies the outcome of an evaluation request for the role using the defined permission. The effect can be:

• Allow: A user to whom this role is attached can carry out the specified action against the identified object.
• Deny : A user to whom this role is attached is not permitted to perfom the specified action against the identified object.

For a permission rule to match the evaluation request, both the specified action and the object pattern have to match the evaluation request.

Role bindings

The Role Bindings tab in the Edit Role pages displays a list of the Hub users and groups associated to this role.

The list displays whether the binding applies to all namespaces or a specific namespace.