Identity and Access Management
User identity is an essential aspect when maintaining a Management System.
It is not something you should take lightly. We recognize several well-established
Identity Providers that are compliant with OpenID Connect & OAuth 2.0 and offer
them as a means of gaining user identity to all services within the Mosaic Platform.
User access management is governed by a simple set of rules. Each service publishes a list of known permissions which allow to perform certain actions. You can then define user roles and such permissions can be picked & assigned to those user roles. Finally, such user roles can be assigned to the desired users.
Managing Users and User Roles
The Management System can be used to configure users and user roles of the Identity Service. The corresponding pages to do this can be found inside the Settings page.
Users
These set of pages allows to explore and manage Management Users. When a new user
logs into the Management System using the desired Identity Provider, a new management
user account is automatically created, but will be inactive. A privileged user must
then assign user roles and activate such users, so they could access the Management System.
Sometimes, it might be beneficial to pre-register a user account in advance for those who are expected to use the Management System in the future. In such cases, a user’s pre-registration could be done for a specific email address (which must be known before). This also gives the opportunity to assign user roles to the pre-registered user as a part of the preparations.
|
Tip
|
It is possible to "whitelist" certain email domains when you expect a large number of user sign-ups, or when you don’t have a pre-defined list of email addresses to pre-register the users manually. This can be done in the Environment Administration Portal under the Identity Service configuration. When you whitelist an email domain, you may also assign one or more user roles in the same configuration. This way, when a user signs up from an email address matching the whitelist pattern, their management user account is auto-activated and the configured roles are pre-granted. |
User Roles
These set of pages allows to explore and manage user roles. From the user role details page, it is possible to manage the granted permissions.
User roles are also designed to be hierarchical. This gives the freedom to make them as simple or as complex as needed for different situations.
When a new environment is created, there is only the Administrator role present. You must create most user roles which are suitable for your Management System’s use cases.
User Role Tags
A user role may also contain zero or more tags assigned to it. These tags are free texts which are embedded inside the generated access tokens once the specific roles are assigned to users. The tags have no special meaning for any of the Managed Services. However, you may design your Customizable Services to take into account the contained tags of the access token when executing requests. This could be used for implementing more complex scenarios where row-level access is checked against the present tags in an access token.
For example, you may create a role Movie Editor (Only Country US) and grant it
the permissions for editing & viewing movie metadata. You may also create a tag in that
same user role with a free text COUNTRY_US. Now, in your customized media service,
you may write an extra authorization check which reads the access token and iterates
the tags inside it. If it contains the free text COUNTRY_US, it can apply a row-level
filter to only allow access to movie metadata of movies produced in the US.
|
Tip
|
It is recommended to always start with the minimum number of permissions being granted to new user roles and then build up from there. Remember that user roles are a hierarchical structure, so make it a practice to create roles which mimic real world roles and then reuse the roles to create more privileged roles. |
Managing Service Accounts
The Environment Administration Portal can be used to configure service accounts. The corresponding pages to do this can be found inside the Environment Details page.
Service Accounts
These set of pages allow to explore and manage service accounts. From the service account details page, it is possible to manage the granted permissions.
In addition to users, services can also make requests among themselves (inter-service communication). Also, you may have some integration requirement where some external tool/process needs to communicate with the Mosaic services. In such cases, it is possible to create services accounts and grant the needed permissions. The service account credentials (client ID, client secret) can then be used to authenticate with the Identity Service to receive a JWT, which must be sent along with the request headers to other services it intends to communicate with.
|
Tip
|
It is recommended to create separate service accounts for each use case rather than share a single account. This makes each service account contain only a limited subset of permissions which are needed for the use case rather than being a single super account with a plethora of permissions that makes it a security risk. |
|
Note
|
It is not possible to assign user roles to a service account. Instead, permissions can be assigned to it directly. This enables very fine-grained control over the access level for the service accounts. |
|
Warning
|
Please be mindful when you change the password of a service account or delete it. There may exist an integration that already uses the service account, and it would fail after these changes. |
See also: