Skip to content

Technical Details

Permissions are deeply integrated in Tenantos. There are four layers of permission checking:

  • API endpoint
  • Request body fields
  • Response body fields
  • Belong checks (does the user have access to the resource?)

Through these four layers, you can specify exactly which permissions a user has.

It's getting a bit technical now. If you are not interested in technical details, you can skip this page.

First, Tenantos abstracts away the multitude of permissions (over 5000) into manageable groups. You do not need to know the names of the individual permissions. If you are an advanced user, you can directly modify the individual permissions to customize the permissions down to the smallest detail. This page is only for advanced users.

For example, let's look at the API endpoint PUT /servers/1. The user sends the following request:

PUT /servers

{
    "description": "My Server",
    "suspendUserIds": [2]
}

Tenantos will check the following:

  • Does the user has permission to send a request to the /servers PUT endpoint?
  • Does the user own the server ID 1?
  • Is the user allowed to use the "description" and "suspendUserIds" fields?

The relevant permissions for that would be:

servers.update
servers.update.param.description
servers.update.param.suspendUserIds

If the users permissions do not exactly match, the request is denied with a meaningful error message.

When returning the response, Tenantos checks each key of the returned array. Let's say the following response is sent back:

{
    "result": {
        "id": 1,
        "hostname": "webserver.example.com",
        "servername": "server001",
        "user_id": 6,
        "os": null,
    }
}

Then the user needs the following permissions to see the fields:

servers.apiOutput.param.id
servers.apiOutput.param.hostname
etc.

Fields to which the user has no authorization are discarded from the output.