Skip to content

Role Not Applied As Per Mapping

SSO Troubleshooting

This guide helps when a user signs in through SSO successfully, but does not receive the Trust3 AI role configured in your role mapping.

Symptom Description Resolution
User signs in but gets the default ROLE_USER instead of the mapped role. Trust3 AI did not receive any group or role values from your Identity Provider (IdP), so there was nothing to match against your role mapping. Confirm your IdP is sending the group attribute, and that its values match your role mapping.

When no group or role values reach Trust3 AI, the default role ROLE_USER is assigned. The sign-in itself still succeeds, so no error is shown.

Resolution steps

  1. In Settings → Identity, check the Role Name Attribute value. It must exactly match the name of the attribute your IdP sends.
  2. Check that your IdP is actually configured to send that attribute. In most IdPs the group or role claim is optional and is not sent by default.
  3. Check that the values match your Role Mapping. If your IdP sends group IDs, the mapping must contain group IDs. If it sends group names, the mapping must contain names.
  4. Ask an affected user to sign out fully and sign in again, then confirm the role.

Azure AD sends no groups when a user belongs to more than 150 groups

Azure AD limits a SAML assertion to 150 groups. Above that limit it omits the group attribute entirely rather than shortening it, which produces exactly this symptom.

See Group claim missing for users in many groups on the Azure AD page for how to resolve it.

Once the group attribute is reaching Trust3 AI, users who were created earlier may still hold the default role. An administrator with the Account Admin or AI Gov Admin role can delete those users from Settings → Users, after which they are recreated with the correct role on their next SSO sign-in.

For additional assistance, contact the Trust3 team at support@trust3.ai.