Access Management
To get access to your data, you must log in to your authentication system. You will have a session id, or better a user token. Send them in authorize-header on each request allows you to get access to the data in dependence of your user roles and tenant.
TIP
For full public access to the CMS see the none client in the clients section.
Overview
Required environments
The environments you need are dependent on your auth server client. have a look into our auth section. see: auth section
Model roles
Each model have an endpoint that is protected against unauthorized access. The endpoints are based on the main actions:
- create
- read (read one single object by id)
- update
- delete
- query (get a list of objects by filter and parameter)
Have a look at the swagger documentation of your own cms for more information.
To get access to the endpoint you need a role assigned to your user in your chosen authorization server. see: auth section
Naming of roles
Model roles are defined by the name of the model. So the name of the role is simple the name of model, but lowercase. If you have a special role field like a special read role, we add a postfix to the role. Now you have "model-read" as role name.
Field roles
Field roles are the way to protect other data objects from unauthorized access via recursive updates or prevent reading sensitive data.
A perfect example is a password field. No one in the application should be able to read a password from database. Only your middleware (workflow service, etc.) should have access to the field with a special role on a technical user see: auth section.
Naming of field roles
Model field roles are based on the name of the model, prefixed by the name of the field, prefixed by the action and split by minus character. The role name is lowercase also. So you will have a field role name like "model-field-update".
Special action prefix
Prefixes:
- create
- read
- update
- delete
TIP
You see there is no "query" action, because the query endpoint based on the "read" action.
Role name examples
- offer (role name for everything without special role, like a fallback)
- offer-read (read access to offer's)
- offer-customer-update (special field tole to update the customer in the offer)
Authorize clients
To use the clients set the environment cms_user_management_client (in your docker container) to the given key-combination split by dot.
| Auth-Server | Key | Description | Versions |
|---|---|---|---|
| Keycloak | keycloak | Keycloak IAM | 15.0.2 |
| Internal | internal | Keycloak IAM | 0.0.1 |
| None | none | Public Access | 1.0.0 |
Example: cms_user_management_client=keycloak.v15_0_2
TIP
Other authentication-server or versions implementations will be made for you. Please request them with your contract.