Admin

The Admin section lets you manager Cockpit users, AdminCentral groups, and Organisations.

It’s a good idea to manage access to your DX Cloud subscription. You an easily handle this using the Admin section in your Cockpit. Here, you can create and manage users, and create user groups for your subscription as well as perform administrative operations like password resets, or creating business units (Organisations).

Manage users

You can manage existing users directly from the Cockpit under the Access section. This includes:

Adding a user

You can add a new user to your DX Cloud subscription directly from the Cockpit under the Access section.

  1. Go to Admin > Users.

  2. Click Add.

    1. If desired, click Active to immediately activate the user upon creation.

    2. Input the user email.

    3. Give the user a First Name.

    4. Give the user a Last Name.

    5. Add the user to the appropriate groups.

      Groups list

      Click the group for details on what roles are included in each group.

      Cockpit groups
      Rancher groups

    6. Don’t forget to click Add.

      create new user

User status

The user list allows you to quickly understand the status of the user.

  • Active Active users are represented by a green badge.

  • Inactive Inactive users are represented by a gold badge.

  • Not verified Unverified users are represented by a red badge.

Editing a user

  1. Go to Admin > Users.

  2. Scroll to the desired user.

  3. Click Edit.

  4. In the dialog window, edit the user as needed.

  5. Don’t forget to click Edit.

Deleting users

  1. Go to Admin > Users.

  2. Scroll to the desired user.

  3. Click Delete.

  4. In the dialog window, click Delete to confirm that you definitely want to delete the user.

Reset user credentials

You can reset a user’s password or One-time Password (OTP) directly from the Cockpit under the Admin section.

SSO users

If you’re using SSO for your DX Cloud subscription, you are unable to reset the password of those users logging in via Single Sign-On, as the password is managed via the OIDC provider.

  1. Go to Admin > Users.

  2. Scroll to the desired user.

  3. Click Reset credentials. In the dialog, choose to:

    • Reset password Initiates password reset process

    • Reset OTP Initiates One-time Password (OTP) reset process

      An email is sent to the user. Users should follow instructions to reset their password and/or OTP credentials.

      reset credentials

Create user group

You can create a new user to your DX Cloud subscription directly from the Cockpit under the Admin section.

  1. Go to Admin > AdminCentral groups.

  2. Click Add.

    1. Give the group a meaningful name.

    2. Click the users that you want to add to the group.

      If you accidentally click the wrong user, you can click them again and they’ll return to the Available group.

    3. Don’t forget to click Add.

      create user group

Group access AdminCentral

If using the SSO module for authentication, you need to ensure the groups created in the Cockpit are granted access via the configuration in the SSO module.

  1. Create a group in the Cockpit.

    No special roles are needed for AdminCentral access.

  2. Assign users to the group. These are the users who you want to be able to access AdminCentral.

  3. In the SSO module, ensure the group name created in the Cockpit is defined in the config.yaml file. See the SSO module configuration section for more details.

    path: /.magnolia/admincentral
callbackUrl: http://localhost:8080/.auth
postLogoutRedirectUri: http://localhost:8080/.magnolia/admincentral
authorizationGenerators:
  - name: groupsAuthorization
    groups:
      targetProperty: groups
      mappings:
        - name: /COCKPIT_GROUP (1)
          targetGroups: (2)
            - editors
          targetRoles: (3)
            - editor
    1 Where /COCKPIT_GROUP is the name of the group you created in the Cockpit. If using Keycloak, the leading / is mandatory.
    2 Defines the target group for the mapped group.
    3 Defines any particular target roles for the group.

Add Organisation

You can create an Organisation so that you can group access to certain parts of your DX Cloud project based on a business unit or organisation. You can define access to clusters, domains, and namespaces this way and explicitly choose the users that are part of the unit.

  1. Go to Admin > Organisations.

  2. Click Add.

    1. Give the organisation a meaningful name.

    2. Give the organisation a meaningful description.

    3. Choose the Cluster Ids for which you want to grant access.

    4. Choose the Domains for which you want to grant access.

    5. Choose the Namespaces for which you want to grant access.

    6. Click the users that you want to add to the organisation.

      If you accidentally click the wrong user, you can click them again and they’ll return to the Available group.

    7. Don’t forget to click Add.

      create business unit

Federations

Federations enable your organization to integrate external Identity Providers (IdPs) with our DX Cloud platform through OpenID Connect (OIDC) protocols or SAML. In the DX Cloud Cockpit, you can configure Federations to establish trusted relationships with third-party identity systems, configure Cockpit and Rancher mappings, as well as define user attribute mappings between your external IdP and platform resources.

federations overview

In this section, you can find:

Add a Federation

  1. In the Cockpit, go to Admin > Federations.

  2. Enter a Display name for your Federation. This autofills the Alias field.

  3. Check the box for Enabled if you want to enable the Federation.

  4. Select the type of the Federation. This is either OIDC or SAML.

    • OIDC

    • SAML

    The following are required:

    1. Enter the Authorization URL.

    2. Enter the Token URL.

    3. Enter the Client ID.

    4. Enter the Client secret.

    The remainig are optional but recommended:

    1. Enter the Logout URL.

    2. Enter the User info URL.

    3. Enter the Issuer.

    4. Check the box for Validate signature if you want to validate the signature of the IDP token.

    5. Check the box for Use JWKs URL if you want to use the JWKs URL to validate the signature of the IDP token.

    6. Enter the JWKs URL.

    The following are required:

    1. Enter the SAML Metadata.

    The remaining are optional but recommended:

    1. Enter the Name ID Policy Format.

    2. Enter the Principal Type. Use NameID.

  5. Under Advanced settings, choose the Sync Mode. This is either Force on every login or Import only on first login.

  6. Check the box for Trust Email if you want to trust the email of the user.

General settings

Alias

🏷️ Alias

The alias is used to identify the Federation in the system. This is the same as the Display name you enter when adding a Federation.

Name

🏷️ Display name

The Display name of the Federation. This is the same as the Alias you enter when adding a Federation.

Enabled

🏷️ Enabled

Click the checkbox to enable the Federation.

Type

🏷️ Type

The type of the Federation. This is either OIDC or SAML.

OpenID Connect settings

Authorization URL

🏷️ Authorization URL

The Authorization URL is the endpoint where the identity provider redirects the user after a successful authentication.

Example
https://let.me.in.com
Token URL

🏷️ Token URL

The Token URL is the endpoint where the identity provider returns the access token.

Example
https://get.my.token.com
Client ID

🏷️ Client ID

The Client ID is the unique identifier of the application in the identity provider.

You should get this from your Identity Provider.

Example
jamesbond
Client secret

🏷️ Client secret

The Client secret is the secret key used to authenticate the application in the identity provider.

You should get this from your Identity Provider.

Example
superFlyTopSecret5000
Logout URL

🏷️ Logout URL

The Logout URL is the endpoint where the identity provider redirects the user after a successful logout.

User info URL

🏷️ User info URL

The User info URL is the endpoint where the identity provider returns the user information.

Issuer

🏷️ Issuer

The Issuer is the unique identifier of the identity provider.

Validate signature

🏷️ Validate signature

Click the checkbox to validate the signature of the IDP token.

Use JWKs URL

🏷️ Use JWKs URL

Click the checkbox to use the JWKs URL to validate the signature of the IDP token.

JWKs URL

🏷️ JWKs URL

The JWKs URL is the endpoint where the identity provider returns the JSON Web Key Set (JWKs) used to validate the signature of the IDP token.

SAML settings

SAML Metadata

🏷️ SAML Metadata

The SAML Metadata is the XML metadata of the identity provider.

Name ID Policy Format

🏷️ Name ID Policy Format

The Name ID Policy Format is the format of the Name ID in the SAML assertion.

Principal Type

🏷️ Principal Type

The Principal Type is the type of the principal in the SAML assertion. Use the NameId.

Advanced settings

Sync Mode

🏷️ Sync Mode

The Sync Mode is the mode of the Federation.

Options:

  • Force on every login

  • Import only on first login

Trust Email

🏷️ Trust Email

Click the checkbox to trust the email of the user.

Edit a Federation

When you add a Federation, you’re connecting DX Cloud to an external identity provider (IdP) to manage authentication for your users. This allows your organization to use Single Sign-On (SSO) through supported protocols like OpenID Connect (OIDC) or SAML.

After creating a Federation, you can add Cockpit, Rancher, Magnolia SSO, and User attribute mappings as required.

  1. In the Cockpit, go to Admin > Federations.

  2. Go to the stacked lines ☰ and click Edit.

  3. Choose one of the following to edit:

    1. Cockpit mappings

    2. Rancher mappings

    3. Magnolia SSO mappings

    4. User attribute mappings

Cockpit mappings

Cockpit mapping lets you automatically assign users to specific Cockpit groups based on identity information received from the Identity Provider (IdP) during login.

When a user logs in using a federated IdP (via SAML or OIDC), we inspect the user’s identity token for specific claims (such as email, department, or role) and matches them to defined rules. These mappings determine which Cockpit group the user should belong to.

Use Cockpit mappings to grant conditional access to environments, projects, or roles based on user attributes managed by your organization’s IdP.

cockpit mapping

To create a Cockpit mapping:

  1. Go to the Cockpit mapping tab.

  2. Go to Add new mapping.

  3. Under Access for, select one of the following:

    • User matching claim: Only users whose IdP token contains a matching claim will be assigned to the group.

    • Everyone: All federated users will be assigned to the specified group, regardless of claims.

      Use Everyone for general access groups, and User matching claim for more granular, attribute-based group assignments.

  4. Enter a Name for the mapping.

    This is used internally to help identify the mapping. Choose a meaningful name you will remember.

  5. Enter a Claim.

    The Claim is name of the claim to inspect in the IdP token.

    Common examples include:

    • email

    • groups

    • department

    • roles

    Get valid claim names from your IdP administrator or associated documentation.

  6. Enter a Claim value.

    The expected value of the claim to match.

    Example:

    If the token contains:

    "department": "marketing"

    Then the Claim would be department and the Claim value would be marketing.

  7. Select if it should be an exact match or a regex with Is regex.

    Leave this unchecked to require an exact match. Enable it if you want to match patterns, for example:

    • ^dev.* matches devops, developers, dev-team

    • .*-team$ matches frontend-team, backend-team, qa-team

  8. Select a Group

    The Cockpit group to assign the user to if the claim match is successful.

    Available groups depend on your Magnolia Cockpit configuration (e.g., Admin, Editor, Viewer).

Example

To assign users from the Marketing department to the Editor group:

  • Access for: User matching claim

  • Name: CockpitMarketing

  • Claim: department

  • Claim value: marketing

  • Is regex: unchecked

  • Group: Editor

Rancher mappings

Rancher mappings let you automatically grant users access to specific Rancher environments based on identity information received from the Identity Provider (IdP) during login.

When a user logs in using a federated IdP (via SAML or OIDC), Magnolia inspects the user’s identity token for specific claims (such as email, department, or role). These mappings determine whether the user should be granted access to Rancher.

Use Rancher mappings to restrict or grant Kubernetes access based on organizational roles, departments, or other IdP-managed user attributes.

rancher mapping

To create a Rancher mapping:

  1. Go to the Rancher mapping tab.

  2. Click Add new mapping.

  3. Under Access for, select one of the following:

    • User matching claim: Only users whose IdP token contains a matching claim will be granted Rancher access.

    • Everyone: All federated users will be granted Rancher access, regardless of claims.

      Use Everyone to grant broad Rancher access, and User matching claim to restrict access to specific teams or roles based on IdP attributes.

  4. Enter a Name for the mapping.

    This is used internally to help identify the mapping. Choose a clear, descriptive name such as GrantDevTeamRancherAccess.

  5. Enter a Claim.

    The claim is the name of the attribute from the IdP token that Magnolia will inspect.

    Common examples:

    • groups

    • department

    • team

    • roles

    Check your IdP documentation or consult your administrator for the correct claim names.

  6. Enter a Claim value.

    The expected value of the claim that must be matched in order to grant access.

    Example:

    If the token includes:

    "groups": ["devops", "qa"]

    Then the Claim would be groups and the Claim value would be devops.

  7. Select whether the value should be treated as a regular expression by enabling Is regex.

    Leave this unchecked to match the claim value exactly. Enable it if you want to match patterns, for example:

    • ^dev.* matches devops, developers, dev-team

    • .*-team$ matches frontend-team, backend-team, qa-team

Example

To grant Rancher access to users in the DevOps group:

  • Access for: User matching claim

  • Name: RancherDevOps

  • Claim: groups

  • Claim value: devops

  • Is regex: unchecked

Magnolia SSO mappings

Magnolia SSO mappings let you grant users access to specific Magnolia SSO clients and roles based on identity information received from the Identity Provider (IdP).

When a user logs in using a federated IdP (via SAML or OIDC), Magnolia inspects the user’s identity token for specific claims (e.g., email, department, groups) and uses these mappings to determine which SSO client and role the user should be assigned to.

Use Magnolia SSO mappings to manage access across Magnolia services and applications through centralized SSO group and role assignments.

magnolia sso mapping

To create a Magnolia SSO mapping:

  1. Go to the Magnolia SSO mapping tab.

  2. Click Add new mapping.

  3. Under Access for, select one of the following:

    • User matching claim: Only users whose IdP token contains a matching claim will be granted Magnolia SSO access.

    • Everyone: All federated users will be granted Magnolia SSO access, regardless of claims.

      Use Everyone to grant broad Magnolia SSO access, and User matching claim to restrict access to specific teams or roles based on IdP attributes.

  4. Enter a Name for the mapping.

    This is used internally to identify the mapping. Choose something descriptive, such as AssignMarketingToEditorRole.

  5. Enter a Claim.

    This is the name of the attribute in the IdP token that Magnolia will inspect to determine role assignment.

    Common examples:

    • email

    • groups

    • roles

    • department

    You can get valid claim names from your IdP administrator or documentation.

  6. Enter a Claim value.

    This is the expected value Magnolia should match against the specified claim.

    Example:

    If the token includes:

    "groups": ["marketing", "design"]

    Then the Claim is groups and the Claim value is marketing.

  7. Enable Is regex if the claim value should be interpreted as a regular expression.

    Leave unchecked for exact matches. Use regex for flexible matching, e.g.:

    • ^editor.* matches editor, editorial, editorial-team

    • .*-group$ matches qa-group, admin-group

  8. Select the Client.

    This is the Magnolia SSO client the user should be assigned to if the mapping matches.

    Clients represent applications or services integrated with Magnolia SSO.

  9. Select the Role.

    The role to assign to the user within the selected Magnolia SSO client.

    Roles control what the user can do once logged into that client.

Example

To assign the page-editor role in the admincentral SSO client to users from the marketing group:

  • Access for: User matching claim

  • Name: MarketingEditorRole

  • Claim: groups

  • Claim value: marketing

  • Is regex: unchecked

  • Client: admincentral

  • Role: page-editor

User attribute mappings

User attribute mappings let you populate user profile attributes in Magnolia based on values from the Identity Provider (IdP) token.

User attribute mappings are typically used to enrich Magnolia user profiles with data such as first name, last name, email, department, or any other identity-related field. This information can then be used for personalization, access control, or auditing within Magnolia.

Each mapping defines where the attribute value comes from, either from a claim in the IdP token or a hardcoded value, and maps it to a specific Magnolia user attribute.

user attribute mapping

To create a User attribute mapping:

  1. Go to the User attribute mapping tab.

  2. Click Add new mapping.

  3. Choose the Attribute based on option:

    • Existing claim: The value will come from a claim in the IdP token.

    • Hardcoded value: The value is fixed and set manually.

Use Existing claim when pulling values like email, first_name, or department from your IdP. Use Hardcoded value to assign a static value for all users (e.g., set "region": "EMEA" for everyone in a federation).

  1. Enter a Name for the mapping.

    This name helps you identify what the mapping is doing (e.g., SetEmailFromClaim or SetRegionToEMEA).

  2. If using Existing claim, enter the Claim name to extract the value from.

    This should match the name of the claim in the IdP token.

    Examples:

    • email

    • given_name

    • family_name

    • custom_department

    You can get valid claim names from your IdP administrator or documentation.

  3. Enter the User attribute.

    This is the Magnolia user attribute you want to populate.

    Examples:

    • email

    • firstName

    • lastName

    • department

    • region

    Make sure the attribute name matches what’s supported or expected in your Magnolia user profile structure.

Examples

To map the email claim from the IdP to the Magnolia email user attribute:

  • Attribute based on: Existing claim

  • Name: MapEmail

  • Claim: email

  • User attribute: email

Delete a Federation

  1. Go to Admin > Federations.

  2. Go to the stacked lines ☰ and click Delete.

  3. Confirm the deletion.

SSO clients

Our SSO module enables secure, authentication by integrating with your Identity Provider (IDP). This lets your users access a Magnolia instance using their existing credentials, streamlining workflows and enhancing security.

sso client overview

For DX Cloud deployments, configuring an SSO client is essential to connect your IDP to Magnolia.

If your IDP uses SAML instead of OIDC, we need to bridge the gap by routing authentication through Keycloak. Proper client configuration ensures smooth and secure access across your environments.

You must only create one SSO client per environment (e.g., production, integration).

Add configuration

To add an SSO client configuration:

  1. Go to Admin > SSO clients.

  2. Click Add.

  3. Choose your desired Environment in the dropdown menu. You must only create one SSO client per environment (e.g., production, integration).

  4. Click Enabled.

  5. If desired, add redirect URLs.

  6. Add the allowed CORS origins.

    CORS restrictions

    Web origins must be listed in the SSO client configuration to allow cross-origin requests.

    If your Magnolia instance is hosted at https://example-magnolia.com and you have a front-end app at https://frontend-app.com, you might configure the following web origins in the SSO client (e.g., in Keycloak):

    • https://example-magnolia.com

    • https://frontend-app.com

    This ensures both domains can participate in the SSO authentication flow without being blocked by CORS restrictions.

  7. Add the Base URL.

    The default URL to use when the auth server needs to redirect or link back to the client.

  8. Add any Magnolia roles you want mapped in the SSO module.

  9. Click Add.

    sso client details

Magnolia SSO Config

Once you have configured your SSO client:

  1. Go to your SSO client configuration in the SSO Client Config table.

  2. Click the three bars .

  3. Click Magnolia SSO Config to get your full Magnolia SSO module .yaml configuration. You can copy and paste the configuration directly into your SSO module. For detailed information on SSO module configuration, see Magnolia SSO module: Configuration.

    callbackUrl: "/.auth"
authorizationGenerators:
- name: "groupsAuthorization"
  groups:
    targetProperty: "groups"
    mappings:
    - name: "/admincentral"
      targetGroups:
      - "publishers"
      targetRoles:
      - "superuser"
    - name: "/power-editor"
      targetGroups:
      - "publishers"
      targetRoles:
      - "superuser"
clients:
  oidc.id: "magnolia-sso-integration"
  oidc.secret: "OIDC_SECRET"
  oidc.clientAuthenticationMethod: "client_secret_basic"
  oidc.scope: "openid profile email"
  oidc.discoveryUri: "https://id.int.example.com/realms/mplatform/.well-known/openid-configuration"
  oidc.preferredJwsAlgorithm: "RS256"
  oidc.authorizationGenerators: "groupsAuthorization"
  oidc.callbackUrl: "/.auth"
  oidc.postLogoutRedirectUri: "http://localhost:8080"
  http.bearer.id: "magnolia-sso-integration"
  http.bearer.secret: "OIDC_SECRET"
  http.bearer.clientAuthenticationMethod: "client_secret_basic"
  http.bearer.scope: "openid profile email"
  http.bearer.discoveryUri: "https://id.int.example.com/realms/mplatform/.well-known/openid-configuration"
  http.bearer.preferredJwsAlgorithm: "RS256"
  http.bearer.authorizationGenerators: "groupsAuthorization"
  http.bearer.authenticator: "oidc-userinfo"
userFieldMappings:
  name: "name"
  removeEmailDomainFromUserName: false
  removeSpecialCharactersFromUserName: false
  email: "email"
  language: "locale"
    sso client sso config
Feedback

PaaS

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the DX Cloud docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules