OpenID Foundation Fast Federation (FastFed) Working Group update presented by Darin McAdams (Amazon) at the OIDF Workshop at Verizon Media on Monday, September 30, 2019 in Sunnyvale, CA.
14. ®
Lots of Pain
System Administrator
Budget 1-2 weeks to configure SSO to each application
Identity Providers
Each app is different. Custom integration & documentation.
Service Providers
Getting into Identity Provider catalogs. Not self-service.
What should I be doing!?
53. ®
Since Identiverse
• Closing out remaining issues, e.g.
• IGA Providers
• Provider Authentication
• Wordsmithing…
• Production timelines?
54. ®
Since Identiverse
• Closing out remaining issues, e.g.
• IGA Providers
• Provider Authentication
• Wordsmithing…
• Production timelines?
• Lesson from demo -> UX
Hinweis der Redaktion
Despite existence of standards like SAML or OIDC, many apps see low federation rates. Not unusual to see percentages in the single digits, or low double-digits.
Customers choose to create yet-another-login-and-password instead of SSO.
The reason: Configuring SSO is hard! Let’s look at a typical experience…
44 steps to configure SSO from GSuite->AWS. This isn’t unusual.
44 steps to configure SSO from GSuite->AWS. This isn’t unusual.
If you’ve never setup SSO before, you are immediately confused by strange words. “ACS URL? What is an ACS URL?”
You need to be a translator between applications
Besides SSO, how do you create user accounts in the application?
More concepts! JIT, SCIM, Lifecycle
After configuring… this is what happens. It doesn’t work. Maybe a typo, or accidentally copied the wrong value? No helpful logging. Calling tech support.
Finally, you get it working
Until 1 year later. Guess what happens after a year
SAML certificate expiration. Now the system is broken again.
Service Providers have no easy way to add themselves to app catalogs managed by the dentity Providers.
They ask the Identity experts: “You made all these standards. Please, tell us what to do!”
EVERYONE IS MISERABLE.
What’s happening – a human is copying and pasting between systems. They have 4 browser windows open.
The problem - humans are the most unreliable, error-prone data bus we could have chosen.
To solve it, how do we let computers talk to each other?
Behind the scenes, same standards. But, computers exchange the configuration programmatically.
This was the goal of the FastFed working group. Later, we’re going to show how it works. But first, let’s show you the new experience.
Does orchestrate their configuration. Sort of a control plane, and opinionated requirements for interoperability.
Aliright, In the N minutes remaining, here’s a whirlwind tour of what’s happening behind the scenes.
This is going to be FAST. Gives a taste. Toward the end, we’ll talk about where to learn more if it piques your interest.
The flow starts at the service. Someone has administrative privileges there, and wants to setup SSO.
First question – what is their Identity Provider?
FastFed has a couple ways to solve this.
The best user experience, and the one I’ll show here, uses their email address. In this case, the service has asked Alice for her email.
Based on the email, we can take the domain name
And, if the company has configured it, make a request to a well-known location to bootstrap. Uses an existing protocol names WebFinger, if you are familiar with it. (Although, we had to change WebFinger a little. )
We get back a location. This tells us where to find the FastFed configuration for Alice. The URL could be anything, just a place to go next.
Next the service can take this URL…
And make a call to retrieve the FastFed Metadata for Alice and her organization
What comes back is a whole lot of information. We won’t go through every detail, but a few highlights…
It includes capabilities
Here, we see this provider wants to use SAML and SCIM with a certain user schema. Another provider could prefer OpenID Connect, for example. This describes those preferences and capabilities.
We see some metadata. Things like unique IDs. Or, display names and images.
There’s also a public key. This will come in later. Just for now - remember – here’s where the service learns the public key for the Identity Provider.
Finally, a URL that points us to the next step in the handshake.
The service captures some of this information into a whitelist. The IDs, the public key. At this point, the service halts. It’s got a half-completed registration. Next step is to hand-off to the Identity Provider to finish the job.
There’s a couple ways to do this handoff, but in practice, an HTTP Redirect will be the most common. Alice is redirected to her Identity Provider using the endpoints discovered earlier.
I’m skipping over it here for time, but the redirect includes parameters for the Identity Provider to learn an equivalent set of metadata about the service. What SSO protocols does it support? What user attributes does it need?
I’m skipping over it here for time, but the redirect includes parameters for the Identity Provider to learn an equivalent set of metadata about the service. What SSO protocols does it support? What user attributes does it need?
The Identity Provider will authenticate Alice
It will confirm she really wants to configure SSO into the service.
Then, at some organizations, this will go into a security queue for approval. This is common, where even though Alice administers the service instance, the organization wants a little scrutiny before anyone in the company can launch 3rd party applications for org-wide use.
Finally, everything’s approved.
We’re ready to finish. Behind the scenes, the Identity Provider will make an HTTP request to complete the registration.
Finally, the services begin exchanging metadata to for those protocols.
This is the same information you were previously copying-and-pasting manually.
BUT, how does the service know the call is allowed? We can’t permit a random IdP to register.
To handle this, the Identity Provider signs the message using it’s public key.
The service can validate. Does this match a pending registration? Signed with the right key?
If everything looks OK, the service accepts it. Captures the metadata from the Identity Provider.
Then, it responds with it’s own Metadata
And we’re done.
What happened - apps exchanged the same metadata that human beings were copying-and-pasting before.
FastFed workflow creates the trust and communication channels.
They can periodically resync to get updates, like SAML certificate rotation.
All the specs are online.
This isn’t just Google+AWS. We want everyone to have this experience. Interested? Get involved.
All the specs are online.
This isn’t just Google+AWS. We want everyone to have this experience. Interested? Get involved.
All the specs are online.
This isn’t just Google+AWS. We want everyone to have this experience. Interested? Get involved.
All the specs are online.
This isn’t just Google+AWS. We want everyone to have this experience. Interested? Get involved.
All the specs are online.
This isn’t just Google+AWS. We want everyone to have this experience. Interested? Get involved.
All the specs are online.
This isn’t just Google+AWS. We want everyone to have this experience. Interested? Get involved.
All the specs are online.
This isn’t just Google+AWS. We want everyone to have this experience. Interested? Get involved.
All the specs are online.
This isn’t just Google+AWS. We want everyone to have this experience. Interested? Get involved.
