Page Comparison

Introduction

The security within the the CoreOne Suite is handled by the CoreOne Security Roles. Those roles By default, the CoreOne Suite is deployed with a set of security roles that you can assign to users to perform basic sets of operations. For example there is a Manage Representations security role. If you assign this role to a user, he will be able to see his representations in the CoreOne Self-Service Portal and can delegate some of his responsibilities to others.

This default security role always cover a basic use case and do have some restrictions attached to it. For example the Manage Representations security role only let’s a user delegate something to another Core Identity for which the user first has created a representation. In an eGoverment environment this is a valid use, but in an enterprise environment you might want to enable the user to delegate his permissions to everyone in the company or to co-workers in the same division or any other use case.

This is where the CoreOne Advanced Permission Management comes into place. This optional module allows you to create your own security rules. A security role 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:

...

CoreOne Suite Security Role

...

Access Level inside CoreOne Suite

...

Description

...

CoreOne Suite Administrator

...

Full Access

...

Full access to the whole CoreOne Suite

...

CoreOne Suite Approvals

...

Access to approval requests where the assignee is involved

...

Assign this role to users that need to take part in an approval process.

...

CoreOne Suite Service Desk

...

Access to basic Identity Management and Management Features

...

Can be used to give Service Desk employees basic rights such as seeing all employees, reset passwords and so on.

...

CoreOne Suite Self-Service User

...

Access to the Self-Service Portal

Access to his own Core Identity

Access to his own Identities

Access to orderings and approvals

...

Gives users basic rights to perform actions like resetting the password for his own accounts or ordering a role for himself

When licenced, the “Advanced Permission Management” Module allows you to create your own Security Roles. When doing so, the view permissions and the data access permission within the CoreOne Suite Admin UI can be configured by yourself.

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.

The following filter gives access to all configured attributes in the system:

{
  "$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.

The filter below for example gives access to all role assignments that belong to the current user.

{
  "$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.

For example the filter below gives access to all role assignments where the user has read rights to the role added by the role assignment:

{
  "$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.

The filter below gives access to the role type with ID 9:

{
  "$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.

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

...

Data Access Permissions

Data access permissions are configured by specifying the entity type, a security mode and a security filter. The entity type defines to which entity, i.e. a Core Identity or a Role, a user has access to. The security mode defines the nature of the access such as read, write, delete or similar. And finally the security filter specifies which conditions have to be met in order to give access. This can be anything from full access to only if a specific condition is met. You will find more on that in the Data Access Permissions section. But it’s important to understand that you can configure security filters based on relations and other attributes of the entity.

Security Roles Pitfalls

As we have learned, the security roles are a powerful tool to build various use cases. But there are a few things that need to be considered.

Performance

The more complex the filter get, the more slower the system will be for the user. If no filter is configured for let’s say roles, the user can be served with the list of roles immediately. But if we configure a security filter that only shows roles to a user that match certain criteria, those criteria have to be evaluated at runtime and therefore will take some time. Depending on the amount of roles, the amount of security filters applied and the complexity of the filters, this may be noticeable to the user.

Maintenance

If you build your own custom use case, you might have to combine a few entity rights to cover your use case. For example if you only want to give read rights to roles that are assigned to a specific organizational unit and the user has a specific employment type, you will not only need to give read rights to the roles, but you will also need to give read rights to the users employments, where the employment type of the user is stored. After an update of the Software it is possible that this data structure has changed. For example the employment type of the user might no longer be stored on the employment but on the Core Identity itself. Even tough such changes rarely happen and are documented in the release notes, there is still a chance. So in order to be sure, you should test each of your security role after each update. When designing security roles, you have to take this into account and plan accordingly.

Relying on default roles

If you use any of our default security roles, you have to be aware that they can change. They are intended to cover a standard use case as described in the documentation. But even though that standard use case might match your use case today, does not mean it will automatically match your use case after an update. We might add some rights to the default security rule that will not match your use case, so you should check the release notes carefully.

Creating Custom Security Roles

You can create custom security roles in the Admin UI. Go to Administration -> Securityroles and click create. Make sure to choose a good name for you rule.

This will automatically create a Ressource with the same name. You can use this ressource to assign your new security rule to core identities.

Best practices

Testing, testing, testing

It’s vital that you test your security rules after each update. Create a basic test plan for your most crucial cases and execute them after each update.

Blueprints

If you are planning on creating a lot of security roles that only have minor differences, try to extract the common things into a base security rule and only specify the difference in specific security rules. It might also be useful to create a blueprint, test the blueprint after each update and redeploy all specific rules based on the blue print if you have detected any changes.