Skip to main content

Analyzing permissions to solve access issues

Overview​

When you run Flowable out-of-the-box everything works great, and you are supplied with a set of default users and permissions. During the phase of integration it might be that the user interface is only partially accessible and/or a user is missing permissions to access certain elements. This guide gives you an overview over certain endpoints which can be checked out, assuming that you are able to login.

User Information Endpoint​

The entry point to troubleshoot permissions is to call after login the endpoint /idm-api/current-user. This information provides information about the current user context and with this also valuable insight about the permissions.

An example response (formatted) of the endpoint looks like this:

{
  "id": "admin",
  "firstName": "Flowable",
  "lastName": "Admin",
  "displayName": "Flowable Admin",
  "email": "test@demo.flowable.io",
  "tenantId": "",
  "type": "default",
  "subType": "admin",
  "state": "ACTIVE",
  "subState": "ACTIVE",
  "presence": "available",
  "language": "en",
  "theme": "flowable",
  "userDefinitionId": "IDM-dc64e976-b582-11ed-9f78-ee29d043426b",
  "userDefinitionKey": "user-admin",
  "userDefinitionName": "Administration User",
  "creationTime": "2023-02-26T03:08:40.533Z",
  "identityInfo": [
    {
      "name": "adminUser",
      "type": "boolean",
      "value": true
    },
    {
      "name": "description",
      "type": "string",
      "value": "Admin"
    }
  ],
  "allowedFeatures": [
    "reports",
    "workobject-api",
    "changeOwnPassword",
    "clearMessage",
    "documents",
    "createConversation",
    "fileUpload",
    "audioMessage",
    "conversations",
    "slashActions",
    "actuators",
    "replyToMessage",
    "snooze",
    "changeOwnTheme",
    "impersonateUser",
    "websockets",
    "tasks",
    "search-api",
    "reportsMetrics",
    "emojiPicker",
    "work",
    "sendMessageFromProfile",
    "editContactAvatar",
    "videoMessage",
    "deleteMessage",
    "editConversationAvatar",
    "changeContactPassword",
    "templateManagement",
    "editOwnAvatar",
    "markdownInput",
    "createWork",
    "registerDevice",
    "themeManagement",
    "editConversationTitle",
    "editMessage",
    "compliance",
    "createUser",
    "reactToMessage",
    "user-mgmt",
    "forwardMessage",
    "contacts",
    "lastReadAvatars"
  ],
  "memberGroups": [
    "flowableUser",
    "flowableAdministrator"
  ],
  "adminType": "superAdmin"
}

Besides the meta-information about this user, there are a few helpful elements in the response when troubleshooting:

  • The id of the user, which is used for direct permission assignment.
  • The tenantId which is important in case of multi-tenant environments.
  • The userDefinitionKey which gives basic access rights and helps to determine the allowedFeatures and memberGroups.
  • The memberGroups provide a list of all groups the user is assigned to. There is the special group flowableAdministrator which will determine if the user is an admin.
  • adminType which provides you if the current user is an admin and what kind of admin the user has (tenant vs. super).

Scenarios and Potential Cause​

In the following sections there are common scenarios described and how they can be resolved.

Flowable Work Interface is showing 404​

When you see an empty Flowable with just a 404 page, this is most of the time by missing allowedFeatures. Typically, missing allowedFeatures are caused by a missing or wrong user definition. Check the /idm-api/current-user endpoint to see if the permissions are applied correctly.

Task is not visible for a user​

Assuming a user doesn't have access, it needs to be analyzed why the user doesn't have access. Therefore, you need to have the /idm-api/current-user response from the user. In addition, it's also advised to use a user with access to the task to gather information about the task itself.

Assuming the task id is known, you can call the endpoint /process-api/runtime/tasks/{taskId}/identitylinks and replace {taskId} with the actual task id. There are similar REST endpoints available for completed tasks, processes, cases, etc.

The result you retrieve will look similar to this:

[
  {
    "url": "/process-api/runtime/tasks/{taskId}/identitylinks/users/shane.bowen/candidate",
    "user": "shane.bowen",
    "group": null,
    "type": "candidate"
  },
  {
    "url": "/process-api/runtime/tasks/{taskId}/identitylinks/users/admin/candidate",
    "user": "admin",
    "group": null,
    "type": "candidate"
  },
  {
    "url": "/process-api/runtime/tasks/{taskId}/identitylinks/groups/clientAdvisor/candidate",
    "user": null,
    "group": "clientAdvisor",
    "type": "candidate"
  }
]

Now it needs to be checked if there is a "user" which maps the "id" of the current user, or a "group" which maps to one of the "memberGroups" of the /idm-api/current-user endpoint. In case not, either the IDM configuration or the task configuration needs to be aligned.

In case there is a valid entry, it might be worth to check the security policy for the appropriate task and ensure that the "type" is allowed to view the task.