Child pages
  • User Authorization

This is the documentation of the release 2.1 of automaIT. The documentation of the latest stable release can be found at AUTOMAIT.

Skip to end of metadata
Go to start of metadata

Application roles

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.

RoleTypeDescription
ROLE_ADMINApplication privilegesuper user privileges
ROLE_HOST_ADMINApplication privilegehost administration privileges: create, modify, delete hosts. Assign host types and host specific values.
ROLE_HOST_INITIALIZATIONApplication privilegehost initialization privileges
ROLE_MODEL_DEVELOPERApplication privilegemodel administration privileges: patch plans, components, and plug-ins. Import and delete host sets and host searches. Manage host types.
ROLE_MODEL_CONFIGURATORApplication privilegemodel configuration privileges: create, edit, and delete variable sets.
ROLE_MODEL_EXECUTORApplication privilegemodel execution privileges: run plans, install, run, and uninstall components, and execute control methods.
ROLE_JOB_CANCELLATIONApplication privilegejob cancellation privilege: may not only cancel own jobs but also those jobs started by any other users.
ROLE_SECURITY_ADMINApplication privilegesecurity administration privileges: create and deactivate users and create, assign, and delete roles and groups.
ROLE_AUTHORIZED_WEB_USERApplication accessweb access
ROLE_AUTHORIZED_CLI_USERApplication accessCLI access

Custom roles are currently not supported.

Role hierarchy

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.

Role Hierarchy

User Role Aggregation

Persistent role mapping

Whenever a user is authenticated successfully (either using an external provider or the automaIT database) the application determines for which roles 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.

In this case the user has global authorization for the given role. Folder specific authorization is described below.

User, Role and Group

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.

Folder Permissions

Available Roles

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.

Example

Folder permissions may be used in the following scenarios:

  1. The group "development" may configure and execute model elements below the folder /development
  2. The user "alice" may execute all model elements except those below the folder /development
  3. 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:

RoleCustom (UI) Folder PermissionPlug-in DescriptorHost Set Limitation
ROLE_MODEL_DEVELOPER(warning) Not yet implemented(error) Not available
Plans and components in plug-in owned folders cannot be edited.
(error) Not available
Host context does not exist.
ROLE_MODEL_CONFIGURATOR(warning) Not yet implemented(tick) Available

(error) Not available
Host context does not exist.

ROLE_MODEL_EXECUTOR(warning) Not yet implemented(tick) Available

(tick) Available
If a host set limitation is set the folder permission is only evaluated if the current host is contained in that host set.

Available Authorities

Folder permissions may be assigned to the following authorities:

  1. User
  2. Group
  3. Everyone

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.

Access type

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.

Summary

The following rules are applied to determine if the user has access to a folder:

  1. If the user has explicit folder permissions then these are evaluated. The evaluation considers that a DENY dominates over an ALLOW folder permission.
  2. Otherwise, if the group has explicit folder permissions then these are evaluated. The evaluation considers that a DENY dominates over an ALLOW folder permission.
  3. Otherwise, if 'everyone' has explicit folder permissions then these are evaluated. The evaluation considers that a DENY dominates over an ALLOW folder permission.
  4. Otherwise, rules 1 to 3 are applied recursively to the parent folder.
  5. 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.

Example

This example given in the scenarios above would require the following permissions:

FolderRoleAccess TypeAuthority TypeAuthority NameNote
The group "development" may configure and execute model elements below the folder /development
/developmentROLE_MODEL_CONFIGURATORALLOWGroupdevelopment 
/developmentROLE_MODEL_EXECUTORALLOWGroupdevelopment 

 

The user "alice" may execute all model elements except those below the folder /development

/developmentROLE_MODEL_EXECUTORDENYUseraliceAdditionally, 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.
/development/bobROLE_MODEL_EXECUTORDENYEveryone  
/development/bobROLE_MODEL_EXECUTORALLOWUserbob 

 

This is the corresponding plug-in descriptor:

plugin-descriptor.xml
<plugin ...>
    <memberList>
        <!-- Scenario 1 -->
        <folder name="/development">
            <permission role="ROLE_MODEL_CONFIGURATOR" access="ALLOW" group="development" />
            <permission role="ROLE_MODEL_EXECUTOR" access="ALLOW" group="development" />
        </folder>
        
        <!-- Scenario 2 -->
        <folder name="/development">
            <permission role="ROLE_MODEL_EXECUTOR" access="DENY" user="alice" />
        </folder>
        
        <!-- Scenario 3 -->
        <folder name="/development/bob">
            <permission role="ROLE_MODEL_EXECUTOR" access="DENY" />
            <permission role="ROLE_MODEL_EXECUTOR" access="ALLOW" user="bob" />
        </folder>
    </memberList>
</plugin>

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.

 

  • No labels