Authentication

Authentication answers a single question: are you who you claim to be? In identity and access management it is abbreviated AuthN, and it is deliberately separated from authorization (AuthZ), which decides what a proven identity is allowed to do. Confusing the two is one of the most common conceptual errors newcomers make, so it is worth nailing down before going further.

• Authentication (AuthN): verifying identity. "This request is genuinely from Priya." Achieved with passwords, MFA, certificates, biometrics or federated tokens.
• Authorization (AuthZ): deciding permitted actions. "Priya may read the finance ledger but not approve payments." Achieved with entitlements, roles and policy.

SailPoint's centre of gravity is authorization, governing what access people hold and whether it is appropriate. It does authenticate its own administrators and users, but in most enterprises it delegates login to a dedicated identity provider and focuses on governance.

IdentityIQ supports several authentication models, and real deployments usually combine them:

The simplest model. IdentityIQ validates the entered credentials against a target application, typically Active Directory or an LDAP directory, by attempting a bind. No passwords are stored in IdentityIQ; it simply asks the directory "are these credentials valid?" This is common for smaller or on-premise deployments.

The enterprise standard. IdentityIQ is configured as a SAML service provider or OIDC relying party and redirects login to an identity provider such as Okta, Entra ID, Ping or ForgeRock. The IdP performs authentication (including MFA) and returns a signed assertion or token; IdentityIQ trusts it and establishes a session. This keeps a single, consistently-enforced login experience across the whole estate.

For environments already fronted by a web-access-management layer or reverse proxy that injects a header, IdentityIQ can use an SSO rule to read the asserted user and log them in without a second prompt.

A frequent question is "does SailPoint do MFA?" In the SSO model, multi-factor authentication is enforced at the identity provider, not in SailPoint. The IdP challenges for the second factor and only then issues the assertion IdentityIQ consumes. SailPoint does provide its own strong-authentication options for sensitive self-service actions such as password reset, but the primary MFA control point is the IdP.

In SailPoint's SaaS platform, Identity Security Cloud, SSO integration with an identity provider is the standard and expected configuration. The platform is accessed through the customer's IdP, so authentication is externalised by design and governance remains SailPoint's job.

Delegating authentication to a purpose-built IdP means MFA, adaptive/risk-based login, passwordless and session policy are all managed in one place by a tool designed for it, while SailPoint concentrates on the harder, less commoditised problem of governing authorization at scale. When you design a deployment, decide early which IdP owns login, then wire SailPoint to trust it.

• Treating SailPoint as an IdP. It governs access; it is not your primary login and MFA engine.
• Certificate and clock issues break SAML silently, expired signing certs and time skew between SP and IdP are the top causes of federation failures.
• Not planning a fallback admin login in case the IdP is unavailable, which can lock administrators out entirely.