Mapping Single Sign-On Users to Roles or Teams in Anypoint Platform

Map the users in a federated organization’s group to a team or role to maintain secure credentials and organizational structure for accessing privileged information. Users in an external organization can then log in to Anypoint Platform using the same organizational credentials and access permissions that an external organization maintains using SAML, OpenID Connect (OIDC), or LDAP.

Anypoint Platform requires different information from your identity provider (IdP) based on whether you use SAML, OpenID Connect, or LDAP. User mappings apply only to the IdP you configured them for.

Before You Begin

Have the Organization Administrator permission in the root Anypoint Platform organization.
Configure an external identity provider (IdP), such as PingFederate, for your Anypoint Platform organization.
Create and configure the single sign-on (SSO) app in your IdP.
Make sure the user or identity of the group of users is created in the identity provider.

Add Group Mappings

Sign in to Anypoint Platform using an account that has the Organization Administrator permission.
Select Access Management from the menu.
In the Access Management navigation menu, click Teams.
Select the team to add the external IdP group to.
Select External IdP Groups.
Enter the name of the group in Group Name.
In Provider Name, select the name of the identity provider.
In Type, select Member, and then click Add.
Click Save Changes.

The SSO users associated with the group you mapped are assigned to the team.

Configure Multiple Group Mappings for Single Sign-On Using SAML

If your organization uses single sign-on but requires permissions from multiple groups, configure an attribute that contains all the groups for individual access permission. You can also create an array of groups.

For example, if your IDP provides your groups in this format, you must create an attribute that encompasses multiple group mappings to prevent security vulnerabilities:

<ns2:Attribute Name="Groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
  <ns2:AttributeValue>Mule_Org_Admin_XXX</ns2:AttributeValue>
</ns2:Attribute>
<ns2:Attribute Name="Groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
  <ns2:AttributeValue>Mule_Exchange_XXX</ns2:AttributeValue>
</ns2:Attribute>

In this example of a SAML assertion, the Group Attribute is Groups:

<ns2:Attribute Name="Groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
  <ns2:AttributeValue>Mule_Org_Admin_XXX</ns2:AttributeValue>
  <ns2:AttributeValue>Mule_Exchange_XXX</ns2:AttributeValue>
</ns2:Attribute>

Verify that the value in the Group Attribute field matches the name of the SAML attribute that contains the group names.

Configure Multiple Group Mappings for Single Sign-On Using OpenID Connect (OIDC)

External identity providers format groups claims in different ways. Anypoint Platform checks the UserInfo response for the groups claim. If the response for the groups claim isn’t found, Anypoint Platform then checks the Token endpoint response.

Use groups claims values to create a team or role for each group of users in your organization:

Obtain a response to the UserInfo or Token endpoint that contains a groups claim from your external identity provider.
If your IdP requires an additional OIDC scope to authorize access to groups claims, enter it in the Group Scope field.
Verify that the JSONata query in Group Attribute JSONata Expression yields an array of group names from either the UserInfo or Token endpoint response.

Examples of OIDC Group Expressions

These examples show responses from the UserInfo or Token endpoints that contain groups claims from different external identity providers.

Entra ID

This example shows a typical Entra ID groups claim:

{
    ...
    "roles": "[
        \"Everyone\",
        \"groupOne\"
    ]",
    ...
}

Given that groups claim, the JSONata expression is $eval($string(roles)).

Okta

This example shows a typical Okta groups claim:

{
 ...
  "groups": [
    "Everyone",
    "groupOne"
  ]
}

Given that groups claim, the JSONata expression is groups.

Auth0

This example shows a typical Auth0 groups claim:

{
  ...
  "https://anypoint.mulesoft.com/groups": [
    "MyGroup",
    "groupOne"
  ]
}

Given that groups claim, the JSONata expression is https://anypoint.mulesoft.com/groups.

Salesforce

This example shows a typical Salesforce groups claim:

{
  ...
  "custom_attributes": {
    "PermissionSets": "groupOne,groupTwo"
  }
}

Given that groups claim, the JSONata expression is $split(custom_attributes.PermissionSets, ',').

Configure Multiple Group Mappings for Single Sign-On Using LDAP

You can obtain the information you need to map your LDAP group to a team or role using a SAML assertion.

User management through LDAP is available only for Anypoint Platform Private Cloud Edition.

This is an example string from the SAML assertion AttributeValue to the External group name:

<saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:type="xs:string">cn=jira-users,ou=groups,dc=muleforge,dc=org</saml:AttributeValue>

This shows an example of an external group mapping:

An example of a list of external group names

Map SSO Users to Teams

If you delete your IdP configuration, your associated team mappings are also deleted.

You can map SSO users to teams by including their group names.

If a user has multiple group names that map to a single team, the group name that grants the most permissions is used. For example, if the Acme team has a Member group of engineering-all and a Maintainer group of engineering-managers, a user with both engineering-all and engineering-managers group names becomes a maintainer. If a user is explicitly designated as a maintainer of a team and has a group name that gives them member status, the group name is ignored, and the user remains a maintainer.

Sign in to Anypoint Platform using an account that has the Organization Administrator permission.
Select Access Management from the menu.
In the Access Management navigation menu, click Teams.
Click the team to modify.
Click the External IdP Groups tab.
In the Group Names field, enter one of the following:
- SAML: The group attribute that comes from your array of SAML groups
- OIDC: The groups claims values that come from the UserInfo or Token endpoint responses
- LDAP: The string from your SAML assertion AttributeValue
In the Type drop-down, select Member or Maintainer.

If you select Maintainer, users who have that group name become team maintainers for this team. If you select Member, users who have this group name become team members.
In the Provider Name drop-down, select the IdP associated with the mapping.
Click Add.
Click Save Changes.

The SSO users associated with the group you designated are assigned to the team.

API Access to Team Group Mappings

To access team external IdP group mappings using the Access Management API (for example, GET /organizations/{orgId}/teams/{teamId}/groupmappings), have one of these permissions:

Access Controls Viewer (view:access_controls) - View team group mappings via API
Access Controls Admin (admin:access_controls) - Create, update, or delete team group mappings via API

Map SSO Users to Roles

You map groups of SSO users to roles in your organization. However, MuleSoft recommends using the Teams feature to manage user permissions.

Sign in to Anypoint Platform using an account that has the Organization Administrator permission.
Select Access Management from the menu.
In the Access Management navigation menu, select Business Groups.
Select the name of the organization to access.
Select the Roles tab.
Click the role you want to modify.
Click the External IdP Groups tab.
In the Group Names field, enter one of the following:
- SAML: The group attribute that comes from your array of SAML groups
- OIDC: The groups claims values that come from the UserInfo or Token endpoint responses
- LDAP: The string from your SAML assertion AttributeValue
In the Provider Name drop-down, select the IdP associated with the mapping.
Click Add.
Click Save Changes.

The SSO users associated with the groups you designated are assigned the role.