Iron Cove Resources
How SAML WorksSAML operates through a series of steps to authenticate users and share identity information.
The most common scenario is the Web Browser SSO Profile, but I’ll also explain the Single Logout (SLO) process relevant to your Okta query.
Step 1. Web Browser SSO Flow
Here’s how SAML enables SSO:User Attempts to Access an SP:The user navigates to an SP (e.g., Salesforce) via their browser.
If the user isn’t authenticated, the SP redirects them to the IdP (e.g., Okta.
IdP Authenticates the User:
The IdP prompts the user to log in (if not already authenticated). Authentication can involve username/password, multi-factor authentication (MFA), or other methods. Once authenticated, the IdP generates a SAML assertion.
SAML Assertion is Sent to the SP:
The IdP sends the SAML assertion to the user’s browser, typically via an HTTP POST or Redirect binding. The assertion is digitally signed to ensure it hasn’t been tampered with.
SP Grants Access:
The SP verifies the assertion’s signature and extracts user information (e.g., identity, roles). If valid, the SP grants the user access to the application.
This process allows the user to access multiple SPs without re-authenticating, as long as their IdP session remains active.
Step 2. Single Logout (SLO) Flow
SLO extends SAML to enable a single logout action that terminates sessions across both the IdP and all connected SPs. This addresses the security risks you mentioned, such as session hijacking, XSS, and man-in-the-middle attacks.
Here’s how it works:User Initiates Logout:
The user logs out from either the IdP (e.g., Okta) or an SP (e.g., a web app). The logout request is sent as a SAML LogoutRequest message.
IdP Processes the Logout:
If the logout is initiated at the SP, the SP sends a LogoutRequest to the IdP. The IdP terminates the user’s session and identifies all SPs where the user has active sessions (based on session tracking).
IdP Notifies SPs:
The IdP sends LogoutRequest messages to each SP, typically via the user’s browser (using HTTP Redirect or POST bindings). Each SP terminates its local session and may send a LogoutResponse to confirm.
Completion:
Once all sessions are terminated, the IdP sends a final LogoutResponse to the initiating system (SP or browser), confirming the logout. The user is fully logged out across all systems.
Okta SLO Context
As your query highlighted, without SLO, logging out of an SP only clears the local session, not the Okta IdP session. If Okta redirects unauthenticated users back to the SP (a common configuration), a new session is created, negating the logout. Okta’s SAML-based SLO ensures that both the Okta session and SP sessions are terminated, reducing vulnerabilities like session hijacking or XSS by ensuring no active sessions remain.
Ask us about Solving your Single Logout via SAML for your Okta instance and custom applications.
If you have further questions, just call and lets chat your situation.
Cloud Licensing Providers we support
| Provider | Description |
|---|---|
| Dropbox | Cloud File |
| Google WorkSpace | Cloud Tools |
| Microsoft Office 365 | Suite of Tools |
| Okta | Cloud Identity and Security |
| Orchestration Engine | Provisioning Engine |
| ProofPoint | Email Filtering |
| Global Relay | Email and Document Archiving |