The Fast Federation Working Group aims to increase adoption of federated identity by making it easier to configure single sign-on between applications. It proposes new metadata files and user experience flows to simplify the registration process for administrators. The goals are to solve problems like attribute mapping and endpoint discovery by pushing complexity onto identity providers and advocating for administrators through standards that reduce integration work for service providers.

1. Fast Federation (FastFed) Working Group

2. Draft Available

3. Problem?
Low adoption of federation

4. Why?
It’s hard.

6. • FirstName
• first_name
• f_name
• GivenName
• given_name
Attribute Mappings

7. Error: Could not validate SAML response

8. It Works!
Until 1 year later…

9. Pain
System Administrator
Budget 1-2 weeks to configure SSO to each application
IdP Vendor
Each app is different. Custom integration & documentation.
SaaS Provider
Getting into IdP catalogs. Not self-service.
What should I be doing!?

10. Identity
Provider
Service
Provider
Copy/Paste Copy/Paste
Today’s Registration Experience
Admin

11. Identity
Provider
Service
Provider
Desired Registration Experience
Admin
Problems to be solved:
• How do the computers find each other?
• How do they understand each other?
o SAML vs OIDC? User Provisioning?
o User Attributes? Required vs Optional?
 Endpoint Discovery and Credential Exchange
 Metadata Files
 Common Vocabulary for Schemas

12. If we do this right…

13. This

14. …becomes the following experience

17. … sign-in to the application…
…answer a few questions…

20. What We’re NOT Doing
• Defining a new authentication protocol
• Forcing changes to existing SAML/OIDC endpoints
What We ARE Doing
• New Metadata Files
• New UX Flows
• Common Recipes & Recommended Practices

21. This market has the following properties:
• No existing shared schema
Each provider defines the attributes they want, and how
they are formatted on the wire.
• Minimal data requirements
Typically, only need a handful of attributes such as name,
email, and mobile phone number.
• No existing trust federations
Anyone can launch an IdP/SP. No certifications and no circle
of trusts.
Tenet 1) Solve the Commercial SaaS Market

22. Tenet 2) Don’t Preclude Other Markets

23. • FastFed’s priority is the user experience of the enterprise
administrator.
• We strive to make this experience fast, easy to understand,
and hard to get wrong.
Tenet 3) Advocate for the Admin

24. • Small(ish) number of IdP implementers
Tend to be identity experts, motivated to solve this problem.
• Thousands of SaaS implementers
Staffed by non-Identity-experts who are stretched thin.
“As Simple as Possible”
Tenet 4) Push Complexity onto IdPs

25. • “If you like your federation endpoint, you can keep your
federation endpoint.”
E.g. If the service expects a SAML assertion with user
attributes labeled as “full_name” and “email”, they can
continue to run in that manner.
• “Purely Additive”
Meaning FastFed requires the introduction of new APIs and
metadata, but doesn’t change existing federation
endpoints.
Tenet 5) Purely Additive for SPs

26. • Hosted services are typically multi-tenant
• Adds complexity
Tenant authorize release of private information (including
SSO configurations).
Tenet 6) Support Multi-Tenancy

27. • Implementers want guidance
• In the spirit of Tenet #3 (Advocate for the Admin),
recommend practices that reduce the burden on
administrators.
• As always: perfect shouldn’t be the enemy of the good.
Allow incremental adoption of best practices.
Tenet 7) Be Opinionated on Best Practices

28. Overview