Shibboleth and InCommon:Making Secure Collaboration a Reality

http://shibboleth.internet2.edu/

Shibboleth and InCommon:Making Secure Collaboration a Reality

http://shibboleth.internet2.edu/

Scott Cantor (cantor.2@osu.edu)

Internet2/MACE and The Ohio State University

Scott Cantor (cantor.2@osu.edu)

Internet2/MACE and The Ohio State University

2

Internet2/MACE

A consortium of over 200 research institutions, with corporate and government partners, developing technologies in support of the next generation of networking and applications.

MACE is a steering committee of about 20 technologists for middleware activities within Internet2.

3

MACE Working Groups

•MACE-Dir (eduPerson, LDAP Recipe)

•Shibboleth

•Course-ID

•HEPKI (PKI-Light, S-MIME, HE Sector CA)

•VidMid (H.323, commObject)

•MedMid (meduPerson, HIPPA privacy laws)

•I2MM (Jabber, real-time communication/presence)

•End to End Diagnostics

4

Outline

What is Shibboleth?

Shibboleth Federations and Trust

Standards Convergence

Current Status

Library Considerations

5

What is Shibboleth?1999-2003

•An Internet2/MACE initiative to develop a standards-based architecture and policy framework supporting the sharing of secured web resources and services

•A software project delivering an open source implementation of the architecture and framework

•Based on the OASIS SAML standard (http://www.oasis-open.org/committees/security)

6

What is Shibboleth?2003-

•Open source attribute-based single sign-on software with an emphasis on user privacy, built on the SAML 1.1 specification

•A provider and consumer of innovations in federated identity standards

•An enabling technology for Internet2, international, and regional efforts at federation in education and research

7

Immediate (and less Immediate) Use Cases

• Traditional web single sign-on• Shared electronic learning resources• Research resources (grids)• Outsourced academic or administrative

services• Account linking across sites• Delegated trust in portal scenarios

(e.g. meta-searching)

8

Web Single Sign-On:General Approaches

•User supplies a single credential accepted by multiple applications across multiple physical servers

• e.g. X.509 Certificates, Smart Cards

•User communicates with a “login service” to convert a local credential into a new token that is passed to an application located elsewhere; repeat as necessary

• e.g. numerous proprietary WebSSO systems, SAML systems, Kerberos

Both approaches typically focus on identity; attribute design is more flexible and preserves privacy.

9

When Shibboleth?

•a secure or personalized service is used by large/discrete sets of users

•a service provider is unable/unwilling to do all the work

•authenticated but anonymous access is a requirement

•a standards-based approach to SSO is a plus

10

2000: Federated Administration2003: Federated Identity

• Users authenticate to their “home” or “origin” institution (identity provider)

• Identity becomes one of many attributes potentially sent to target sites (service providers)

• Authorization enforced by service provider, identity/attribute provider, or both

• Partitions responsibility, policy, technology, and trust

11

High Level ArchitectureKnock, Knock…

ResourceKnock, Knock

ResourceWho’s There?

AssertionConsumer

Service

abcde12345AuthnAuthority

Mary

AttributeRequester

AttributeAuthority

abcde12345 who?

AttributeRequester

AttributeAuthority

Mary, faculty, contract:001

ResourceLet me in!

12

Design Goals

• (relatively) seamless for users

• secure enough

• preserve privacy while permitting personalization

• manageable, scalable, flexible

• reduce the marginal cost and the barriers of implementing security

13

Shibboleth Project Deliverables

•An open source SAML implementation (http://www.opensaml.org/)

•Java-based “origin” implementation (authentication and attribute authorities)

•“Target” implementations for Apache, IIS, with additional deployment vehicles in development, including Java and non-web application scenarios

•Federated PKI-based trust fabric

14

Outline

What is Shibboleth?

Shibboleth Federations and Trust

Standards Convergence

Current Status

Library Considerations

15

Federations

Shibboleth “federations” are sets of sites that share common trust and operational metadata.

Federations generalize bilateral arrangements between sites so policy can be delegated and scaled.

Deployments can span federations and one-off agreements, and the PKI accomodates this.

16

Federation Services

•Vetting of identity providers

•Acting as naming authority for providers

•Aggregating, signing, publishing metadata

•Infrastructure for identity provider discovery

•Establishing ground rules for members

•Defining vocabularies of attributes and semantics

•Mediation and indemnification(in some deployments)

17

The Trust Continuum

Collaborative trust at one end…• Can I videoconference with you?• You can look at my calendar.• You can join this computer science workgroup and edit this program.• Students in Physics 201 at Brown can access this on-line sensor.• Members of the campus community can access this licensed

resource.

Legal trust at the other end…• Sign this document, and guarantee that what was signed was what I

saw.• Encrypt this file and save it.• Identify yourself to this high security area.

18

Dimensions of the Trust Continuum

Collaborative trust

•handshake

•consequences of breaking trust more political (ostracism, shame, etc.)

•fluid (additions and deletions frequent)

•shorter term

•structures tend to clubs and federations

•privacy issues more user-based

Legal trust

•contractual

•consequences of breaking trust more financial (liabilities, fines and penalties, indemnification, etc.)

•more static (legal process time frames)

•longer term (justify the overhead)

•tends to hierarchies and bridges

•privacy issues more about laws and rules

19

Federation Examples

•InQueue (Internet2 pilot federation)

•InCommon (Internet2/US, forthcoming)

•SWITCH (Swiss federation)• http://www.switch.ch/aai/deployment.html

•Statewide initiatives

•Intra-university deployments

•Other international collaborations

20

InCommonhttp://incommon.internet2.edu/

A federation for American higher education, initially focused on “.edu” origins.

Builds an open identity infrastructure across higher education for academic and research collaboration, outsourced and governmental services, etc.

Expected to serve as a trust anchor for a variety of Internet2 efforts.

Low barrier to entry, minimal legalities

21

Practices of Interest to Members

• Initial identification/password assignment process for accounts

•Authentication mechanisms for account use•Policy on the reuse of account names•Business logic for key attributes, as the need arises

•Usage and storage of attributes by targets

Current intent is descriptive, not prescriptive.

22

Outline

What is Shibboleth?

Shibboleth Federations and Trust

Standards Convergence

Current Status

Library Considerations

23

SAML 1.1http://www.oasis-open.org/committees/security

Shibboleth based on SAML 1.x:• SSO profiles initiated by identity provider• Query/response protocol for attributes, authorization

Lacking in interoperability…• Standardized “opaque” identifiers• Service provider initiated SSO• Metadata• Standardized attribute profiles

24

Liberty Alliance ID-FF 1.2http://www.projectliberty.org/

Builds on SAML 1.1 to specify a suite of protocols around “identity federation”, or account linking between providers.

Best features:• Metadata format and exchange protocol• Rich protocol for requesting authentication, permits control over strength, interactivity, re-authentication

• Detailed “context” data about identification and authentication during SSO

25

Road to Convergence

Work underway on SAML 2.0:• SAML 1.x deployment feedback• Shibboleth use cases• Liberty Alliance ID-FF specifications• XACML-based authorization enhancements• Standard due Q2 2004

Migration to new standard will increase commercial interoperability and functionality.

26

Outline

What is Shibboleth?

Shibboleth Federations and Trust

Standards Convergence

Current Status

Library Considerations

27

1.0 available since July 2003

1.1 made available in mid-August, added Windows/IIS target support, simpler configuration

Next code drop expected in March (~1.2)

Internet2 pilot testing with InQueue federation

Production InCommon federation being deliberately established

Current StatusPilotsCurrent Status

28

Getting Startedhttp://shibboleth.internet2.edu/

Binary and source distributions available

Origin components require user authentication and a raw attribute source (LDAP, JDBC, other JNDI, custom)

Institutions can join InQueue to test in a federated environment

Individuals can use custom configuration data for private testing

29

Future Work

• Security and metadata improvements (revocation, etc.)

• Apache 2 support• Java support• Enhanced virtual hosting of applications• Better auditing• Management interfaces• SAML 2.0 support• XACML-based resource manager

30

Outline

What is Shibboleth?

Shibboleth Federations and Trust

Standards Convergence

Current Status

Library Considerations

31

Campus Deployment

Two principal roles in a typical university library:

•Authenticating/authorizing off-campus access via proxies to non-partnering vendors

•Replacing location-based and other forms of weak or unwieldy authentication with partnering vendors

32

Changing Environment

•Increased demand for a more seamless transition between library and learning resources

•Increased acceptance of the need for stronger authentication

•Slow trend toward digitization of valuable materials

33

Some of the Outstanding Issues

•Identity Provider discovery and issues of multiple federations

•Recognition of Shibboleth authentication by service providers

•Direct linking to resources in a multi-authentication environment

•Institutional vs. library patron data