A role manages the availability of functionality in automaIT, i.e. a user may only use a functionality if he is authorized to do so. Otherwise the functionality is hidden, disabled or an error is shown.
The following static roles are available. These are part of the application and cannot be changed.
|ROLE_ADMIN||Application privilege||super user privileges|
|ROLE_HOST_ADMIN||Application privilege||host administration privileges: create, modify, delete hosts. Assign host types and host specific values.|
|ROLE_HOST_INITIALIZATION||Application privilege||host initialization privileges|
|ROLE_MODEL_DEVELOPER||Application privilege||model administration privileges: patch plans, components, and plug-ins. Import and delete host sets and host searches. Manage host types.|
|ROLE_MODEL_CONFIGURATOR||Application privilege||model configuration privileges: create, edit, and delete variable sets.|
|ROLE_MODEL_EXECUTOR||Application privilege||model execution privileges: run plans, install, run, and uninstall components, and execute control methods.|
|ROLE_JOB_CANCELLATION||Application privilege||job cancellation privilege: may not only cancel own jobs but also those jobs started by any other users.|
|ROLE_SECURITY_ADMIN||Application privilege||security administration privileges: create and deactivate users and create, assign, and delete roles and groups.|
|ROLE_AUTHORIZED_WEB_USER||Application access||web access|
|ROLE_AUTHORIZED_CLI_USER||Application access||CLI access|
Custom roles are currently not supported.
The following diagram shows that the role ROLE_ADMIN aggregates all other roles, i.e. a user having the role ROLE_ADMIN implicitly has all other roles.
User Role Aggregation
Persistent role mapping
Whenever a authenticated successfully (either using an external provider or the automaIT database) the application determines for which the user is authorized. A user may have multiple directly assigned roles. Additionally, the user may be part of multiple groups. In the case of a group assignment the user inherits all roles associated with the group.is
In this case the user has global authorization for the given role. Folder specific authorization is described below.
Non-persistent role mapping
If authentication is configured to use an external provider then the external authorities of the user (e.g. from LDAP) may be mapped to internal roles. This may configured using the XML element "authority-role-mapping". The configuration of an external authentication provider is detailed in User Authentication Configuration.
External authorities may also be mapped to internal groups. This is analogue to "Mapping authorities to internal roles" but the element is called "authority-group-mapping".
The evaluation of the mapped roles is done once at the login. If new roles are assigned or revoked during a logged in user session then the changes will take effect on the next login.
The current user's effective roles can be determined by clicking on the user's name. This is placed in the top right hand corner of the automaIT web application.
As described above a user may have one or more roles assigned globally. This section describes folder specific authorization which allows a more granular security concept.
Folder permissions may be used in the following scenarios:
- The group "development" may configure and execute model elements below the folder /development
- The user "alice" may execute all model elements except those below the folder /development
- No-one but user "bob" may execute model elements below /development/bob, not even those users which have global execution rights.
The following roles are folder dependent and may therefore be assigned as folder permissions:
|Role||Custom (UI) Folder Permission||Plug-in Descriptor||Host Set Limitation|
|ROLE_MODEL_DEVELOPER||Not yet implemented|| Not available|
Plans and components in plug-in owned folders cannot be edited.
| Not available|
Host context does not exist.
|ROLE_MODEL_CONFIGURATOR||Not yet implemented||Available|
|ROLE_MODEL_EXECUTOR||Not yet implemented||Available|
Folder permissions may be assigned to the following authorities:
These entities are evaluated in order, i.e. user specific folder permissions will always dominate over group specific folder permissions. Group specific folder permissions will in turn dominate over folder specific permissions granted to everyone.
The access type defines if a folder permission grants a permission ("ALLOW") or revokes it explicitly ("DENY").
The following access types are available:
- ALLOW: The user/group/everyone is granted access for the given role if it has not been explicitly denied.
- DENY: The user/group/everyone is revoked access for the given role.
Inheriting Folder Permissions
If a folder does not explicitly define a folder permission for a given user and role then it inherits the permissions defined by the folder above. This inheritance is recursive.
If the root folder does not define a folder permission for a given user and role then the permissions are taken from the user as described in User Role Aggregation.
The following rules are applied to determine if the user has access to a folder:
- If the user has explicit folder permissions then these are evaluated. The evaluation considers that a DENY dominates over an ALLOW folder permission.
- Otherwise, if the group has explicit folder permissions then these are evaluated. The evaluation considers that a DENY dominates over an ALLOW folder permission.
- Otherwise, if 'everyone' has explicit folder permissions then these are evaluated. The evaluation considers that a DENY dominates over an ALLOW folder permission.
- Otherwise, rules 1 to 3 are applied recursively to the parent folder.
- Otherwise, if no folder permissions exist then the global user permissions are evaluated.
In simple environments which only use ALLOW access determining folder permissions is easy: a user has access if global access or access to a folder or any of its parents is granted.
In more complex environments which also use DENY access determining folder permissions is more complicated because the order of evaluation is decisive.
This example given in the scenarios above would require the following permissions:
|Folder||Role||Access Type||Authority Type||Authority Name||Note|
|The group "development" may configure and execute model elements below the folder /development|
The user "alice" may execute all model elements except those below the folder /development
|/development||ROLE_MODEL_EXECUTOR||DENY||User||alice||Additionally, the user "alice" should have the role ROLE_MODEL_EXECUTOR assigned.|
|No-one but user "bob" may execute model elements below /development/bob, not even those users which have global execution rights.|
This is the corresponding plug-in descriptor:
The elements are described in the Model Schema Reference.
Automatic user creation
If a user authenticates successfully the authorization is only possible if the user is registered in automaIT. In the case of external authentication it is possible to configure the automatic creation of a user with a set of default roles. This may be configured using the element "user-creation" of the external authentication provider which is detailed in User Authentication Configuration.