Shibboleth & Privacy

Peter Brantley

Director of Technology, California Digital Library

University of California, Office of the President

September 2005

Outline

1. Access Mgmt2. Shibboleth3. Federations4. UCTrust5. SAML6. Privacy

Access Management

Essential Requirements:• Feasible and deployable• Authentication strength proportionate to asset value • Granularity of access and extensibility • Cross-protocol / environment flexibility • Provides for user-centered privacy • Ensures accountability • Ability to collect mgmt data

A White Paper on Authentication and Access Management Issues

Clifford Lynch, CNI, 1998

Distributed AM

Optimally, separate AM functions are assumed by the most appropriate or relevant parties -

1. Registration and Authentication:

Library, College, University

2. Authorization and Accounting:

The Resource Owner

Role vs Identity

Licenses providing access to restricted content, e.g., Elsevier’s ScienceDirect, are conceptually based on my role:

{member of} University of California

not my identity:

peter.brantley {at} ucop.edu

or my IP address:

128 . 218 . 14 . x

Improved AM

• Ideally want something non-identifying that a service can use to associate with me, and give me access.

• If a service provider knew where I was from, it could ask my identity-provider (i.e., my University) to authenticate me.

• Once authenticated, the service provider could determine whether or not I should have access to the resource based on information about my role.

• A service provider could therefore ask for only the attributes about my role that it most cares about.

• Might be {member of}, or {staff}, or {IT Director}• This approach enables finer role based distinctions.

This is Shibboleth!

Shibboleth Project• An umbrella of activities around federated authentication and access

management managed by Internet2 and its international partners, still ad hoc but moving toward formalism.

Shibboleth Specifications• The wire protocols and conformance requirements that define

"Shibboleth Compatible", currently derived in large part from SAML 1.1 with additions supporting user-centric privacy-preserving interaction.

Shibboleth System• Internet2-developed open source implementation of the specification

and value-added components

• Not the only extant or planned implementation (at least 2-3 other implementations known, and smaller projects based on the code base)

Shibboleth status

V1.3 released July/August 2005

In production use by commercial information providers (e.g., Elsevier SD, OCLC, JSTOR, EBSCO, Proquest, Blackwell)

Growing int’l uptake (countrywide deployments underway in HE within Switzerland, Finland, UK, Australia, others)

Deployment in US campuses accelerating rapidly

Vendors peripheral to HE beginning to support.

Production Federations (e.g., InCommon) now available

Meetings of “Leagues of Federations”

Supports through pluggable extension the US Federal E-Authentication Initiative (http://www.cio.gov/eauthentication/).

Shibboleth ArchR

eso

urc

e

WAYF

Identity Provider Service ProviderWeb Site

1

ACS

3 2

HS

5

6

7

User DB

Credentials

4

AR

Handle

Handle8

Handle9AA

Attributes 10

Res

ou

rce

Man

ag

er

Attributes

© SWITCH

High Altitude ArchServiceProvider

Knock, Knock

ServiceProvider

Who’s There?

Assertion Consumer

Service

v6597w54wd7AuthnAuthority

Mary

AttributeRequester

AttributeAuthority

v6597w54wd7 who?

AttributeRequester

AttributeAuthority

Mary, faculty, contract:001

ResourceLet me in!

Shibboleth Federations

Persistent enterprise-centric trust facilitators

Usually nationally-oriented

Federated operator handles enterprise I/A, management of centralized metadata operations

Members of federation communicate bilaterally through agreed upon sets of attributes

Members of federation determine what to trust and for what purposes on an application basis

Steering group of members sets policy and operational direction for federation

Hard work.

Meta-Federations

Federations of federations are under discussion.

Shibboleth InCommon and U.S. Federal federation (“FedFed”) are establishing a peering relationship.

Sun’s Project Liberty and Shibboleth will interoperate through advancement of technical standards.

Increased support for virtual organizations (VOs) uniting users within distinct Federations via adaptation of existing cross-org. collaboration tools, such as mlists and similar.

Expect eventual formation of Shibboleth-enabled social software based infrastructures, extending the concept of VOs, that support personal attribute requests (e.g., imagine a Shibbolized Flickr or Connotea).

Meta-Fed Discussions

Meeting held at Slaughter, England, Oct 2004

U.S., UK, Netherlands, Finland, Switzerland,

Australia, Spain, and others.

Issues include:• agreeing on policy framework, • comparing policies, • correlating app usage to trust level, • aligning privacy needs, • working with multinational service providers, • scaling the WAYF function.

Good meeting, not wholly conclusive.

Upper Slaughter images courtesy Ken Klingenstein.

Upper Slaughter

Leading trust to Slaughter

Leading trust from Slaughter

Feds in Europe

Different authentication technologies and infrastructures exist within Europe.

REFeds Effort: Research/Education Federations.

EC funded GN2 project: • pan-euro network access: eduroam• pan-euro aai solution: eduGAIN

eduGAIN supports meta-federation, via a peering model.

InCommon

InCommon is the U.S. HE federation.

Defines common identity attributes and common supporting technologies.

Emphasis is on a broad membership, relatively low-level requirements to start.

Any regionally accredited degree-granting school is potentially eligible.

InCommon is now a LLC, may turn into a non-profit.

Managed by a Steering Committee (CIO level people) with a Technical Advisory Group.

InCommon | ops

Members trust the operators to perform its activities well:

• The operator (Internet2) posts its procedures• Enterprises read the procedures and decide if they

want to become members• Contracts address operational and legal issues

Origins and targets establish trust bilaterally in out-of-band or no-band arrangements (using shared posting of practices):

• Origins must trust targets dispose of attributes properly

• Targets must trust origins to provide attributes accurately

• Risks and liabilities managed by enterprises

InCommon | progress

The relatively straightforward:• Syntax and semantics of exchanged attributes (Eduperson)• Set up and operation of federation• Selling the concept and value

The more challenging:• Having applications make intelligent use of federated identity• Handling indemnification• Finding scalable paths for LOA components

Shib communities

Flexible creation of federations within federations, of varying duration, are increasingly common in the U.S..

Short term:

Hurricane Katrina Evacuee Medical Database• RedCross federated authorization in field offices to

common evacuee database.

Long term:

The University of California (UC) has established its own federation within InCommon, UCTrust.

UCTrust requires greater assurance in IdM practices to ensure conformance with existing UC policies.

UC Background

The University of California is:

Ten campuses, three national labs, five medical centers

Most operational responsibilities on campuses• Payroll, Student Information, etc.• Each campus does its own identity management

A few services are central• Employee self-service and benefits central• Most licensed library materials• Multi-campus collaborations

UC Problem Statement

Separate identity management in place at each UC campus.

Moving toward a new business environment : • UC employee self-service and benefits• Access to any UC campus library system• Inter-campus access to course management systems• Collaboration within the Academic Senate• Administrative applications

How can services of one UC campus be accessed by users of another UC campus?

UCTrust | scope

UCTrust establishes UC-wide requirements to facilitate system-wide agreements.

Piloting with three campuses:• UC San Diego• UC Los Angeles• UC Irvine• UC Berkeley in conversation

Piloting with UCOP applications:• Your Benefits Online• California Digital Library

UCTrust | ops

UCTrust Task Force• Composed of campus Identity Providers, Service

Providers, UCTrust Administration, and UCOP• Manages operational policies and procedures• Oversight and conflict resolution provided by UC’s

committee of university CIOs.

UCTrust Federation Administration• Provides operational coordination, when needed• Maintains documentation repository• Not a major resource drain; technology and end-user

support is with the Identity and Service Providers.

UCTrust | reqs

UCTrust extends InCommon with additional requirements:

Campuses must provide authoritative and accurate attribute assertions.

Campuses must have practices that meet minimum standards:

• establishing electronic credentials and • maintaining individual identity information

Providers receiving individual identity attributes must ensure their protection and respect privacy constraints as defined by the campus

Shibboleth next steps

Developing a multi-Federation world.

Enhancing support for US DoE e-authentication initiative.

Support GridShib - Shibboleth in the global Grid.

Encourage continued commercial and vendor uptake.

Exploration of interoperability with MSFT’s ADFS.

Extending Shibboleth beyond the browser; some dataflows may use existing components in different ways.

Shibboleth 2.0, utilizing SAML 2.0, enhances functionality significantly. Design has been committed.

What’s SAML?

SAML

Security Assertion Markup Language (SAML)

Codified by OASIS with participation from MACE and others

Defines XML Schema for AuthN and attribute assertions, queries, responses, and use profiles such as Web SSO.

Defines bindings to protocols for transport

V2.0 expands SAML and includes definitions from Shibboleth and the Liberty Alliance

SAML in a Nutshell

An XML-based framework for exchanging security information

• XML-encoded security assertions• XML-encoded request/response protocol• Rules on using assertions with standard transport and

messaging frameworks

An OASIS standard (1.0, 1.1, and 2.0) • Vendors and users involved • OpenSAML implementation available• Codifies current system outputs vs. creating new technology

Shibboleth and SAML

Shibboleth is a profile of SAML.

Shibboleth Arch document describes how Shib uses SAML.

Shibboleth extends SAML.

Shibboleth includes a trust fabric implementation based on PKI.

Shibboleth includes a framework and metadata for identifying IdPs and SPs.

Shibboleth includes a mechanism (ARPs) to manage the release of attribute information to SPs.

Privacy & User Consent

Privacy• SAML 2.0 includes recommendations for privacy

preservation if and when desired• Central concept is that Identity Providers need not release

any personal information about users to service providers

User Consent • SSO protocol includes ability to query and record user-

consent• Identity providers and service providers can choose to

provide services based on whether user-consent was obtained and recorded.

Privacy in EU

EU Privacy directives are at least implicitly intended to encompass development and use of attribute release policies.

Growing awareness of privacy in the U.S. so greater harmonization is possible.

And (quoting Ken Klingenstein), “… then there’s the Swiss…”

Well-known name

Where privacy is not (much) at issue -

User entry at the IdP and SP(s) are keyed off name and/or attribute.

SAML 2.0 supports the use of:• E-Mail Address• X.509 Subject Name• Windows Domain Qualified Name• Kerberos Principal Name• Attribute (e.g., employee ID)

Anonymized access

Privacy is an issue -

Access at SP is given against roles or attributes.

User is never explicitly identified by a persistent identifier.• A transient identifier is used as the “name” of the user.• One or more roles describe the user:

– Employment grade :: Manager

– AccessRights :: Silver

– MemberOf :: Club

Privacy preserving as user identity at IdP remains unknown.

Mixed Bag

Some privacy is traded for PZN -

User identified by privacy preserving identifier.

User is identified by a persistent randomized string (aka “Handle”), private and unique to IdP and SP pairs.

Privacy preserving since no identity information about user is available at the SP.

Requires IdP => SP synchronization of user data stores.

Affiliations: An important subcase where a single persistent Handle is shared among a set of SPs, through release by the user.

Trade-offs

Anonymous use hinders PZN; persistent anonymized identifiers permit a range of PZN options.

PZN is usually less about the habits of any given individual, but more about data-mining online behavior habits of many specific users.

Aggregation across users into groups removes correlations that exist between discrete resource-interaction events.

It is usually the individual case - individual privacy - that is of greatest concern in the state’s protection of privacy rights.

Privacy & PZN

In the non-digital world, books are checked out, divorced from any digital click-stream.

In a more pervasively digital world, browsing behavior is recorded along with borrowing, purchasing.

Within the attribute-based realm, a service provider can choose to offer network-based pzn services if a persistent identifier is present. The user can determine the value of the trade-off, and whether they want to present attributes which reveal an anonymized identity.

Acknowledgements

Many thanks to -

the Shib crew:

Ken Klingenstein, Steven Carmody, RL “Bob” Morgan, Michael Gettes, Renee Frost, Scott Cantor, Walter Hoehn, and many many others,

and to Frank Siebenlist, Argonne National Laboratory, U.S.,

and John Paschoud, London School of Economics, U.K.,

and David Walker, University of California, U.S.,

for giving permission to liberally borrow from their past Shibboleth presentations.