SSO with SAML 2.0
Quick answer
Configure single sign on: identity provider records, certificates, user matching, failover and testing without locking yourself out.
Key takeaways
- Keep the side door and a local admin until SSO is proven
- Match on a stable attribute, usually user principal name
- Watch certificate expiry dates, they cause outages every year
- Provision users before enabling enforced SSO
The pieces
The Integration Hub multi provider SSO plugin creates an identity provider record holding the IdP metadata, certificate and the field used to match the assertion to a user. Most projects match on user_name or email.
Do not lock yourself out
Always keep local authentication available while testing. Use the side door URL, instance.service-now.com/side_door.do, and keep at least one local admin account with a strong password. Test the IdP record with the Test Connection button before you set it as default.
Common failure points
Most SSO tickets come down to four things.
- Certificate expired at the identity provider
- Assertion attribute name changed and no longer matches the user field
- Clock skew between IdP and instance
- Users exist in the IdP but not in ServiceNow, so provisioning has to run first
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which URL bypasses SSO for local login?
- A. /login.do
- B. /side_door.do
- C. /navpage.do
- D. /sso.do
Show answer
B. /side_door.do
side_door.do presents the local login form when SSO is enabled.
Most common cause of a sudden SSO outage?
- A. A new user role
- B. Expired signing certificate
- C. Browser cache
- D. A cloned instance
Show answer
B. Expired signing certificate
Certificates expire on a schedule and break the trust relationship.