The Authorization Customization feature provides flexible role management by allowing users to tailor how roles are defined and displayed. Roles are assigned through a scoped role string managed by an identity provider (IDP), and this feature introduces several customization options:
Customizable scoped role delimiter: Users can define their own delimiter to separate parts of the scoped role string. By default, a period (.) is used, but it can be changed to an underscore (_) or any other character, enhancing integration with different IDP configurations.
Customizable Wildcard: The second part of a three-part scoped role string specifies a configuration area, and a wildcard character can represent access to all non-confidential areas. While the default wildcard is an asterisk (*), users can now customize it to any character or string, providing more flexibility in defining access levels.
Role Claim configuration: Allows to define which claim in the token coming from the IDP should be used as the scoped role claim. Depending on that different formats for role display names can be configured within the application. This allows for more intuitive and organization-specific naming conventions that align with the user’s role and access permissions.
These enhancements enable organizations to align role management and display with their specific needs and identity provider configurations, facilitating more precise control over user access and role representation in the application.
The CDCM application allows the delimiter used in scoped role strings to be customized, providing flexibility in how roles are structured and integrated with various identity providers.
Configuration: The delimiter can be set using the environment variable ROLE_DELIMITER. By default, the delimiter is a period (.), but it can be changed to any character, such as an underscore (_), to match the format used in the IDP.
Usage Example: If ROLE_DELIMITER is set to _, the scoped role string can be formatted as spaceKey_areaKey_roleKey, enabling clearer separation of the space, configuration area, and role components.
The CDCM application provides the ability to customize the wildcard used in scoped role strings, enhancing flexibility in defining access across multiple configuration areas.
Configuration: The wildcard character can be set using the environment variable CONFIGURATION_AREA_WILDCARD. By default, the wildcard is an asterisk (*), but it can be changed to any character or string, such as any or %, to meet specific organizational needs.
Usage Example: If CONFIGURATION_AREA_WILDCARD is set to any, the scoped role string spaceKey_any_roleKey allows users to have the specified role in all non-confidential configuration areas.
This feature allows organizations to customize access patterns and streamline role management by using intuitive and relevant wildcard symbols that align with their identity provider and access control strategies.
The CDCM application allows the usage of different claims in the token coming from the IDP. By doing this this the roles set in a specific claim are used for authorization in the CDCM application and different fields in that claim can be used for the display names. This enhances clarity and alignment with organizational naming conventions. It is also possible to specify a prefix that should be ignored when parsing the role claim string coming from the identity provider.
Configuration: Display names are configured using the environment variable OAUTH_CLAIM_CONFIGURATION. This variable should contain a JSON array, where each object defines the claim attribute (=roleClaimAttribut) and the corresponding display name format (=displayNameForma) as well as an optional field for the prefix that should be ignored while parsing the role string(=prefix).
JSON Format: Each object in the array specifies a roleClaimAttribute, a displayNameFormat and a prefix. The display name format can include placeholders (<<>>) to dynamically insert token attributes into the display name.
Example Configuration:
[
{
"roleClaimAttribute": "roles",
"prefix": "I_will_be_ignored",
"displayNameFormat": "System user <<applicationId>>"
},
{
"roleClaimAttribute": "groups",
"displayNameFormat": "<<given_name>> <<family_name>>"
},
{
"roleClaimAttribute": "cdcm.groups",
"displayNameFormat": "<<given_name>> <<family_name>> | <<department>>"
}
]
|
Usage: This configuration allows display names to be dynamically generated based on user attributes, providing personalized and informative identifiers. For example, a display name might appear as "System user 12345" or "John Doe | Sales" based on the claims found in the user token.
CDCM can add the roleAdmin Role that is created during space creation to arbitrary users by adding their email address to a comma-separated list in the environment variable ROLE_ADMINS.
Example:
export ROLE_ADMINS="alice@example.com bob@example.com" |
CDCM will add the roleAdmin role for all spaces the the users alice and bob that are mapped via the email addresses in the OIDC Token Response from the IAM system.