UI should check roles/permissions before allow actions to a user

[ctron]

For example, the upload. The user has an access token of:

{
  "exp": 1731661671,
  "iat": 1731661371,
  "auth_time": 1731661290,
  "jti": "d36fce31-b1ec-4568-a7db-29b3d4ff59ad",
  "iss": "https://trustify-sso.dentrassi.de/realms/trustify",
  "aud": "account",
  "sub": "5049d7ed-4035-4be8-a23e-6e5d1e30f4e3",
  "typ": "Bearer",
  "azp": "frontend",
  "session_state": "4167ef65-8290-41a6-9023-7ee1627922f5",
  "allowed-origins": [
    "*"
  ],
  "realm_access": {
    "roles": [
      "default-roles-trustify",
      "offline_access",
      "chicken-user",
      "uma_authorization"
    ]
  },
  "resource_access": {
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "scope": "openid email profile read:document",
  "sid": "4167ef65-8290-41a6-9023-7ee1627922f5",
  "email_verified": false,
  "name": "Jens Reimann",
  "preferred_username": "ctron",
  "given_name": "Jens",
  "family_name": "Reimann",
  "email": "ctron@dentrassi.de"
}

The important part being: .scope = "… read:document". Missing create: or update: scopes. So it's read-only.

Still, the UI offers an upload screen, which then fails with a 403.

I think there should be an enpoint in the backend which the UI can use to check if an operation possible for the user. As the scope read:document is specific to the keycloak setup. Which translates to the read:advisory and read:sbom permission. However, that information/logic is unknown to the client. And differs between different OIDC providers (like AWS cognito).

My proposal would be to create an endpoint where the frontend can check if a permission is granted or not. Sending the bearer token and the requested permission. Which are, right now, defined by: https://github.com/trustification/trustify/blob/ed72d871cd9a9d2afe6ce30380d0bbd5edf7b497/common/auth/src/permission.rs#L57-L110

[carlosthe19916]

My proposal would be to create an endpoint where the frontend can check if a permission is granted or not. Sending the bearer token and the requested permission. Which are, right now, defined by:

What about having an endpoint e.g. /api/v1/permissions that returns ALL permissions the user has?

• /api/v1/permissions does not need to any receive any other information other than the Bearer Token
• The endpoint gives ALL permissions in a single shoot

[ctron]

That might work today, but not in the future. As "all" wouldn't be defined if we start adding RBAC, ACL style authorization.

[carlosthe19916]

I don't see why it would not work in the future.
What I was suggesting is rather than:

• Multiple shoots:
  • client: can I do X? => Backend YES|NO
  • client: can I do Y? => Backend YES|NO
  • client: can I do Z? => Backend YES|NO
• Do a single shoot:
  • client: what can I do? => you can { X: YES|NO, Y: YES|NO, Z: YES|NO}
  • If in the future there are more permissions added/changed/deleted there is no impact the response of the backend as it will still be something like:
  • client: what can I do? => you can { X: YES|NO, Y: YES|NO, Z: YES|NO, A: YES|NO, B: YES|NO, C: YES|NO}

I can not accept a solution that forces the client to call an endpoint multiple times, one for each permission to verify whether or not he is allowed to trigger certain actions. But perhaps I am misunderstanding the proposed solution. It would be nice that for every proposal there is enough details for anyone to read it and clearly know what the technical proposal is and avoid assumptions.

[ctron]

Assuming you pull in documents into this, trying to answer the question: can user X delete document Y? How would that work?

[trustification-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.

[carlosthe19916]

Seems like the Auth thing will need some appropriate design and will come hand in hand with the upcoming RBAC solution for after v2.0. Currently the UI is equivalent with V1 in regards of what this issue mentions. So I would suggest to move this ticket to the milestone "2.1.0" to design and implement a solid solution.