Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

OpenID Foundation FastFed Working Group Update - 2017-10-16

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 28 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie OpenID Foundation FastFed Working Group Update - 2017-10-16 (20)

Anzeige

Aktuellste (20)

Anzeige

OpenID Foundation FastFed Working Group Update - 2017-10-16

  1. 1. Fast Federation (FastFed) Working Group
  2. 2. Draft Available
  3. 3. Problem? Low adoption of federation
  4. 4. Why? It’s hard.
  5. 5. • FirstName • first_name • f_name • GivenName • given_name Attribute Mappings
  6. 6. Error: Could not validate SAML response
  7. 7. It Works! Until 1 year later…
  8. 8. 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!?
  9. 9. Identity Provider Service Provider Copy/Paste Copy/Paste Today’s Registration Experience Admin
  10. 10. 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
  11. 11. If we do this right…
  12. 12. This
  13. 13. …becomes the following experience
  14. 14. … sign-in to the application… …answer a few questions…
  15. 15. 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
  16. 16. 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
  17. 17. Tenet 2) Don’t Preclude Other Markets
  18. 18. • 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
  19. 19. • 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
  20. 20. • “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
  21. 21. • Hosted services are typically multi-tenant • Adds complexity Tenant authorize release of private information (including SSO configurations). Tenet 6) Support Multi-Tenancy
  22. 22. • 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
  23. 23. Overview

×