Plan requirement
| Subscription | Any plan |
| Access | Admin |
Keeping single sign-on working. Almost everything that breaks it is a date somebody did not write down. Zendesk supports SAML, OpenID Connect and JWT, and you can run multiple active configurations of all three at once, each assigned to a different collection of users. A collection of users is not a brand: single sign-on is set for the account as a whole.
Review it
- In Admin Center, click Account in the sidebar and select Security > Single sign-on.
- Check which configurations are active, and for whom.
- Note the expiry of every certificate and secret.
- Confirm the fallback route is what you intended, and that the primary configuration is the right one.
Which configuration wins
Two sign-in experiences, and they behave differently when something breaks. Let them choose shows every active option on the sign-in page. Redirect to SSO sends everybody to the primary method, and a primary only has to be set when you redirect and have several configurations active. So the account most exposed to a bad certificate is the one that redirects, because there is nothing else on the page.
Expiry is the main cause of outages
A certificate or client secret expires and nobody can sign in, with no warning. It is entirely predictable and it still happens, because the date lives in a system nobody looks at.
Put every expiry in a shared calendar with a reminder a month ahead.
Staff and customers are separate
Check both. A change made for team members does not affect end users, and it is easy to test one and assume the other.
Watch what is still enabled
Zendesk passwords left on alongside single sign-on. It is usually a leftover from testing, and it means the account has a route in that your provider does not govern.
Test after any provider change
An upgrade, a migration, a policy change at the identity provider. Each can alter what is sent, and the symptom is sign-in failing for everybody on a Monday.
Keep a recovery plan
What happens if the provider is unavailable, or the configuration breaks. Who can still get in, and how. Decided in advance, because during an outage nobody can sign in to work it out.
Write it down
Which provider, who administers it, where the certificates come from, when they expire. This is the documentation your successor needs and the one nobody writes.
Comments
0 comments
Article is closed for comments.