Identity-Enabling Web Applications

Scott Cantorcantor.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• 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.

•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

•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

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

15

SAML Convergence

ID-FF 1.1

SAML 1.0 SAML 1.1

Shibboleth 1.x

ID-FF 1.2

SAML 2.0

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

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

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

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