Single Sign-On (SSO)
Single Sign-On (SSO) is an authentication method that allows agents to access the Surfly platform using their existing corporate credentials, managed through a central identity provider. This integration centralizes user management, enforces corporate security policies, and simplifies the login process for users.
What you need to know about Single Sign-On (SSO)
Single Sign-On (SSO) is an authentication process that enables users to log in once using their corporate credentials and access multiple independent systems - including Surfly - without needing to re-enter their username and password at each application. SSO relies on a central Identity Provider (IdP), such as Okta, Microsoft Entra ID (formerly Azure AD), Ping Identity, or Google Workspace, to manage user identities and provide security tokens that connected applications trust.
When an agent attempts to log into Surfly, the platform redirects them to their company's SSO login page. The agent authenticates using their standard corporate credentials, which may include multi-factor authentication (MFA). Once the IdP successfully verifies the user's identity, it sends a secure assertion—typically using the Security Assertion Markup Language (SAML 2.0) protocol—back to Surfly. This assertion confirms the user's identity and grants them access to the platform with the appropriate permissions.
This architecture means that an organization's IT and security teams retain full control over who can access Surfly, without needing to manage users directly in the Surfly admin dashboard. It makes Surfly a managed application within the company's broader IT ecosystem.
Key SSO Integration Features
Integrating an IdP with Surfly enables several important capabilities for managing user access at scale:
- Centralized Authentication: Agents use one set of credentials for Surfly and all other corporate applications, reducing password fatigue and helpdesk requests.
- Automated User Provisioning: With Just-in-Time (JIT) provisioning, an agent's Surfly account is automatically created on their first successful SSO login. For more advanced management, SCIM (System for Cross-domain Identity Management) can be used to automatically create, update, and deactivate users in Surfly based on changes in the IdP.
- Role-Based Access Mapping: SSO assertions can contain user attributes, such as department or group membership. Surfly can use this information to automatically assign roles (e.g., Agent, Manager, Admin) to users upon login, ensuring they have the correct level of access.
The importance of Single Sign-On (SSO)
The integration of Single Sign-On (SSO) with Surfly provides a better and more secure experience for both agents and administrators. It allows users to access the Surfly platform using their familiar corporate credentials, removing the friction of managing a separate password. For the organization, this method of authentication strengthens security posture while making daily operations more efficient.
Strengthen Centralized Access Control
SSO shifts the responsibility of user authentication from the Surfly platform to the company's own identity management system. This allows security policies, such as password complexity and MFA, to be enforced consistently for Surfly access, just as they are for other corporate applications. This direct link to a central user directory provides organizations with several security advantages:
- Enforces mandatory MFA as configured in the corporate IdP.
- Automates the de-provisioning of agents, instantly revoking Surfly access when an employee leaves the organization.
- Maintains a single, authoritative source for user identity, reducing the risk associated with disparate credential management.
- Produces detailed audit logs within the IdP, showing every authentication event for compliance reporting.
A Practical Example of Single Sign-On (SSO)
Frequently asked questions about Single Sign-On (SSO)
We’ve compiled answers to the most frequently asked questions about
Single Sign-On (SSO)
.
Surfly supports any IdP that works with SAML 2.0, OpenID Connect (OIDC), or OAuth 2.0, including Okta, Microsoft Entra ID/Azure AD, Google Workspace, Ping Identity, and others.
Yes. Surfly can consume role or group attributes from the IdP’s SAML/OIDC assertions to automatically assign Surfly roles (e.g., agent, admin) at login.
Yes, when SSO is enabled, users authenticate through the identity provider. They don’t need a separate Surfly username/password unless fallback local login is explicitly enabled for specific cases (e.g., admin emergency access).
Surfly defers MFA enforcement to your IdP. If MFA is required at the IdP level, it applies to Surfly access automatically.