Introduction

With the CoreOne Authentication Service, permissions are represented as role_claims. Those role_claims are a simple text representation of something, the relying party will understand. A simple example is a role_claim with the content “Administrator” which will indicate to the relying party, that the current user is an “Administrator”. Those role_claims can be created within the CoreOne Suite Admin UI and simply follow the requirements of the relying party.

The CoreOne Suite also allows for context aware resource assignments. This means, in addition to simply be in the possession of a permission like a role_claim, the possesion can have a context. The context itself can be various things like I posses this permission for another user or in the context of an organization or company.

A few examples:

• John has the permission to read his own taxes in the tax application → no context

• John has the permission to read Sallys taxes in the tax application → user context of Sally

• John has the permission to read the taxes of ITSENSE in the tax application → organizational context of ITSENSE

Permission without a context are simply published in the tokens roles claim by default. Permissions with a context can be requested by requesting the roles_with_context.

roles_with_context

Whenever you are requesting the roles_with_context claim, the token will be extend with the appropriate data. Instead of simple string array, you will get a complex object as shown below:

By default it contains the following date

role The name of the permission / right

Context A complex object

Context Transformations

By default the internal IDs of the context objects are published in the token. So the combination of the ContextObjectType and ContextObjectIdentitfier of the example above point to the CoreOne Suite user with ID 3. Most applications will not be able to process that information. Therefore a context transformation can be configured to transform that data to something, an application will understand. For example could a transformation be applied that will resolve the ID 3 of the user to a username or a tax identifier number. This can be done with an Assignment context transformations.