Single sign-on
SSO and Federation
SAML 2.0, OAuth 2.0 and OpenID Connect integrations designed, debugged and rolled out, with MFA policy, across the applications your people already use.
How it works
Federation through an enterprise identity provider
The problem
- Each new application arrives with its own integration guide and its own reading of the standard.
- A federation failure surfaces as a vague login error, and diagnosing it means reading XML or token claims by hand.
- Partners and acquired companies need access without being given accounts.
What we do
Single sign-on is where most identity programs start, because everyone sees it and the standards are mature. The difficulty is in the details each application gets slightly wrong.
We publish what we know about the protocols in the explainers below, and we built a public test identity provider and service provider, at saml-box.com, for checking an integration before it reaches production.
What you get
- Integration patterns for SAML, OAuth 2.0 and OpenID Connect that every application team follows.
- Applications onboarded and tested against a reference identity provider before they reach production.
- Federation with partners and subsidiaries, with the trust and attribute mapping written down.
- MFA policy applied once, at the identity provider.
How it is usually shaped
Often the first engagement and the fastest to show a result.
Platforms
- Ping Identity
- ForgeRock
- Okta
- Keycloak
- Spring Security SAML
Talk to us
Tell us where your SSO and Federation work stands, and we will reply within one business day.
Talk to us about SSO and Federation