Introduction

To handle who can access what entity in the CoreOne Suite, we introduced data access permission handling.

Based on security filters we can configure access to all entities that are stored in the database.

There are different types of security filters to achieve a high grade in flexibility to build different use cases for entity-level access.

There are security filters that work on all entities and some that work only for specific types.

• Generic Filters

• Core Identity Filter

• Role Filter

Entity Type

All possible types that advanced permission management can handle are stored in the security_entity_type table.

Entity Type Default Rights

Each entity type has default rights attached to it. In the security_entity_type table, you will find a property called default_security_rights. This property defines the default rights that will be applied to all users.

For example, the IResourceAssignment entity has a GenericNoAccessFilter defined, meaning no one has access to it by default. On the other hand, the ICoreIdentity entity has a GenericMyCoreIdentityFilter defined, meaning everyone is allowed to read their own Core Identity by default.

Security Mode

The security mode defines which actions are allowed on the entity where access is given. The available rights are:

• Read

• Write

• Update

• Delete

• All

Current Limitations

If we combine view with data permissions we can achieve various advanced use cases. But there are some limitations to this.

Update Limitations

If you have an entity like let’s say a ICoreIdenity, this entity contains a list of defines IAttributeValues. With the data permission you can give users Read rights to all attribute values and only Update rights to certain attributes. On a data level this will work and will be checked by the Advanced Permission Handling. But there are two limitations.

Most of the UI interfaces can not handle the attribute permissions yet. This means, if you edit an ICoreIdentity you will be able to edit all attribute values, regardless of the actual permissions. If you click save, you will get an appropriate error message from the backend.

In some cases the business logic is not executed in the context of the user, but in the context of the system. In those cases the limitation of the UI will lead to a situation where the user actually can save data. So whenever you create a new security role and you would like to limit the edit of specific attributes keep this in mind and test it carefully. However if you configure the Updatable on the attribute itself, everything will work as expected.

Relations

If you give view permission for the Identity Detail page and grant data permissions to all identities, you might still not be able to load the appropriate view. Because the detail page displays more than just the entity, you might need to give access to certain relations. For example an IIdentity has many relations to the ITargetSystem, the IIdentityType, the IProvisioningConfiguration and so on. Depending on the view and the use case, you might need to give access to those relationships.