Skip to main content

Authorization

This document outlines the available roles within our application and how to configure group to role mappings for LDAP and OAuth2 authentication methods. Understanding these roles and how to map them correctly is crucial for managing access control within the system.

Available roles​

Our application supports three roles:

  1. ADMIN: This role grants full control over the application. Admins can create, view, and manage all resources, including those created by other users.
  2. USER: This role grants access to core application functionality. Users can create, view, and manage their own resources.
  3. VIEWER: This role provides read-only access to the application. Viewers can view all resources but cannot create or modify them.

Role mapping​

If you're using internal authentication (the default method), you don't need to worry about role mapping. The application will automatically assign the correct roles based on the configuration of the internal user accounts.

However, when using LDAP or OAuth2, you will need to map the groups from these systems to the roles within our application.

LDAP group to role mapping​

For LDAP, groups assigned to the user within LDAP need to be mapped to our application's roles.

An example helm upgrade command for mapping LDAP administrator and developers groups to Ilum roles is shown below:

helm upgrade \
    --set ilum-core.security.authorities.roles.mappings.administrators=admin \
    --set ilum-core.security.authorities.roles.mappings.developers=user \
    --reuse-values ilum ilum/ilum

OAuth2 group to role mapping​

For OAuth2, you will need to map the group claims from the JWT token to the roles within our application.

An example helm upgrade command for mapping OAuth2 groups to roles is shown below:

helm upgrade \
    --set ilum-core.security.authorities.roles.mappings.8032fe76-2d7e-4178-9066-d38ee8536675=admin \
    --reuse-values ilum ilum/ilum

Note: To utilize role-based authorization, your OAuth2 provider needs to include the user's group membership information in the token claims. These are often referred to as group claims. The configuration for this can vary between OAuth2 providers. Therefore, you should refer to your provider's documentation for precise instructions on how to do this.

Example configuring group claims in Azure AD​

Here is an example of how you can configure group claims for Microsoft Azure AD:

  1. Sign in to the Azure portal.
  2. Select Azure Active Directory.
  3. In the left-hand navigation pane, select the "Azure Active Directory" service, select "App registrations", and then select your application.
  4. In the application's blade, select "Token configuration", then select "Add groups claim".
  5. Select the groups you want to include in your token claims.
  6. Select "Add".
  7. Don't forget to grant admin consent for the application to allow group membership claims.

Once you've completed these steps, Azure AD will include the selected group's ID in the groups claim of the token when issuing tokens for the application. This information can then be used by our application to assign appropriate roles to users based on their group membership in Azure AD.

The application needs to know which roles to assign to users based on these group IDs. For this, we utilize Authorization Mapping configuration. It's a mechanism to map these Azure AD group IDs to the corresponding roles within our application.