Skip to content
English - United States
  • There are no suggestions because the search field is empty.

Troubleshooting Issues with Single Sign-On (SSO)

This article reviews possible issues with an organization's SSO set up, including SSO not completing and role access issues via SSO for Call Simulator. 

 

SSO Not Completing - Call Simulator Tenant Login Page Showing Instead:

  • If SSO is not completing silently for users already logged into your SSO IdP or otherwise not flowing into your SSO IdP process as expected, the issue may be with pop-up blockers. The Call Simulator SSO flow involves launching your IdP authentication flow via a pop-up window. This pop-up may have elements that are unique to your environment and IT choices, such as how you authenticate yourself. Regardless of those specifics, a pop-up is a part of the current SSO flow.

  • If a user is not automatically authenticating as expected, and you believe SSO is otherwise configured properly and testing properly from Call Simulator, please check for a blocked pop-up in the user's browser and session. Different browsers show blocked pop-ups differently, sometimes near the browser address bar or plug-in list or settings controls.

SSO Set Up and Role Access Issues:

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!