Within the application, we define two types of security objects:
- Access control list (ACL)
- Proxy
These security objects are used to authorise (or prohibit) an identity to perform an action.
Security objects
Access control list (ACL)
An access control list contains one or more access control entries (ACE
).
In each entry, different permissions are defined for a set of identities (user, group, team).
For example, when a user wants read access to a component, the application will evaluate the read permission according to the ACL carried by the component.
Component classes carry an ACL which is applied by default when a component of this class is created. This ACL can be modified later via integration.
Order of access control inputs (ACE)
The order in which ACE
are defined is important, as it corresponds to the order in which they are evaluated. The first entry corresponds to the user, one of his groups, one of his teams or *, will be the one used to evaluate the various user permissions for a component.
For example, if the first entry has the identity * to view the component, and the second has the identity of the user’s identifier X which does not allow the component to be viewed, the user will be able to view this component.
By inverting the twoACL
entries, all users except user X will be able to see the component.
- When setting up
ACL
, it is advisable not to define entries with the identity *.
Indeed, this would mean that a user who is not part of a group could still have the permissions of theACL
.
It is preferable to add the name of all groups/profiles as an entity.
- It is recommended not to exceed 1000 ACL on a scope.
ACL Proxy
A proxy can be used to define dynamic security based on one or more rules.
Each rule corresponds to a list of conditions and an ACL identifier. If all the conditions of a rule are met, the user’s permissions are determined according to the referenced ACL.
Three types of conditions are supported by the application:
Security object Association
A security object is associated with an object through its ACL
field. This field contains only the ACL identifier. In this way, an ACL can be defined on several components, providing the possibility of managing security policies common to sets of components.
The ACL referenced, for example on a component, will be used to determine whether or not a user is authorised to perform an action on it.
Creating a component is a special case. As this does not yet exist, it is the ACL defined at component class level that is evaluated. To authorise a user to create a component, he or she must have the CREATE
permission on the ACL referenced at class level.