Child pages
  • User Authorization
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.

ROLE_ADMINApplication privilegesuper user privileges
ROLE_HOST_ADMINApplication privilegehost administration privileges: create, modify, initialize and delete hosts. Assign host types and host specific values.
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. Authorization through Access Control Lists 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.

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:

  1. Everyone in the group "development" except user "alice" may configure and execute model elements below the folder /development.
  2. The user "bob" may execute all model elements except those below the folder /development.
  3. The user "carol" may execute the plan /development/doSomeStuff on all hosts except those in host set "development#production".
  4. 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.

Available Permissions

The following permissions are available in ACLs and may therefore be assigned on business objects:

RoleValidity and granted rights on business objectsHost Set Limitation

(tick) Folder, Plan, Component, Component version
Execute plans and component methods that descend from this object

(tick) Plan version, Component method
Execute this plan or component method

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


(tick) Folder, Component
Add, edit, and delete variable sets on components

(error) Plan, Plan version, Component version, Component method

(error) Not available
Host context does not exist.


(tick) Folder
Import plans and components, add and delete plan and component versions

(tick) Plan, Component
Add and delete plan and component versions

(error) Plan version, Component version, Component method

(error) Not available
Host context does not exist.


(tick) Root folder
Initialize hosts. Is used to limit initialization of hosts to certain host sets.

(error) Folder, Plan, Plan version, Component, Component version, Component method

(tick) Available
If a host set limitation is set the ACL permission only applies if the current host is contained in that host set.
Business Object Hierarchy

acl business object hierarchy

The hierarchical relations of business objects in automaIT.

Available Authorities

ACL permissions may be assigned to the following authorities:

  1. User
  2. Group

Access type

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.


ACL Priorities

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:

  1. User permissions always prevail over group permissions.
  2. Permissions for specific host sets always prevail over permissions with no host set specified.
  3. 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.
ObjectAuthorityHost Set LimitationAccess Type
Child object (tick)Group-ALLOW
Parent objectUserexamples#hostSet


same objectUser (tick)-ALLOW
same objectGroupexamples#hostSetDENY
same objectUserexamples#hostSet (tick)ALLOW
same objectUser-DENY
same objectUserexamples#hostSetDENY (tick)
same objectUserexamples#hostSetALLOW

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.

Example - call to super component
<component name="someComponent" path="/development" description="Inherits from superComponent">
		<component name="superComponent"/>
	<control name="doSomething" access="PUBLIC">
		<call blockName="doSomething">
		    <superComponent />

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:

  1. 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.
  2. Otherwise, the previous rule is applied recursively to the parent object.
  3. 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:

ElementPermissionAccess TypeHost Set LimitationAuthority Name
Everyone in the group development except user alice may configure and execute model elements below the folder /development.
/developmentexecute, configureALLOW development
/developmentexecute, configureDENY alice

The user bob may execute all model elements except those below the folder /development.

/executeALLOW bob
/developmentexecuteDENY bob


The user carol may execute the plan /development/doSomeStuff on all hosts except those in host set development#production.

/development/doSomeStuffexecuteALLOW carol


The user dave may execute the control methods of the component /development/someComponent#1.0, but may not install or uninstall it.

/development/someComponent#1.0executeALLOW dave
/development/someComponent#1.0:constructorMethodexecuteDENY dave
/development/someComponent#1.0:destructorMethodexecuteDENY dave

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):

UPDATE users SET disabled=0, disabled_at=NULL WHERE disabled !=0 AND name = '<username>';

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.

  • No labels