User Management Access Control Service 6.0.1

The eitco access control service extends the eitco user management service with the possibility to specify access control. Access control lists (ACLs) are used for this purpose.

The Concept of Access Control Lists

An ACL assigns rights and prohibitions to users and groups. Normally, ACLs are then assigned to objects. How ACLs are assigned to objects and what rights exist is not defined in the module user-management-access-control. However, there are requirements for the rights concept of the applications that use this component:

  • Rights and prohibitions share the same value range. You can only forbid what you can allow and vice versa.

  • The rights are fully ordered and imply their respective subordinate rights. That is, there is a clear hierarchy of rights. If someone has a right, then he also has all the rights that are smaller.

  • Even the smallest right implies access. Once someone has rights on an object, they will be able to find it in searches. With these requirements, the permissions of a user on an ACL can be calculated as described below.

Let G be the set of all permissions assigned to a user (directly or indirectly via the groups he is in) in the ACL.
Let D be the set of all prohibitions assigned to a user (directly or indirectly via the groups he is in) in the ACL.

If max(D) > max(G), then the user has the permission max(G); otherwise the user has the permission max(D) - 1.

So generally, the greater the value of an ACL, the more rights this group or job position possesses. If no ACL is assigned to an object, then it is accessible to everyone.

It is possible to prohibit all rights on an object, but then nobody would have access to it making it effectively removed.

Substitution

In order to implement concepts such as substitutions or extensions (i.e. group memberships that propagate authorisations but not prohibitions), the rights determination must be adapted. In addition, an extension of the user service is required.

Weak group membership

Group memberships of users require the information whether they are "weak". Weak affiliations only propagate permissions, never prohibitions.

The permissions of a user on an ACL would then be calculated as follows:

Let S be the set of all groups to which the user is strongly (i.e. not weakly) connected.
Let S' be the set of all groups to which the user is weakly connected.

Let G be the set of all permissions assigned to the groups in S in the ACL.
Let D be the set of all prohibitions assigned to groups in S in the ACL.

For all s_i in S', now calculate the permissions g_i as follows:

    Let G' be the set of all permissions assigned to groups in S in the ACL.
    Let D' be the set of all prohibitions assigned to the groups in S in the ACL.

    If max(D') > max(G'), then g_i = max(G')
    otherwise g_i = max(0, max(D') - 1)

Let G' be the set of all calculated permissions g_i

If max(D) > max(G + G'), then the user has the permission max(G + G'); otherwise the user has the permission max(D) - 1

Usage of the Access Control Service in an application

The client application has to be a Spring boot application. It can connect to the service in two ways:

By http

In this case, add the maven dependency below to your project:

Maven dependency for the http Spring starter
<dependency>
    <groupId>de.eitco.commons</groupId>
    <artifactId>cmn-user-management-access-control-http-client-spring-boot-starter</artifactId>
    <version>6.0.1</version>
</dependency>

Embedded

For this, use the following maven dependency:

Maven dependency for the embedded starter
<dependency>
    <groupId>de.eitco.commons</groupId>
    <artifactId>cmn-user-management-access-control-embedded-spring-boot-starter</artifactId>
    <version>6.0.1</version>
</dependency>

ACL Data Model

An Access Control List (ACL) or “Access Control List” is used to restrict access to a data object. ACLs consist of entries, called Access Control Entries, each of which describes an access rule in more detail. For example, an entry can grant access to a specific object (for example a file in a file system; the respective ACL is assigned to this) for a specific user (or a group of users) to an access level (for example "View only" or " Edit ").

Attribute Based Access Control provides access based on the evaluation of attributes. DAC In the Discretionary Access Control (DAC) model, access to resources is based on user’s identity. A user is granted permissions to a resource by being placed on an access control list (ACL) associated with resource. An entry on a resource’s ACL is known as an Access Control Entry (ACE). When a user (or group) is the owner of an object in the DAC model, the user can grant permission to other users and groups. The DAC model is based on resource ownership.

Solr ACL Filter

The SOLR ACL Plugin extends SOLR with ACL checking functionality. The goal of the extension is that all documents that are invisible to a user based on their ACLs will be filtered from the search results from SOLR. An EQL extension is used to specify the required parameters for the filter. The parameters are:

  • The ID of the user

  • The ACL assignment ID of the user

  • The numeric value of the required ACL right

The extension uses the resolved ACL rights managed by the Access Control Service. The SOLR EQL implementation will add a filter query to the SOLR search request as shown below. More information about the query extension and usage examples can be found in the EQL documentation.

{!aclright userId=111 aclAssignmentId=222 granted=3}

Configuration

To enable the plugin in SOLR, add the following lines to solrconfig.xml:

<queryParser name="aclright" class="de.eitco.commons.user.management.access.control.solr.AclRightParserPlugin">
    <str name="jdbcUrl">jdbc-url</str>
    <str name="jdbcUser">user</str>
    <str name="jdbcPassword">password</str>
</queryParser>

The plugin requires a database connection to access the tables of the Access Control Service. For this purpose, a JDBC connection has to be configured.

Caching

The plugin caches the resolved rights on a per-user-and-document level. It is assumed that this cache can get very big, because of which the ACL assignment ID of the user is used to check if the cache entry is up to date. If not, is is evicted immediately and the current value is loaded from the database.