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