Statista 4.0 User Rights
- Revisit (user-rights([#user-rights] within your team's domain
Introduction
In order for us to fully utilize Role-Based-Access-Control (RBAC), we need to reshape our existing user-rights structure to be more focused and compatible with the functionality that we (as users of Auth0) and the applications are trying to achieve. For a more comprehensive definition of RBAC please take a look at the Wikipedia Definition and Auth0 Docs.
We would like to achieve a structure where a user solely belongs to a role (or several roles) but does not explicitly contain special permissions outside the roles scope. This simplifies and standardizes our structure and allows us to manage access in a more convenient way.
Status Quo for Statista 4
We currently map the roles defined in Auth0 to the existing products of our Monolith. This is a simple 1:1 map, which takes a product ID and creates a role within the Auth0 environment. With each role, we define permissions associated to it. For example: A Starter Account has access to XMO but another account type such as the Basic Account might not. Reference - Auth0 Terraform Provider
As it stands, we have several different setups in the legacy world. The most simple case is where a user just has a product that comes with a set of permissions (user-rights). This is an array of business logic strings that get delivered as the user is fetched from the db. As far as the migration and setup goes within the new SSO (Auth0 powered) flows, we mirror this functionality. All other cases are not yet considered in the new setup. This is to be determined and designed to fit the Auth0 environment.
A second case involves group accounts. Here, we have some variations on what the monolith does. Firstly, we can consider the case where everyone within an organization (library, university, enterprise, etc.) simply log in the main account. This way, all users use the same credentials and login methods and this becomes similar to the case mentioned earlier, it's one account that is associated to a product and comes with a set of permissions. This is the default simplest case.
Then, we can also consider the case where there are explicitly created accounts which belong to a group within the database (main account). Here, those accounts in general inherit the permissions from their account holder (main account). However, the handling of the monolith does not explicitly do this. We combine an array of user permissions both from the main account and the individual account created in the db. For example, the main account could have and Enterprise Account and the individual account can have a Basic Account. Within the legacy, both of those products will be considered and a join array of both of the associated permissions will be created to define the user.
This pseudo-inheritance can be extended to have a chain of main account owners. For example, the first layer of account owners could also have an umbrella account owner. In this case, the monolith does the same, where an array of permissions is created from all layers of inheritance.
A special case exists, where users can have individual permissions assigned to them as well, not belonging to the product definition that they are assigned to. This is of course not ideal, since it's manually assigned and not easily maintainable or automated.
Lastly, the permissions inside the monolith are often functioning as feature flags. We would like to migrate away from this, and purely define permissions as access parameters. Because of the legacy world, we also need to eliminate rights that function as "anti-rights" within the monolith. For example, if the main account gives a user several permissions, we currently have a situation where the individual accounts have explicit rights assigned to them that "counter" the inherited rights. This is not ideal.
From an application perspective, the authorization logic should not depend on the type of product the user has, but directly reference the permissions attached to it. The reasoning behind this is that users might belong to multiple roles with distinct and/or overlapping permissions. As it currently stands, we only have one role definition per user, but the need for multiple roles is pressing (e.g. Administrator vs Employee). When presenting the user with the definition to an application using our service, the roles will be aggregated to an array of combined permissions that the application will check, regardless of which and how many that user has.
Permission Structure and Standard
We would like to standardize our permissions format and minimize the variations as much as possible. This would mean that the domain that each application is responsible for needs to have a clear definition of the user-rights required for its functionality. Please take into consideration what user-rights you need, and then map them to specific products. If required, an extra role could be set up on our end in order to accommodate variations. For example:
User -> Starter Account Role
Grants the user permission: xyz
If variations are needed (e.g. administrator):
User -> Starter Account Role + Administrator
Grants the user permissions: xyz:read, xyz:write
This way, we are following the noun:verb notion of the user rights, and is understandable by both the application and the developer.
Keep in mind that currently we would need to define what is an Administrator user in this case. A functionality that is not yet implemented. But if there are requirements and these requirements can be interpreted from the UserDB automatically, we can accomodate this setting.