Hi, I’m trying to configure SSO tenants so they ca...
# ask-a-descoper
o
Hi, I’m trying to configure SSO tenants so they can define attribute mapping for groups. We need a way to retrieve the full dynamic list of groups from the IdP without knowing the group values in advance and without mapping them to predefined values or roles. To clarify, this is not about group-to-role mapping. I do not want to map groups to specific predefined roles. I want the user’s groups, exactly as they come from the IdP, to be mapped into a user attribute (or custom attribute) called
groups
, without needing to predefine the possible group values. At the moment, in the SSO settings, I can define attribute mappings that map attributes coming from the IdP to custom user attributes. However, custom user attributes do not seem to support a dynamic list type. When I define the
groups
custom attribute as a text attribute, the mapping only stores the first group. When I define it as a multi-select attribute without predefined values, the attribute mapping UI does not offer this attribute as a mapping target. Is there a supported way to map the full list of IdP groups into a user attribute dynamically?
✅ 1
d
Based on the search results, I can see that Descope supports multi-select custom attributes that can function as arrays. Let me provide a comprehensive answer about mapping dynamic IdP groups to user attributes. Custom Attribute Configuration You can map dynamic IdP groups to a custom user attribute using the multi-select type . Custom user attributes support these types: • Text • Numeric • Boolean • Single select • Multi select (functions as an array) • Date SSO Attribute Mapping Setup 1. Create a custom user attribute with type "multi select" without predefined values 2. In your SSO configuration, map the IdP groups attribute to this custom attribute
Copy code
{
  "attributeMapping": {
    "customAttributes": {
      "groups": "idp_groups_attribute_name"
    }
  }
}
Alternative Approach If the multi-select attribute without predefined values isn't appearing in the mapping UI, you can use the
customAttributes
field in the attribute mapping configuration . This allows mapping IdP attributes directly to custom user attributes . The documentation confirms that Descope allows mapping attributes from your IdP to custom user attributes when configuring attribute mapping , and multi-select attributes can be utilized as arrays . If you're still experiencing issues with the multi-select attribute not appearing in the mapping UI, this may be a UI limitation that requires using the Management API to configure the mapping directly. User Management | Descope Documentation SSO with SAML Provider | Descope Documentation Get Tenant's SAML/OIDC Settings | API Reference | Descope Documentation Configure Okta SSO as IDP | Descope Documentation Tenants | Descope Documentation
o
As I already mentioned, when defining a multi-select custom attribute, the attribute mapping UI does not offer this attribute as a mapping target.
d
You're correct - this appears to be a UI limitation where multi-select custom attributes without predefined values aren't showing up as mapping targets in the SSO configuration interface. Workaround Using Management API Configure the attribute mapping directly via the Management API instead of the UI:
Copy code
curl -X POST "<https://api.descope.com/v1/mgmt/tenant/settings/sso/saml>"  
  -H "Authorization: Bearer <ProjectId:ManagementKey>"  
  -H "Content-Type: application/json"  
  -d '{
    "tenantId": "your-tenant-id",
    "attributeMapping": {
      "customAttributes": {
        "groups": "your_idp_groups_attribute_name"
      }
    }
  }'
Alternative Solutions 1. Use the
group
field in attribute mapping
- Map your IdP groups attribute to the standard
group
field, then access the full groups array in your application logic 2. Custom Claims in JWT - Configure custom claims to include the groups data from the IdP response, making it available in your JWT tokens The UI limitation you've identified is a known gap where multi-select attributes without predefined options don't appear in the mapping dropdown. The API approach bypasses this UI restriction and should allow you to map the dynamic groups list to your custom attribute. Get Tenant's SAML/OIDC Settings | API Reference | Descope Documentation
c
@Bhagwanta Yeole @Nick Rodriguez @Avi Glozman can you help here?
👀 1
👍 1
b
Hey @Ori Shalom , I’m checking this with our internal team and will get back to you with an update as soon as possible.
a
Hey @Ori Shalom - Unfortunately this isn't something that's currently supported, but it's something our team can look into.
o
Thanks for checking. I wanted to emphasize that this is an important capability for us because it is coming up from customers, not just as a nice-to-have on our side. Our platform includes features around sharing access to resources, and customers want the ability to base that access on IdP groups. Typical examples are sharing a resource with a group, allowing same-group access, and similar group-based access control patterns. For these use cases, mapping groups to predefined roles is not sufficient. We need access to the user’s actual groups dynamically, as provided by the IdP, without having to know the possible group values in advance. If there is any way to provide support for this capability in the short term, we’d greatly appreciate it. If not, any workaround or interim approach you can suggest in the meantime would be very helpful as well. FYI @Ariel Shiftan
a
Appreciate the clarification; Descope does support SCIM, which would allow you to access a user's groups dynamically, as they would be pushed through directly from the IdP.
o
Hi @Avi Glozman, I originally tried only with SAML. Trying with SCIM now I’m not sure how to eventually map the groups attribute into a JWT claim. I tried doing so with flow and defining JWT template and also mapping it to custom attribute but all with no luck. Can you share maybe exact instructions or maybe suggest time to debug this together? I’ll also mention that require SCIM is a bit limiting because not all customers will have SSO with SCIM but I guess it’s better than nothing for initial solution.
d
Hi @Ori Shalom There are two ways to get the user’s groups. 1. SSO JIT - upon login time the user’s groups are sent via the SAML/OIDC response 2. SSO SCIM - upon group events the groups are sent via the SCIM event (not related to the login) For the 1st bullet (JIT), you can just take the
idpGroups
after the SSO action and append them to the JWT using the custom claims action. For the 2nd bullet, it is a bit tricky since the groups are not there upon login, so you can use the management API to get the groups and append them to the JWT in the same way. (Soon we gonna add a flow action to get the user’s group). However, please note that embedding all groups directly in the JWT may not be ideal. In cases where users belong to many groups, this can significantly increase the token size and potentially cause issues (e.g., browser limitations on header size). A more scalable approach would be to fetch the relevant user groups from your application using the Groups API when needed, rather than including them all in the JWT.
For example on how to add to the JWT, you can just search for “idp groups” in the flows library and see.
o
Thanks, will try. I noticed the
idpGroups
prop is not scoped to user (it’s not
user.idpGroups
). Will it return the actual user groups or all idp groups?
d
It returns the IdP groups coming from the SSO SAML/OIDC response upon JIT login (not scim) As wrote above there are two cases. For SCIM there is a need to do api call currently to get the groups (since they are not coming upon login) and then you can use the same custom claims action to add to the JWT.
To clarify, it will return only groups for the user that is logging in via SSO. Not all IdP groups of the tenant.
Hi @Ori Shalom We added support for fetching also the user’s SCIM IdP groups, just mark the checkbox in the SSO flow action (see below image) And you will have them all under the
idpGroups
, which you can use later (add to JWT, etc.)
o
Thanks @Doron Sharon, this is super helpful! We’ll give it a try.