Page Comparison

Introduction

The security within the the CoreOne Suite is handled by the CoreOne Security Roles. Those roles contain two things, the view permissions and the data access permission. The view permissions are used across all UIs to handle who has access to which views and which actions. The access permissions are used to determinate what data is available to the user or service within the views or APIs. This way you can give certain users access to view and limit them to a subset of the available data.

Those CoreOne Suite Security Roles are application roles. As such they will be represented as resources within the CoreOne Suite Access Management logic.

Built-In Security Roles

Out of the box the CoreOne Suite is deployed with four built-in security roles:

...

Starting from version 7, there are also fine granular security roles available which give you the ability to build your own roles more easily. Those granular security roles cover specific use cases such as “Register a legal entity”. Behind that role, all the necessary vier and data access permissions are stored. Those role are maintained by us.

View Permissions

The view permissions follow a basic naming concept which should indicate what they represent in the UI. When creating a new security role in the CoreOne Admin UI, you can simply select the entries that you would like the users to see.

Data Access Permission

Data Access Permission are stored as sets of entity permission. Each such permission consists of three things. The entity where access is given to, the security mode and a filter.

Entity Type

An entity is any object within the CoreOne Suite Meta Directory. From a Core Identity to a Target System Configuration, everything is stored in an entity and can therefore be selected. All available entities are presented to you in the UI and they follow the same logic naming as all the UI masks do.

Entity Type Default Rights

Each entity type has default rights attached to it. In the security_entity_type entity, 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 wich actions are allowed on the entity where access is given to. The available rights are:

• Read

• Write

• Update

• Delete

• All

Filter

If you do not set a filter, the chosen security mode is applied to all entities. If you set one, you can further filter the entities to which the current permission will apply to. To do so, there are a couple of filters available. If you apply them, the data will be filtered according to the filter configuration.

GenericFullAccessFilter

When applied, this filter gives full access to all entities.

...

{
  "$type": "iTsense.Moving.Backend.DataHandling.Security.Filter.GenericFullAccessFilter`1[[iTsense.Moving.Backend.Services.DmcoreService.DataInterfaces.Servicedmcore.IAttribute, iTsense.Moving.Backend.Services.DmcoreService]], iTsense.Moving.Backend.DataHandling",
  "ElementType": "iTsense.Moving.Backend.Services.DmcoreService.DataInterfaces.Servicedmcore.IAttribute, iTsense.Moving.Backend.Services.DmcoreService"
}

GenericMyCoreIdentityFilter

When applied, you can filter entities based on their ownership. You can apply this filter to all entities that have a relation to a Core Identity. The filter on that property then only allows the permitted action to be applied when the current Core Identity is the owner of the object.

...

{
  "$type": "iTsense.Moving.Backend.DataHandling.Security.Filter.GenericMyCoreIdentityFilter`1[[iTsense.Moving.Backend.Services.DmcoreService.DataInterfaces.Servicedmcore.IRoleAssignment, iTsense.Moving.Backend.Services.DmcoreService]], iTsense.Moving.Backend.DataHandling",
 "NotContains": false,
   "PropertyChain": {
    "$type": "System.String[], mscorlib",
   "$values": [
      "Role",
     "CoreIdentity",
     "Id"
      ]
 }
}

GenericNoAccessFilter

Denies access to all entities.

GenericSubFiltersFilter

Gives access to entities if a subset of filters apply.

...

{
  "$type": "iTsense.Moving.Backend.DataHandling.Security.Filter.GenericSubFiltersFilter`2[[iTsense.Moving.Backend.Services.DmcoreService.DataInterfaces.Servicedmcore.IRoleAssignment, iTsense.Moving.Backend.Services.DmcoreService],[iTsense.Moving.Backend.Services.DmcoreService.DataInterfaces.Servicedmcore.IRole, iTsense.Moving.Backend.Services.DmcoreService]], iTsense.Moving.Backend.DataHandling",
  "ReferenceDtoTypePropertyName": "Role",
  "ReferenceDtoTypeSecurityMode": 1
}

GenericPropertyChainFilter

Gives access to the selected entity if the chain of properties configured in the filter match.

...

{
  "$type": "iTsense.Moving.Backend.DataHandling.Security.Filter.GenericPropertyChainFilter`2[[iTsense.Moving.Backend.Services.DmcoreService.DataInterfaces.Servicedmcore.IRoleType, iTsense.Moving.Backend.Services.DmcoreService],[System.UInt32, mscorlib]], iTsense.Moving.Backend.DataHandling",
  "FilterValues": {
    "$type": "System.UInt32[], mscorlib",
    "$values": [
      9
    ]
  },
  "NotContains": false,
  "PropertyChain": {
    "$type": "System.String[], mscorlib",
    "$values": [
      "Id"
    ]
  }
}

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.

...

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.