1 / 22

Identity-Enabling Web Applications

Identity-Enabling Web Applications. Scott Cantor cantor.2@osu.edu Internet2/The Ohio State University. Introductions. Previous life as an applications developer at OSU Web Single Sign-On developer / deployer / operator Internet2 MACE Middleware Architecture Committee for Education

Download Presentation

Identity-Enabling Web Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related