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, initialize and delete hosts. Assign host types and host specific values.|
|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. Authorization through Access Control Lists 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.
Access Control Lists
As described above a user may have one or more roles assigned globally. This section describes business object specific authorization which allows a more granular security concept.
Access Control Lists may be used in the following scenarios:
- Everyone in the group "development" except user "alice" may configure and execute model elements below the folder /development.
- The user "bob" may execute all model elements except those below the folder /development.
- The user "carol" may execute the plan /development/doSomeStuff on all hosts except those in host set "development#production".
- The user "dave" may execute the control methods of the component /development/someComponent#1.0, but may not install or uninstall it.
Administrable business objects
The following business objects are subject to ACL permission checking
- Folder (including the root folder)
- Plan (versioned and unversioned)
- Component (versioned and unversioned)
- Component Method (unversioned)
While the root folder is basically also a regular folder it plays a special role for assigning initialize permissions and global permissions.
A business object inherits the permissions defined by its parent object if it does not explicitly define an ACL permission for a given set of user, permission, and host set.
This inheritance is recursive. If the root folder does not define a matching ACL permission then the operation is rejected.
Hierarchical relations of business objects can be seen in the diagram to the right.
The following permissions are available in ACLs and may therefore be assigned on business objects:
|Role||Validity and granted rights on business objects||Host Set Limitation|
Folder, Plan, Component, Component version
Plan version, Component method
Plan, Plan version, Component version, Component method
Plan version, Component version, Component method
Folder, Plan, Plan version, Component, Component version, Component method
If a host set limitation is set the ACL permission only applies if the current host is contained in that host set.
ACL permissions may be assigned to the following authorities:
The access type defines if an ACL permission grants a permission ("ALLOW") or revokes it explicitly ("DENY").
The following access types are available:
- ALLOW: The user/group is granted access for the given operation.
- DENY: The user/group is revoked access for the given operation.
Certain Access Control Entries have priority over other ones. This means when two entries declare conflicting permissions, a fixed order defines which one prevails.
This can be useful when:
- Granting rights for a group but withdrawing them for single users
- Granting global execute or initialize access on an object and afterwards withdrawing them for single host sets.
The order is as follows:
- User permissions always prevail over group permissions.
- Permissions for specific host sets always prevail over permissions with no host set specified.
- Permissions that deny access always prevail over permissions that allow access.
The order of this hierarchy is binding. This means a user entry will always prevail over a group entry, even if the user entry is allowing and the group entry is denying permission.
The table on the right illustrates which entry would prevail over another and which rule would be responsible for the decision.
Two roles have supremacy over defined ACL permissions:
- ROLE_ADMIN is always allowed to perform any action, no matter what ACLs have been defined. Users with ROLE_ADMIN privileges cannot be denied any actions through ACLs.
- ROLE_HOST_ADMIN is always allowed to perform host initializations.
|Object||Authority||Host Set Limitation||Access Type|
Access Control Lists and component inheritance
When extending another component, the permissions of the super component apply for all methods that have not been overridden. This means for those methods the hierarchy of the super component still apply and they are not affected by any permissions set on the child component. Permissions for such methods cannot be changed individually on the child object. To administrate permissions individually on child level methods can be overridden with a call to the super method, as in the following example.
This way, the method "doSomething" can be assigned individual permissions not influenced by the method doSomething in component superComponent.
The following rules are applied to determine if the user has access to an object through ACLs:
- If the user has an explicit ACL entry for business object, then this one is evaluated. The evaluation selects the most relevant entry using a fixed order.
- Otherwise, the previous rule is applied recursively to the parent object.
- Otherwise, if no matching ACL entry exists then the operation is rejected.
In simple environments which only use ALLOW access determining ACL permissions is easy: a user has access if global access (access on root folder) or access to a business object or any of its parents is granted.
In more complex environments which also use DENY access determining ACL permissions is more complicated because the order of evaluation is relevant.
This example given in the scenarios above would require the following permissions:
|Element||Permission||Access Type||Host Set Limitation||Authority Name|
|Everyone in the group development except user alice may configure and execute model elements below the folder |
The user bob may execute all model elements except those below the folder
The user carol may execute the plan
The user dave may execute the control methods of the component
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.
Reenable deactivated users
Using the web interface, registered users can be deactivated by a user who owns the user role ROLE_ADMIN or ROLE_SECURITY_ADMIN. Yet, there is no functionality to reactivate such users. As a workaround users can be reactivated directly in the database using the following SQL statement (Remember to change <username> to the name of the disabled user):
Users may only be reactivated, if no other active user with that name (case-insensitive) exists. Otherwise a duplicate key value violation will be thrown.