Transcript Identity-Enabling Web Applications: Today`s Landscape

Identity-Enabling Web Applications
Scott Cantor
[email protected]
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
• 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
Outline
Principals of Identity-Aware Design
Web Authentication Overview
Standards Marketplace Overview
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.
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.
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.
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
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 realtime. Alternatively use development
“frameworks” that include good abstractions.
•Bundle a “default” identity source, without
assuming it.
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.
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
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
Some Personal Biases
•Open
•Standards-Based
•Federated
•Attribute-Based
•Module
•Passive (I want to get behind Active, but…)
•Bearer (see above)
•N-Tier
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
Marketplace of Standards
•SAML
•WS-Federation
•Information Cards
•OpenID
•Kerberos
SAML Convergence
ID-FF 1.1
SAML 1.0
ID-FF 1.2
SAML 1.1
SAML 2.0
Shibboleth 1.x
2002
2003
2004
15
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
16
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
17
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
Information Cards
•Microsoft’s profiles of WS-Trust, WSSecurityPolicy:
• 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
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
OpenID
•LiveJournal author’s simple, borderline-secure
protocol for proving ownership of a URL (e.g. a
blog)
•Became a bandwagon for every non-XMLflavored 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
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