48
Shibboleth Update RL “Bob” Morgan, Washington Steven Carmody, Brown Scott Cantor, Ohio State Marlena Erdos, IBM/Tivoli Michael Gettes, Georgetown Keith Hazelton, Wisconsin David Wasley, UCOP Ken Klingenstein, Director Internet2 Middleware Initiative

Shibboleth Update

  • Upload
    adair

  • View
    38

  • Download
    0

Embed Size (px)

DESCRIPTION

Shibboleth Update. RL “Bob” Morgan, Washington Steven Carmody, Brown Scott Cantor, Ohio State Marlena Erdos, IBM/Tivoli Michael Gettes, Georgetown Keith Hazelton, Wisconsin David Wasley, UCOP. Ken Klingenstein, Director Internet2 Middleware Initiative. Outline. Background - PowerPoint PPT Presentation

Citation preview

Page 1: Shibboleth Update

Shibboleth Update

RL “Bob” Morgan, WashingtonSteven Carmody, BrownScott Cantor, Ohio StateMarlena Erdos, IBM/TivoliMichael Gettes, GeorgetownKeith Hazelton, WisconsinDavid Wasley, UCOP

Ken Klingenstein, DirectorInternet2 Middleware Initiative

Page 2: Shibboleth Update

Outline

Background

What is Shibboleth?

Shibboleth Communities of Interest

Shibboleth and PKI

Shibboleth and SAML and WebSSO

Using Shibboleth

Shibboleth milestones

Roll-out plan and next steps

Getting ready

http://middleware.internet2.edu/shibboleth

Page 3: Shibboleth Update

MACE (Middleware Architecture Committee for Education)

Purpose - to provide advice, create experiments, foster standards, etc. on key technical issues for core middleware within higher education

Membership - Bob Morgan (UW) Chair, Scott Cantor (Ohio State), Steven Carmody (Brown), Michael Gettes (Georgetown), Keith Hazelton (Wisconsin), Paul Hill (MIT), Jim Jokl (Virginia), Mark Poepping (CMU), Bruce Vincent (Stanford), David Wasley (California), Von Welch (Grid)

European members - Brian Gilmore (Edinburgh), Ton Verschuren (Netherlands)

Creates working groups in major areas, including directories, interrealm access control, PKI, medical issues, etc.

Works via conference calls, emails, occasional serendipitous in-person meetings...

Page 4: Shibboleth Update

Shibboleth

A word which was made the criterion by which to distinguish the Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce sh, called the word sibboleth. See --Judges xii.

Hence, the criterion, test, or watchword of a party; a party cry or pet phrase.

- Webster's Revised Unabridged Dictionary (1913):

Page 5: Shibboleth Update

Shibboleth - What is it?

An initiative to develop an architecture, policy framework, and practical technologies to support inter-institutional sharing of resources

Will provide for the secure exchange of interoperable attributes which can be used in access control decisions

Controlled dissemination of attribute information, based on administrative defaults and user preferences

Shifts the model from passive privacy towards active privacy

Based on a federated administration trust framework

Vendor participation - IBM/Tivoli

Standards Alignment - OASIS/SAML

Open solution(protocols and messages documented rfc-style, open source implementation available)

Page 6: Shibboleth Update

Shibboleth - Why is it Needed?

Growing interest in collaboration and resource sharing among institutions

Provides ability to make access control decisions in a cross domain environment

Current approaches to problem (IP address filtering, identity matching, use of shared ids) have serious problems

Shibboleth will involve more than the architecture/implementation developed by the SAML participants (eg community-of-interest, privacy)

Page 7: Shibboleth Update

Founding assumptions

Leverage vendor and standards activity wherever possible (OASIS/SAML http://www.oasis-open.org/committees/security/ ), but recognize distinctive business needs.

Federated Administration

(Initially) disturb as little of the existing campus infrastructure as possible

Work with common, minimal authorization systems (eg htaccess)

Encourage good campus behaviors

Learn through doing• There is very little experience with systems that allow users to manage the

release of attribute information

Create a marketplace and reference implementations

Page 8: Shibboleth Update

Stage 1 - Addressing Three Scenario’s

Member of campus community accessing licensed resource• Anonymity required

Member of a course accessing remotely controlled resource• Anonymity required

Member of a workgroup accessing controlled resources• Controlled by unique identifiers (e.g. name)

Taken individually, each of these situations can be solved in a variety of straightforward ways.

Taken together, they present the challenge of meeting the user's reasonable expectations for protection of their personal privacy.

Page 9: Shibboleth Update

Architectural Model

Browser User’s Origin Site Responsible for Authentication

Origin Site Entity Willing to Create and Sign Assertions• Set of assertions about the user (Attribute/value pairs)

• User has control over disclosure

• Identity optional

• “active member of community”, “Associated with Course XYZ”

Target responsible for Authorization• Rules engine

• Matches contents of assertions against ruleset associated with target object

Cross Domain Trust• Implemented in communities

• Previously created between origin and target

• Perhaps there is a contract (information providers..)

Page 10: Shibboleth Update

Authorization Attributes

Affiliation

EPPN

Entitlement

OrganizationalUnit

EnrolledCourse

“active member of the community”

[email protected]

Urn:mace:infovendor:contract1234

Economics Department

Physics 201

Typical Assertions in the Higher Ed Community

Page 11: Shibboleth Update

Implications of Shibboleth Design Choices

Support all 3 scenarios (not just the library problem)• -> need a mechanism to manage attribute release

Focus on Privacy Protection• Both sites and users need to manage attribute release

Assume Origin Site Authenticates User• Origin Site needs enterprise level authentication mechanism

• Should have Web Single Signon system

Target Site Authorizes User• Need Trust Framework

• Need agreement on syntax and semantics of attributes (eduPerson, custom agreements between pairs of sites)

Page 12: Shibboleth Update

Federated Administration

Origin Site• Must have joined the appropriate communities

• May have created “reasonable” default attribute release policies

• Responsible for Identifying and registering users

• Responsible for Authenticating users

Browser User• May have created specific attribute release policies

Target Resource Manager• Manage policies governing access to the resource

Page 13: Shibboleth Update

Simple point-to-point model

client

EnterpriseLDAP

directory

Attributeauthority

AuthenticationService target

Attributerequestor

Policvdecision

point

Policyenforcement

pointPolicy

enforcementpoint

Policyenforcement

points

Video directory

Service discoveryservice

Protocols

Griddirectory Video

directory

EnterpriseLDAP

directory

Page 14: Shibboleth Update

Target Web

Server

Origin Site Target Site

Browser

Authentication Phase

First Access - Unauthenticated

Authorization Phase

Pass content if user is allowed

Shibboleth ArchitectureConcepts - High Level

Page 15: Shibboleth Update

Second Access - Authenticated

Target Web

Server

Origin Site Target Site

Browser

First Access - Unauthenticated

Web Login Server

Redirect User to Local Web Login

Ask to Obtain Entitlements

Pass entitlements for authz decision

Pass content if user is allowedAuthentication

AttributeServer

Entitlements

Auth OK

Req Ent

Ent Prompt

Authentication Phase

Authorization Phase

Success!

Shibboleth ArchitectureConcepts (detail)

Page 16: Shibboleth Update

Shibboleth Flows Draft

Page 17: Shibboleth Update

Detailed Component Descriptions

Attribute Authority

Handle Server

SHIRE

SHAR

WAYF

Page 18: Shibboleth Update

Establishing a User Context

Page 19: Shibboleth Update

Getting Attributesand Determining Access

Page 20: Shibboleth Update

SHIREIndexical Reference Establisher

Destination site component responsible for context/session establishment

When there is no active session, redirects browser user to the WAYF

Page 21: Shibboleth Update

WAYFWhere are You From?

The WAYF is the transition point from destination to origin site HS when users contact a destination first.

Users can respond to the WAYF by indicating in “colloquial” fashion which institution can authenticate them.

The WAYF will determine the URL of the appropriate HS based on the user’s input.

A variety of nasty semantic attacks lurk!

Page 22: Shibboleth Update

Handle Server

Works with AA and local Web ISO system to associate a query handle with an authenticated browser user and generate a signed assertion

Performs its work in response to an Attribute Query Handle Request (currently an unauthenticated HTTP GET)

AQHR contains• SHIRE URL for acceptance of response via HTTP POST• URL of desired resource/service at destination

Page 23: Shibboleth Update

SHIREIndexical Reference Establisher

Destination site component responsible for context/session establishment

Session establishment will commonly rely on traditional techniques (i.e. cookies).

The SHIRE accepts an assertion from a HS and associates the incoming handle with the session it creates.

Page 24: Shibboleth Update

SHARAttribute Requester

A SHAR makes attribute requests using the handle given it by the SHIRE.

Upon receiving a response (AQR), the SHAR…

…authenticates the response

…extracts the attributes

…checks attribute acceptance• e.g. can an AA at MIT issue attributes for Harvard?

Page 25: Shibboleth Update

Attribute Authority

Responds to Attribute Query Messages (AQM) from SHAR

Allows for specification and management of ARPs

Not a directory, but works with institutional directories and databases to aggregate and export attributes in a controlled fashion

Page 26: Shibboleth Update

IBM Interest

Provides “Federated” administrative model (as apposed to centralized or delegated)

• Leaves administration of user and authenticating user to requester’s site

• Leverages existing authentication/directory infrastructure

Privacy of requester preserved

Leverages SAML standard and will be one of its first “proof points”

Applies to B2B environments beyond current scope and definition

Page 27: Shibboleth Update

IBM and Tivoli’s commitment

IBM/Tivoli has been contributing to the architecture and design for over a year

IBM/Tivoli is committed to contributing to an open source implementation

• Prototype underway

IBM/Tivoli is committed to continuing to drive ubiquitous Security standards

• Shibb is based on existing standards where they exist

• SAML, etc...

Page 28: Shibboleth Update

Shibboleth (and SAML) Communities of Interest (COI)

(Ken Klingenstein)

Page 29: Shibboleth Update

CampusSystems

D. Wasley’s PKI Puzzle

Fed Bridge Educause HE Bridge

CREN Root CA

CampusSystems

CampusPKI

Directory

PKI provides:• Strong Authentication• Flexible Authorization• Secure Digital Signature• Powerful Data Security

CampusPKI

Directory

ServerCerts

VendorResources

CampusResources

Shib

EDUPKI

Hierarchy

COMPKI

Hierarchy

Page 30: Shibboleth Update

Shibboleth and PKI

Complimentary infrastructures wrt technology and policy

Technically,• Shibboleth leverages existing campus authentication processes (and can

use end-entity certificates for this process)• Shibboleth uses PKI to implement a multi-domain trust model• Shibboleth’s primary use is for authorization and privacy• PKI’s primary use is establishing identity across domains• PKI can use Shibboleth to achieve privacy and authorization

Policy, • Shibboleth establishes a collaborative trust model (flexible, quick, privacy-

enabled, etc.)• PKI establishes a legal trust model (binding, hierarchical, formal, etc.)

Page 31: Shibboleth Update

Shibboleth and SAML and WebISO

(R.L. “Bob” Morgan)

Page 32: Shibboleth Update

What Will it be Like to Use Shibboleth?

Sample Browser Screens are available at:• http://middleware.internet2.edu/shibboleth/mockups/index.html

Actual user interface being designed by five higher ed Schools of Information

Page 33: Shibboleth Update

Use - Go Directly To Target

Page 34: Shibboleth Update

Use - Specify Origin Site

Page 35: Shibboleth Update

Use - Local Authentication

Page 36: Shibboleth Update

Use - Target Page Displayed!

Page 37: Shibboleth Update

Use - Local Navigation Site

Page 38: Shibboleth Update

Use - “in the background”

Page 39: Shibboleth Update

Use - Target Page Displayed!

Page 40: Shibboleth Update

Milestones

Project formation - February 2000 Stone Soup

Process - began late summer 2000 with Tivoli commitment (Marlena Erdos), project leadership fall (Steven Carmody), bi-weekly calls and scenario, requirements and architecture development

Linkages to SAML established December 2000 (consistent architecture and distinguished territory)

Architecture and protocol completion - Aug, 2001

Design - Oct 2001

Coding begins - Nov 2001

Page 41: Shibboleth Update

Roll-out plan

Basic coding stage through February 2002

Alpha pilots Feb and March 2002

Code rewrites March April

Beta pilots - April May

General release - June, 2002

Release issues:

open-source license approach

distribution - Apache and other components

CVS, Bugtraq, and source/enhancement management

Page 42: Shibboleth Update

Coding stage

Three coding teams:

CMU - origin IBM/Tivoli - target OSU - libraries

Approach is to integrate hard-wired components and then progressively replace hard-wiring with code

Dec, Jan, Feb - finish coding, testing

End of february - packaging

End of Feb - March - deploy code to early pilot sites

Page 43: Shibboleth Update

Profile of Pilot Sites

Member of campus community accessing licensed resource• University hosting licensed DBs accessed from other universities

• Talking to several commercial vendors (they need “their customers” asking for this functionality…)

Member of a course accessing remotely controlled resource• Web based testing

• Clearinghouse for curriculum packages

• Web based tools used in courses

Member of a workgroup accessing controlled resources• Multi-institution project teams

Page 44: Shibboleth Update

Some of the pilots

Webassign

Penn State

Univ of Delaware - Problem Based Learning Clearinghouse

EDINA (UK)

London School of Economics

Page 45: Shibboleth Update

Getting Ready

As a Target• think through web services architecture

• examine contracts with origins for attribute requirements, business rules and marketing options

As an Origin• implement enterprise authentication infrastructure

• implement eduPerson in enterprise directory

• work with vendors to educate and take advantage

• ??

Page 46: Shibboleth Update

Identity Services on One Slide

Campus authentication Enterprise directory

Web services and

servers

WebISO

Learning Management

Systems PersonalPortals

Objectclassstandards

(e.g.eduperson,gridperson)

ContentPortals

Shibbolethexchange of

attributes

FuturePKI

DODHEet al

Future PKI

Interrealm

Security Domain

Gridset al

Page 47: Shibboleth Update

Middleware Inputs & Outputs

GridsGridsJA-SIG &JA-SIG &

uPortaluPortalOKIOKI

Inter-realmInter-realmcalendaringcalendaring

Shibboleth, eduPerson, Affiliated Directories, etc.Shibboleth, eduPerson, Affiliated Directories, etc.

EnterpriseEnterpriseDirectoryDirectory

EnterpriseEnterpriseAuthenticationAuthentication

LegacyLegacySystemsSystems

CampusCampusweb SSOweb SSO

futuresfutures

EnterpriseEnterpriseauthZauthZ

LicensedLicensedResourcesResources

EmbeddedEmbeddedApp SecurityApp Security

Shibboleth, eduPerson, and everything else

Page 48: Shibboleth Update