Identity-Enabling Web Applications

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. Gotchas • 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

8. Some Suggestions • 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.

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. SAML Convergence ID-FF 1.1 ID-FF 1.2 SAML 1.0 SAML 1.1 SAML 2.0 Shibboleth 1.x 2002 2003 2004

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. 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