Automatic SSO integration: how it works end to end

Rolling out a security awareness program to ten thousand employees carries a cost that almost no one puts on the table at the start: creating and maintaining ten thousand accounts. Every hire, every departure, every role change is one more user to provision on one more platform, with one more password the employee will forget. Login looks like a minor detail until you multiply it by the headcount of a large group, and at that point it stops being minor.

SSO removes that friction, but it usually gets sold as a checkbox (“does it have SSO? yes”) without explaining what actually happens between the moment the employee clicks and the moment they’re in the program. That “what actually happens” is what decides whether the integration takes an afternoon or turns into a multi-week project. The Verizon DBIR consistently places stolen credentials among the top initial-access vectors into organizations, so reducing the number of passwords each employee juggles isn’t just convenience but attack surface that shrinks.

What SSO does (and doesn’t) solve in an awareness platform

Single sign-on (SSO) is the mechanism by which an employee accesses the platform with the same corporate credentials they already use for the rest of their tools, without creating or remembering a username and password specific to the platform. Authentication isn’t solved by the platform: it’s delegated to the organization’s identity provider (IdP), which already knows who that person is.

That’s exactly what it solves, and it’s worth being precise about the boundary. SSO answers the question ”is this person who they claim to be?” at the moment of access. It doesn’t answer ”should this person exist in the platform at all?”. That second question (creating, deactivating, and updating accounts) is provisioning, and it’s a separate problem solved by a different piece. Confusing the two is the most common reason a deployment “with SSO” still hides manual work.

How does the SSO authentication flow work end to end?

The standard behind most of these integrations is SAML 2.0. SAML has two actors: the identity provider (IdP), which is the corporate system where the employee’s identity lives, and the service provider (SP), which in this case is the awareness platform. The end-to-end flow, when the employee starts from the platform, goes like this:

1. The employee opens the platform and it detects there’s no active session.
2. The platform (SP) redirects the browser to the corporate IdP with a signed authentication request.
3. The IdP authenticates the employee with its own rules: password, second factor, conditional access policies, whatever the organization has configured.
4. If authentication succeeds, the IdP returns a signed SAML assertion to the browser, a document stating “this person is who they claim to be, and these are their attributes”.
5. The platform validates that assertion’s signature against the IdP’s certificate, reads the attributes, and opens the session.

The employee sees only one thing: they click and they’re in. The whole exchange of the request, the assertion, and the signature validation happens in milliseconds and without them typing anything. The other possible starting point is the reverse, where the employee starts from the corporate portal (IdP-initiated) and jumps into the platform already authenticated, but the mechanics of the signed assertion are the same.

What matters for anyone evaluating the platform is that trust doesn’t rest on a password shared between two systems, but on cryptography: the SP trusts the IdP because it can verify its signature, not because it stores a secret. That’s why SSO is more secure than replicating passwords, and it’s the same logic of delegating to the right system that we apply when we explain why we integrate by API and not by agent.

Are SSO and user provisioning the same thing?

No, and keeping them apart is what lets the program scale without manual work. SSO authenticates; provisioning creates, updates, and deactivates accounts. An employee can only authenticate via SSO if their account already exists in the platform, so provisioning is the prior step you have to solve separately.

Provisioning can be handled two ways without adding accounts by hand, and they’re not equivalent. The one that sustains the program over time is directory synchronization: the platform connects to the corporate directory, via LDAP or importing from Microsoft Entra ID or Google, and keeps the employee roster aligned with the organization’s source of truth. When someone joins or leaves the company, the change propagates without the program owner touching anything.

The other option, simpler to start with, is importing the roster manually from a CSV file, when you’d rather not connect the full directory. It works for the initial rollout, but it’s a snapshot of one moment and doesn’t reflect later joiners or leavers. Deactivation, moreover, is the case that matters most from a security standpoint: an employee who left the company but still has an active account is a gap.

That’s why directory-based provisioning, where deactivating the employee in the corporate system carries over to their status in the platform, is the one that closes that gap at the root. It’s the same single-source-of-truth principle behind how directory synchronization with Microsoft Entra ID (formerly Azure AD) works.

What makes an SSO integration “automatic” and not a multi-week project?

The difference between an afternoon’s integration and one that runs for weeks isn’t the standard (SAML is the same for everyone) but how much of the setup depends on exchanging configuration files by hand. An automatic integration reduces that setup to three things handled cleanly:

1. Metadata exchange instead of manual configuration. The IdP and the platform describe each other with a standard metadata file (URLs, certificates, identifiers). Loading that metadata from one side to the other replaces copying and pasting individual fields, which is where the hard-to-diagnose errors show up.
2. Explicit attribute mapping. The IdP’s assertion carries attributes (name, email, department, maybe the subsidiary’s country) and the platform needs to know which field each one maps to. Defining that mapping once, with judgment, is what avoids having to tweak it every time a new employee comes in.
3. One IdP per tenant when there are several organizations. In a group with subsidiaries, each one may have its own identity provider. A multi-tenant architecture lets each subsidiary connect its IdP without stepping on the others, something that becomes necessary once you’re sustaining a multi-language program with HQ in Spain and subsidiaries in LATAM.

When those three things are handled, adding SSO stops being a project milestone and becomes a configuration step. The employee never sees any of this, which is exactly the point.

How does SSO fit into SMARTFENSE’s architecture?

SMARTFENSE solves authentication by delegating it to each organization’s identity provider. The platform supports universal authentication via SAML 2.0, which lets it integrate with any IdP that speaks the standard, and it also imports and authenticates employees directly from Microsoft Entra ID and Google, and supports authentication from Auth0. Provisioning is covered by the other track: user synchronization via the LDAP directory and importing from those same providers, so the employee roster stays aligned with the organization’s source of truth.

For the cases that need to go beyond what configuration solves (automating hires and departures with custom logic, or connecting the roster to another internal system), the platform exposes a documented REST API with OAuth 2.0 and JSON for user management and results. The full list of these identity and directory integrations is on the platform integrations page, and how employees are managed once inside is covered in users and smart groups.

The result, seen from the program’s operation, is that the responsible team doesn’t administer passwords or add accounts by hand: identity is solved by the system that already held it, and the platform handles its own job, which is measuring and changing people’s behavior.

Frequently asked questions

Does SSO mean SMARTFENSE stores my employees’ passwords?
No. With SSO the platform never sees or stores the corporate password. Authentication happens at the organization’s identity provider, which returns a signed assertion; the platform only verifies that signature to open the session.

Can I use SSO without synchronizing my whole directory?
Yes. SSO authentication and account provisioning are independent pieces. You can authenticate via SAML and load the roster by importing it from a CSV file, or synchronize the directory via LDAP to keep hires and departures aligned. They’re separate decisions.

What happens when an employee leaves the company?
If provisioning is directory-based, deactivating the employee in the corporate system propagates to the platform and their access is closed without manual intervention. This is the point most worth solving through synchronization rather than on-the-fly account creation.

Is SSO useful for a group with several subsidiaries?
Yes. A multi-tenant architecture lets each subsidiary connect its own identity provider independently, keeping the program unified at the group level while each organization’s authentication is handled separately.

How long does an SSO integration take?
It depends on whether the setup relies on metadata exchange and attribute mapping defined once, or on manual field-by-field configuration. With the former, adding SSO is a configuration step; with the latter, it stretches out because of hard-to-diagnose errors.

If you’re evaluating how to take your awareness program to the whole organization without adding one more password or provisioning accounts by hand, the SMARTFENSE platform solves authentication and provisioning by leaning on the identity your organization already manages.