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 2 Next »

Introduction

The CoreOne Suite offers an extensive access management. In the domain of this access management, permissions are called resource assignments. So whenever an administrator is assigning a resource in the Admin UI, when a user receives resources through a assignment rule, or someone uses the self-service portal to delegate a service permission or a service permission of a company to someone else, those permissions are stored in the access management space as resource assignments.

From here, those resource assignments are then provisioned to the CoreOne Authentication Service. While provisioning, assignment context and other transformations can be applied. With those transformations, application specific information can be added. Whenever a user then authenticates himself for a given application, those provisioned resource assignments are exposed to the application as part of the access token. This is either through the roles or the roles_with_context claim. The later is used whenever a resource assignment has a context. For example someone has the right to submit taxes for the company ITSENSE. The company ITSENSE represents the context.

There are use cases where those permission need to be available to the application even if the user is not present (offline access) or if the application needs to know permissions of other users or other entities (companies, users). In those cases, the permission API of the CoreOne Authentication Service can be used.

Base URL

The base URL for the permission API is as following:

{authentication service url}/api/permission

Authentication

In order to access the API, you will need to configure an appropriate client of the CoreOne Suite application and assign the cos_auth_api scope. Additionally you will need an appropriate user with permissions to access the data. Authentication then is done by passing a bearer token in each request.

Data Objects

Permission

All the endpoints return a permission object which looks as following:

{
    "$type": "iTsense.CoreLogin2.Server.API.Models.PermissionApiDto, iTsense.CoreLogin2.Server",
    "username": "max@dax.ch",
    "userId": 17173,
    "role": "TrusteeApp_AddBill",
    "application": "Trustee Test Application",
    "contextType": "OrganizationUnit",
    "contextObjectIdentifier": "5445"
}

Property

Data Type

Example

Description

$type

String

"iTsense.CoreLogin2.Server.API.Models.PermissionApiDto, iTsense.CoreLogin2.Server"

Identifies the type of the object

username

String

"max@dax.ch"

The username of the user that holds the permission

userId

String

17173

The userId of the user that holds the permission

application

String

"Trustee Test Application"

The name of the application to which the permission belongs

contextType

String

"OrganizationUnit"

Defines the context type as documented here. So it's either "OrganizationUnit", "User" or "All"

contextObjectIdentifier

String

"5445"

The identifier of the context object. In this case, the internal ID of the organization unit / company. Note that you can transform this data with a context transformation.

Use Cases

For our use cases we have trustee management app, where a user can add, remove and approve bills. So the application has three rights: add, remove and approve.

Read who has rights for a user

If you would like to read who is representing a specific user (Peter Pan, 17175), you can perform the following query.

{authentication service url}/api/permission?contextType=User&contextObjectIdentifier=17175&application=trusteeApp

Property

Data Type

Example

Description

contextType

String

User

Set this to User as you are interested in representations for a user

contextObjectIdentifier

String

17175

This is dependent on how the user is stored. By default it’s the user id. But if any token transformation has been applied, this might also be the users email or any other unique attribute.

application

String

trusteeApp

The name of the application to which the permission have to belong

Example result

[
    {
        "$type": "iTsense.CoreLogin2.Server.API.Models.PermissionApiDto, iTsense.CoreLogin2.Server",
        "username": "peter@pan.de",
        "userId": 17175,
        "role": "TrusteeApp_AddBill",
        "application": "trusteeApp",
        "contextType": "User",
        "contextObjectIdentifier": "17175"
    },
    {
        "$type": "iTsense.CoreLogin2.Server.API.Models.PermissionApiDto, iTsense.CoreLogin2.Server",
        "username": "peter@pan.de",
        "userId": 17175,
        "role": "TrusteeApp_RemoveBill",
        "application": "trusteeApp",
        "contextType": "User",
        "contextObjectIdentifier": "17175"
    },
    {
        "$type": "iTsense.CoreLogin2.Server.API.Models.PermissionApiDto, iTsense.CoreLogin2.Server",
        "username": "peter@pan.de",
        "userId": 17175,
        "role": "TrusteeApp_ApproveBill",
        "application": "trusteeApp",
        "contextType": "User",
        "contextObjectIdentifier": "17175"
    },
    {
        "$type": "iTsense.CoreLogin2.Server.API.Models.PermissionApiDto, iTsense.CoreLogin2.Server",
        "username": "max@dax.ch",
        "userId": 17173,
        "role": "TrusteeApp_AddBill",
        "application": "trusteeApp",
        "contextType": "User",
        "contextObjectIdentifier": "17175"
    },
    
]

Notice the first three entries are the permissions the user has himself, and the fourth one is another person who received this right to add bills in Peters name via delegation.

Read who represents a company

If you would like to read who is representing a specific company, you can perform the following query.

{authentication service url}/api/permission?contextType=OrganizationUnit&contextObjectIdentifier=5445&application=trusteeApp

Property

Data Type

Example

Description

contextType

String

OrganizationUnit

Set this to User as you are interested in representations for a user

contextObjectIdentifier

String

5445

This is dependent on how the organization is stored. By default it’s the organization unit id. But if any token transformation has been applied, this might also be the companies UID or any other unique attribute.

application

String

trusteeApp

The name of the application to which the permission have to belong

Example Result

[
    {
        "$type": "iTsense.CoreLogin2.Server.API.Models.PermissionApiDto, iTsense.CoreLogin2.Server",
        "username": "max@dax.ch",
        "userId": 17173,
        "role": "TrusteeApp_AddBill",
        "application": "trusteeApp",
        "contextType": "OrganizationUnit",
        "contextObjectIdentifier": "5445"
    },
    {
        "$type": "iTsense.CoreLogin2.Server.API.Models.PermissionApiDto, iTsense.CoreLogin2.Server",
        "username": "max@dax.ch",
        "userId": 17173,
        "role": "TrusteeApp_Approver",
        "application": "trusteeApp",
        "contextType": "OrganizationUnit",
        "contextObjectIdentifier": "5445"
    }
]

Read which other entities a user represents

If you would like to read who a user is representing, you can perform the following query.

{authentication service url}/api/permission?application=Trustee Test Application&userSubject=c1s:17173

Property

Data Type

Example

Description

application

String

"Trustee Test Application"

The name of the application to which the permission have to belong

userSubject

String

c1s:17173

The subject of the user. This is usually used when the user is logged in, so the subject can be taken directly from the token.

  • No labels