1. Identity-Enabling Web Applications Scott Cantor cantor.2@osu.edu Internet2/The Ohio State University

2. Introductions Previous life as an applications developer at OSU Web Single Sign-On developer / deployer / operator Internet2 MACE Middleware Architecture Committee for Education http://middleware.internet2.edu/MACE/ Shibboleth Project Technical Architect Author of Service Provider software and C++ OpenSAML libraries http://shibboleth.internet2.edu/ Standards Development SAML Technical Committee, SAML 2.0 Technical Editor Liberty Alliance Contributor

3. Outline Principals of Identity-Aware Design Web Authentication Overview Standards Marketplace Overview

4. Terminology Authentication Establishing “who” is accessing something, generally in a repeatable way. Credentials Collection Dialog with the user/client in order to perform authentication. Attributes Extensible set of data about an authenticated subject/principal/user. Broadly speaking, there tend to be authorization attributes and profile/demographic attributes. Web SSO Authentication to one virtual host based on authentication to another.

5. Identity-Aware Design Applications should fulfill their function, not try to be the center of the universe. Managing identity is not their function. Authentication is ALWAYS* out of bounds on the web. Abstraction, abstraction, abstraction: Partitioning design of application-specific user data vs. generic user data. Factoring out identity components doesn’t mean applications can’t include them.

6. Identifier-Aware Design Some properties discussed in eduPerson: persistence privacy uniqueness reassignment human palatability Understand and communicate your requirements instead of overloading data to address different use cases. Use flexible data models and patterns: Allow for easy renaming, aliases, etc. This is NOT the place to save time.

7. the notion of “local” users/passwords modularizing credentials collection vs. authentication assuming look and feel of authentication directly implementing security or data protocols or using protocol-specific APIs custom session management sloppy use of identifiers Gotchas

8. Be lazy, do less work. Design applications to function in a secure web environment: trust the web server. Use portable, language-neutral, CGI-oriented interfaces to access identity information in real- time. Alternatively use development “frameworks” that include good abstractions. Bundle a “default” identity source, without assuming it. Some Suggestions

9. Overview of Web Authentication HTTP Authentication Practically speaking, requires application servers to know user secrets. Out of step with reality. SSL/TLS Smart cards still show promise, but privacy-flawed. Hard to deploy and ultimately doesn’t scale. GSS / Kerberos Seamless for those with Kerberos clients and willingness to manage server principals. Some growth potential, but probably too rigid for non-enterprise scenarios. Web SSO Adaptations of distributed authentication protocols to browsers, redirects, forms, and cookies. Most flexible, can be federated (with an inverse relationship between trust and scale). Support strong authentication but ultimately can be weak. Information Cards Changes the game, though not adding much actual security yet. Usual chicken/egg deployment problem for the moment.

10. Web SSO: Axes for Comparison Open / Closed Source Standards-Based / Proprietary Formalized / Undocumented Federated / Non-Federated Attribute-Based / Identity-Based Module / API Passive Client / Active Client Holder of Key / Bearer N-Tier / 1-Tier

11. Some (Incomplete) Examples Pubcookie, Cosign, WebAuth Open, proprietary, non-federated, identity-based, modules, passive, some N-tier CAS Open, proprietary, non-federated, identity-based, APIs w/ some modules, passive, N-tier Shibboleth Open, standards-based and proprietary, federated, attribute-based, modules, passive Commercial Products (HP, Sun, IBM, Oracle, CA, BMC, etc.) Closed, standards-based and proprietary, federated, attribute-based, APIs w/ some modules, passive w/ some active Microsoft ADFSv1 Closed, proprietary, federated, attribute-based, modules and APIs, passive Microsoft Information Card Ecosystem (Identity Metasystem) Open and closed, proprietary, federated, attribute-based, modules and APIs, active and passive OpenID Open, proprietary, federated, identity-based w/ some attributes, API, passive

12. Some Personal Biases Open Standards-Based Federated Attribute-Based Module Passive (I want to get behind Active, but…) Bearer (see above) N-Tier

13. State of the Web SSO Ecosystem Non-federated protocols still widely used Attribute-based SSO growing in popularity, offers a lot of flexibility Proprietary systems gravitating toward standards (de facto or de jure) Multi-protocol systems increasingly common N-tier problem lacking widely acceptable standards OAuth emerging, but like OpenID seems to be rejecting prior art HTTP limitations complicate matters

14. Marketplace of Standards SAML WS-Federation Information Cards OpenID Kerberos

15. 15 SAML Convergence ID-FF 1.1 SAML 1.0SAML 1.1 Shibboleth 1.x ID-FF 1.2 SAML 2.0 200220032004

16. 16 SAML 2.0: The Good Extensible technology-neutral security token framework Rich XML protocol for authentication, best-effort logout, simple provisioning Best of breed SSO protocol incorporating a lot of practice from proprietary systems Well-defined identifier types for privacy-oriented use cases Extensible metadata schema for exchange and provisioning of configuration and trust policy Modular specs enable formulation of new profiles that adapt SAML to new use cases or composition with other standards

17. 17 SAML 2.0: The Bad and/or Ugly XML XML Signature (not required, but often needed) XML Encryption (ditto) Basic SSO profile has too many options Drawbacks of redirection-based SSO

18. WS-Federation Good Adds metadata to original draft spec, probably composes with WS-SecurityPolicy New work on “claims dialects” seems like an attempt at a calculus of user attributes Bad/Ugly Passive SSO is circa SAML 1.1, same general downsides re: redirection Active SSO amounts to WS-Trust, so why add this? Another tactical metadata schema? Logout is (or was) badly under-specified

19. Information Cards Microsoft’s profiles of WS-Trust, WS- SecurityPolicy: Client loads RP’s policy and user selects IdP that can satisfy policy Client authenticates to IdP and asks for a token Client delivers token to desktop application (e.g. browser) for delivery to RP Overall experience, including SSO, largely dependent on client

20. Information Cards Good Overall flow is really nice Allows RP to be hidden from IdP In theory, helps with phishing Self-assertion of data included in many card selectors via built-in IdP Key derivation and proof of possession included Bad Specs are complex, though RP side is less so Microsoft-controlled specs Client portability hit or miss for now Browser-based token delivery is bearer only for now Card/IdP selection still a work in progress

21. OpenID LiveJournal author’s simple, borderline-secure protocol for proving ownership of a URL (e.g. a blog) Became a bandwagon for every non-XML- flavored federated SSO effort Flow resembles typical SSO + dymamic metadata (XRDS) acquisition Main distinguishing feature is zero trust, the assumption that any OP can talk to any RP with no prior key exchange

22. OpenID Good Very simple HTTP-based protocol Metadata exchange based on a flexible XML standard (XRI and XRDS) Now includes attribute exchange Allows users to choose their own identifiers Bad Encouraging applications to weld themselves to one protocol Oversells the simplicity of running a good IdP Privacy often made the user’s problem Drawbacks of redirection-based SSO Arguably offers a shaky security foundation Allows users to choose their own identifiers