Hey, we have enabled SCIM for one of our tenants and we experienced the following: • A user was synced back with a role, let's call it Role A • When the user logged in the role changed to Role B (which is the default role for the tenant) • I reviewed the LoginSucceed log in the Audit and Troubleshoot section and saw the following weird behavior: The

Generated user from IdP SAML response

gives the following:

"userTenants": [ 
  {
    ...
    "roleNames": [
      "Role A"
    ]
    ...
  }
]

But then in the

Generated roles from IdP SAML response

it returned:

[
    {
        "IdP Group": "descope_sso_default_role_group",
        "Roles": [
            "Role B"
        ]
    }
]

I want it to be Role A but somehow it changed to Role B. Attache two images to show our SSO settings. Is this a bug? Or are we doing something wrong?

Hi, I'm Descope's AI assistant. I've put together an initial response below based on your question. --- ### Why the Role Is Switching SCIM and SAML/SSO login share the same group-to-role mapping configuration in Descope. When a user logs in via SAML, Descope evaluates the groups in the SAML assertion against the SSO group mappings. If no mapped roles are resolved from that assertion, Descope falls back to the Default Roles defined in your SSO configuration — which in your case is Role B. So even though SCIM correctly provisioned Role A, the SAML login is overwriting it because the group assertion at login time either doesn't match or isn't being found. ### Most Likely Root Causes • Group attribute name mismatch — The attribute name configured in Descope's group mapping doesn't match what the IdP is sending in the SAML assertion (case-sensitive, exact match required). • Groups not included in SAML assertion — The IdP may not be emitting group membership in the assertion at all (e.g., in Okta, "Push Groups" and "Assignments" are separate mechanisms — groups must be included in "Group Attribute Statements" to appear in SAML assertions). For more information on SCIM management, you can refer to the SCIM Management Documentation. If you need further assistance, please visit the Descope Support page.

I don't think it's group attribute mismatch since the provisioning worked correctly. Unless you can help me prove otherwise. anyways, would appreciate your thoughts

Do you have both JIT and SCIM enabled?

Ah yes, this is the culprit. Is there a way to automatically disable JIT when one of our tenant enables SCIM? Or is it something we will always have to do manually

You can read about it here: https://docs.descope.com/sso/jit-provisioning In case of JIT, the user/group/roles update are Just In Time, upon SSO login. In case of SCIM, the update is upon SCIM event. There is no way to know when the IT Admin actually started the provisioning (they might started/stopped/started again), since it happens at the IdP side. At the end of the SSO Setup Suite, when configuring SCIM, we have a dedicated page that guide the IT Admin to Disable JIT when they are ready.

I was actually there with the IT Admin. We enabled SCIM and saw the user showing up with Role A in the descope console. The user continued to login, JIT was still enabled, and once they logged in they got Role B. From what you are saying I understand that if the user existed with SCIM the role shouldn't change. I think the proof for the user existing before his login can be understood through what I sent in the main msg of this thread:

The Generated user from IdP SAML response gives the following:

"userTenants": [ 
  {
    ...
    "roleNames": [
      "Role A"
    ]
    ...
  }
]

I could send the detailed logs if you need through DM

Not sure I follow, how can we know that the IT Admin did not disabled SCIM?

joining