Troubleshooting Issues with Single Sign-On (SSO)

A user’s role can provision differently during single sign-on (SSO) due to mismatched group memberships, attribute misconfigurations, or how Call Simulator handles provisioning and role mapping data coming from the customer SSO via SAML (Security Assertion Markup Language). Specifically, a user may be in a nested group that the provisioning service cannot read, or the attributes sent from the identity provider (IdP) may not match the roles configured in the Call Simulator. 

Causes of mismatched roles during SSO provisioning

• Nested group limitations: Some provisioning services, like Microsoft Entra ID, cannot read users in nested groups in order to pass the data successfully in SAML assertions during SSO. Only users in explicitly assigned groups that are direct members may be provisioned, leading to different roles for users in nested groups.
• Incorrect or missing attribute mapping: The user’s attributes sent from the identity provider (e.g., SAML response, OpenID token) must precisely match what Call Simulator expects for role assignment. If there is a mismatch in user details or group memberships, Call Simulator may not provision the correct role. The exception to this is if the role claim / assertion from SAML is “role mapped” in Call Simulator. In other words, if the SAML role for a customer named ACME is called “ACME_trainee”, Call Simulator won’t know how to assign a role for that claim or assertion unless there is a prior role mapping from “ACME_trainee” to a Call Simulator role, such as “Learner”.
• Provisioning and role mapping settings: Call Simulator’s provisioning settings and how it maps incoming claims or tokens to roles can cause differences.
  • Manual vs. automatic provisioning: If a user is already provisioned in Call Simulator, a successful SSO process will update the authorization (roles) to be whatever comes in from a successful SSO login - aka Just in Time (JIT) provisioning.
  • Conditional access policies: Advanced configurations in the customer’s IdP or Identity and Access Management system (IAM), like conditional access policies in an SSO setup, can dynamically alter a user’s access or role based on factors like location, device, or other contextual information, leading to different roles being assigned in different scenarios. Any changes of that nature would happen “upstream” in the customer’s IdP or IAM environment in order to pass roles / authorization into Call Simulator.
• Time synchronization issues: In some cases, a mismatch in the system time between the identity provider and the service provider can cause the SAML token to be seen as invalid, leading to provisioning errors. 

How to troubleshoot

• Check group memberships: Ensure the user is in a group that is directly assigned to Call Simulator, not a nested group.
• Synchronize system clocks: Ensure the clocks on all relevant servers are synchronized to prevent time-related errors. 

Should you continue to experience issues with SSO, please do not hesitate to reach out to Support@CallSimulator.com to schedule a meeting with your SSO administrator and our tech team. We are happy to help!