Skip to main content

Information model and API

Users#

The Id and UserName are unique. UserName is an email address of the user.

users

User object#

The information in User:

  • Id
  • FullName
  • UserName(*)
  • Roles
  • Teams
  • Email
  • Status
  • Type
  • CreatedBy
  • CreatedDate
  • LastModifiedDate

Roles#

Roles are names of the roles in the system. They are used with permissions to represent authorization configuration of the User(s).

User can be linked with multiple roles.

Teams#

A User can be a member of multiple Teams. It will inherit all Roles of all its Teams. For referencing the Id of the team is used.

Teams#

Teams are collection of existing Users in the system.

teams

Roles#

Roles are the names of the Roles in the system for Teams. They are used with permissions to represent authorization configuration of the Teams. A Team can be linked to multiple Roles. The user will inherit all Roles of the Teams he/she belongs to.

Roles#

roles

Roles are used for grouping permissions.

There are 2 permission types - ownedEntityPermissions, manageableAreas

  • ownedEntityPermissions OwnedEntityPermission

    • Scope - it is a scope of permission which is equal to entity names. Available values - [ organization, plant, mainSystem, equipment, channel, job, schema, structure, design, file, risk, deviation ]

    • Operation - it represents an operation. Available values - [ create, read, update, delete ]

    • Relation - Available values - [ owned, all ]. If relation is owned, then while operating with entities user can specify as an object owner only himself or his teams. While getting user can get only those entities which is owned by him or his teams. If relation is all, then user do not have limits in specified scope and operation.

  • manageableAreas - Available values - [ designations, quality, risks, assets, monitors ]. ManageableArea specifies areas which user can manage.

The roles of users are written in JWT token, which is generated from identity server. After decoding the JWT token, user can find its assigned roles.

JWT decoded

Example 1:

OwnedEntityPermissions

[      {            "scope": "organization",            "operation": "create",            "relation": "owned"      },      {            "scope": "organization",            "operation": "read",            "relation": "owned"      }]

If this role is assigned to user, then user only can create organization and get them. As relation is owned, it means that as a objectOwner of organization can be specified only the user or its teams. And when user gets all organization the system will return only that ones, which object owner is the loggined user or its teams. If user tries to do other actions (e.g. update organization, create plant etc.) the system will throw error with 401 status code and with message that user does not have permission to this resource.

Example 2:

OwnedEntityPermissions

[      {            "scope": "organization",            "operation": "create",            "relation": "all"      },      {            "scope": "organization",            "operation": "read",            "relation": "all"      }]

If this role is assigned to user, then user only can create organization and get them. As relation is all, it means that as a objectOwner of organization can be specified any user or team. And when user gets all organization the system will return all data. If user tries to do other actions (e.g. update organization, create plant etc.) the system will throw error with 401 status code and with message that user does not have permission to this resource.

Synchronization of AAD Groups and AIH Teams#

Business logic#

AAD users can be part of Security and Microsoft 365 Groups.

roles

AIH Team can be linked to one AAD group by aadGroupId.

roles

Login#

When user logs through AAD into AIH, then:

  • If the user isn't known in AIH and there are teams that are linked to AAD Groups where the user is a member, then the user is created in the system.
  • If the user is known in AIH and isn't part of teams that are linked to AAD Groups where the user is a member, then the teams will be assigned to the user.
  • If the user is known in AIH and is part of teams that are linked to AAD Groups where the user is not a member, then the user will be removed from the teams.
  • If the user is known in AIH and is assigned roles directly, these will not be updated according to the team roles.

The link between a team and AAD Group can be removed and after then the synchronization will be stopped and any users assigned to the team, will remain assigned.

System user creation and usage flow#

We are supporting system users' usage in our application.

Steps#

  • Creating user and filling in "System" value in Type field

    { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa8", "fullName": "TestSystemUser", "userName": "TestSystemUser", "roles": [   "SYS_ADMIN" ], "teams": [   {     "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",     "name": "TeamA"   } ], "email": "[email protected]", "status": "active", "type": "system", "createdBy": {   "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",   "name": "EXTERNAL_SYSTEM" }, "createdDate": "2024-03-21T10:07:46.899Z", "lastModifiedDate": "2024-03-21T10:07:46.899Z"}

  • For already created user navigate Post/Users/{id}/Secret endpoint and generate secret for the user(secret is not generated for newly created user by default)

  • Now we support getting token from identity server login page

    1) After clicking on LoginSystemUser button new dialog is opened

    LoginPage

    2) Filling ClientId and ClientSecret fields with valid values and clicking "Confirm" button token will be generated

    SystemUserLoginPage