Authentication flow
Quick answer
A login is validated against an SSO provider (SAML/OIDC) or via pass-through authentication to a directory, then a session is established.
Key takeaways
- Purpose: verify a user is who they claim before granting a session
- Trigger: A user attempting to sign in
- Outcome: A validated session with the correct capabilities
- Where it fits in the SailPoint architecture
The authentication flow is the sequence by which a user login is validated and a session established in IdentityIQ. Although SailPoint's core purpose is governing authorization, users and administrators still have to get in, and in most enterprises that login is delegated to an identity provider. Knowing the flow helps you diagnose the surprisingly common federation failures.
What triggers the flow
The flow begins whenever a user attempts to reach the IdentityIQ UI or an authenticated API. The path taken depends on how authentication is configured: pass-through, SAML/OIDC single sign-on, or rule-based SSO.
Step by step (SSO model)
- 1. Access attempt. The user requests an IdentityIQ page; no valid session exists.
- 2. Redirect to the IdP. IdentityIQ, acting as a SAML service provider or OIDC relying party, redirects the browser to the identity provider.
- 3. Authentication at the IdP. The IdP validates credentials and enforces MFA, then issues a signed assertion (SAML) or token (OIDC).
- 4. Assertion consumed. IdentityIQ validates the signature and time window, then reads the asserted identifier.
- 5. Identity resolution. That identifier is matched to an IdentityIQ identity, and the user's capabilities are loaded.
- 6. Session established. A session is created and the user lands on their intended page.
Pass-through and rule-based variants
In the pass-through model, steps 2-4 are replaced by IdentityIQ binding the entered credentials against a directory such as AD. In rule-based SSO, an upstream proxy asserts the user via a header and an SSO rule logs them in. All variants end the same way: an IdentityIQ identity resolved and a session created.
Why authentication is separate from authorization
This flow only proves who the user is. What they can then see and do inside IdentityIQ is governed by their capabilities and scope, that is authorization, a separate concern. Keeping the two mentally distinct is essential when troubleshooting "I can log in but cannot see X" (authorization) versus "I cannot log in at all" (authentication).
Common pitfalls
- Expired signing certificates on the IdP or SP, the top cause of sudden SSO failure.
- Clock skew invalidating time-bound assertions.
- Identifier mismatch, the asserted value not matching any identity, so login succeeds at the IdP but fails to resolve.
- No break-glass admin login for when the IdP is unavailable.
Want to learn this properly?
Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.
Check your understanding
What triggers the authentication flow?
- A. A validated session with the correct capabilities
- B. A user attempting to sign in
- C. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
Show answer
B. A user attempting to sign in
A user attempting to sign in
What is the outcome of the authentication flow?
- A. A user attempting to sign in
- B. A validated session with the correct capabilities
- C. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
Show answer
B. A validated session with the correct capabilities
A validated session with the correct capabilities
Where does this flow run?
- A. A validated session with the correct capabilities
- B. A user attempting to sign in
- C. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
Show answer
C. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.