Authentication 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.

• 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.

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.

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).

• 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.