Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 34 Next »

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:

CoreOne Suite Security Role

Access

Desciption

CoreOne Suite Administrator

Full Access

Gives full access to the whole system

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.

View Permissions

The view permissions follow a basic naming concept which should indicate what they represent in the UI.

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

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.

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 the ownership. You can apply this filter to all entities that have a relation to a Core Identity and the filter on that property to only allow the permission 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 of 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"
    ]
  }
}
  • No labels