internet shibboleth project
DESCRIPTION
TRANSCRIPT
Internet2 Shibboleth Project
TERENA Networking Conference 2002, Limerick, Ireland
RL “Bob” Morgan, WashingtonSteven Carmody, BrownScott Cantor, Ohio StateMarlena Erdos, IBM/TivoliMichael Gettes, GeorgetownKeith Hazelton, WisconsinDavid Wasley, UCOP... and many more
Ken Klingenstein, DirectorInternet2 Middleware Initiative
Outline
Background – I2 Middleware Work; Shibboleth Goals, Assumptions, Timelines, Related Works.
Shibboleth Basics – how it works; demos.
Technical Topics Shibboleth Technical Architecture User and Institutional Attribute Authorities, Resource Managers Applications and Shibboleth – EBSCO, NSDL, Meteor,
WebAssign
Non-technical topics Software licensing and maintenance Marketplace adoption – higher ed, GXA, Liberty, etc. Club Shib bylaws and operations
Wrap-up – what it buys, and what it costs…http://middleware.internet2.edu/shibboleth
Interrealm authorization:current approaches
Lots of ad hoc, non-scalable, difficult to maintain, and restrictive approaches:
Single ID and shared passwords are distributed, perhaps widely, presenting significant accountability risks.
Content providers limit access by IP address, leaving campus users on DSL/cable modems at home frustrated…
Campuses operate proxy services or VPNs that inconvenience users and present performance bottlenecks.
Sometimes campuses must load user identities into vendor databases, incurring additional cost, stale data, and potential privacy violations.
Users get new userids and passwords in each realm, incurring huhge overhead (and they often set all their passwords to be the same…)
Shibboleth Basics
“Interrealm Attribute-based Authorization for Web Services” An initiative to develop an architecture, policy framework, and
practical technologies to support inter-institutional sharing of resources
Based on a federated administration trust framework Provides 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 Developed with vendor participation - IBM/Tivoli Standards Alignment - OASIS/SAML Open solution (protocols and messages documented rfc-style, open
source implementation available)
Founding assumptions
Federated Administration – Focus on inter-institutional issues, with each enterprise responsible for authentication and assertion of attributes.
Create mechanisms for lightweight federation operations. Disturb as little of the existing campus infrastructure as possible but encourage good campus behaviors
Build a system that supports security but does not degrade privacy.
Leverage vendor and standards activity wherever possible (OASIS/SAML http://www.oasis-open.org/committees/security/ ), but recognize distinctive business needs.
Work with widespread campus technologies.
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.
Federated Administration
Leverage local authentication mechanisms (UID/PW to PKI)
Origin Site Must have joined the appropriate communities May have created “reasonable” default attribute release policies Responsible for initial identification and registration of users Responsible for managing attributes (eg Affiliation) Responsible for Authenticating users prior to resource access
Browser User Only needs to know the name of his/her origin domain May have created specific attribute release policies
Target Resource Manager Must have joined the appropriate communities Manage policies governing access to the resource
Rethinking Privacy
Passive privacy - The current approach.
A user passes identity to the target, and then worries about the target’s privacy policy. To comply with privacy, targets have significant regulatory requirements. The user has no control, and no responsibility. And no one is happy...
Active privacy - A new approach.
A user (through their security domain) can release the attributes to the target that are appropriate and necessary. If the attributes are personally identifiable. If the attributes are personally identifiable, the user decides whether to release them. The user has control, along with commensurate responsibility. All parties are happy
Attribute-based authorization
There is a spectrum of approaches available for attribute-based management of access to controlled resources,
At one end is the attribute-based approach, where attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach does not degrade privacy.
At the other end is the identity-based approach, where the identity of a prospective user is passed to the controlled resource and is used to determine (perhaps with requests for additional attributes about the user) whether to permit access. Since this leads with identity, this approach requires the user to trust the target to protect privacy.
Stage 1 - Addressing Four 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)
Intra-campus - crossing political boundaries 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 while respecting the content provider’s need for accountability.
Milestones
Project formation - Feb 2000 Stone Soup
Process - began late summer 2000 with Tivoli commitment (w/Marlena Erdos), project leadership in fall 2000 (w/Steven Carmody), bi-weekly calls to develop scenario, requirements and architecture.
Linkages to SAML established Dec 2000 (consistent architecture and distinguished territory)
Architecture and protocol completion - Aug 2001
Design - Oct 2001
Coding began - Nov 2001
Alpha release – April 2002 (!)
Roll-out plan
Three coding teams:
CMU - origin; IBM/Tivoli - target; OSU - libraries
Alpha code – available now
Alpha pilots – April - June
Beta code and beta pilots – June 1 - Sept 1
Release September 1 with Apache/modified BSD license
Internet2 to operate CVS, bug tracking, etc.
Applications and Shibboleth –
Currently working with: NSDL (National Science Digital Library) EBSCO (and other commercial information
providers) Meteor (Student Loan System) WebAssign (Web Based Testing, Physics and
Chemistry)
Shibboleth: How It Works
Technical Components
Demo
Technical Components
Origin Site Handle Server Attribute Authority
Target Site SHIRE SHAR WAYF Resource Manager
Existing assumed components:
for origins - Campus directory or attribute store; Web-ISO
for targets - web servers and resource managers
Go to Target, SHIRE
Destination site component responsible for context/session establishment
Session establishment will commonly rely on traditional techniques (i.e. cookies).
With no session in place, the SHIRE knows nothing about the user, so must either ask directly (SHIRE==WAYF) or redirect the user to a location that will ask on its behalf (SHIRE!=WAYF)
WAYFWhere are You From?
The WAYF is the transition point from destination to origin site HS when users contact a destination first.
The Club’s Registry provides the WAYF with a list of members, and their Handle Servers
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.
Handle Server
Works with AA and local Web ISO system (authentication) 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)
Triggers local campus authentication system
Generates a Handle
“Remembers” mapping from Handle to specific user
Sends Assertion with Handle to SHIRE
SHIREIndexical Reference Establisher
The SHIRE accepts and validates an assertion from a HS (Registry provides list of club members, their speakers, and associated cert’s)
Associates the incoming handle with the session it creates.
Passes control to the SHAR
SHARAttribute Requester
A SHAR makes attribute requests using the handle given it by the SHIRE.
Attribute Authority
Receives Attribute Query Messages (AQM) from SHAR; returns Attribute Response Message (ARM)
Finds ARPs matching target Determines which attributes and values to release
Provides UI for specification and management of Attribute Release Policies (ARPs)
Not a directory, but works with institutional directories and databases to aggregate and export attributes in a controlled fashion
SHARAttribute Requester
Upon receiving a response (AQR), the SHAR…
…authenticates the response ((Registry provides list of club members, their speakers, and associated cert’s) The attribute assertion contains the name of the origin
site (eg brown.edu)
…extracts the attributes
…checks attribute acceptance e.g. can an AA at MIT issue attributes for Harvard?
Resource Manager
Accepts Attributes from the SHAR
Compares supplied Attributes against Policy associated with requested resource
Grants/Denies access
Establishing a User Context
Getting Attributesand Determining Access
Attribute Authority -- Management of Attribute Release Policies
The AA provides ARP management tools/interfaces.
Different ARPs for different targets Each ARP Specifies which attributes and which values to release Institutional ARPs (default)
–administrative default policies and default attributes–Site can force include and exclude
User ARPs managed via “MyAA” web interface Release set determined by “combining” Default and User ARP for
the specified resource
Authorization Attributes
Typical Attributes in the Higher Ed Community
Affiliation
EPPN
Entitlement
OrganizationalUnit
EnrolledCourse
“active member of the community”identity
An agreed upon opaque string
Department
Opaque course identifier
Urn:mace:infovendor:contract1234
Economics Department
Physics 201
Non-technical Issues
Software licensing and maintenance
Marketplace adoption – higher ed, GXA, Liberty, etc.
Trust Models and Federations
Club Shib bylaws and operations
Software licensing and maintenance
Two products at this point will be licensed and maintained:
OpenSAML –a set of libraries to package,sign and unpack,verify SAML assertions, at opensaml.org
Shibboleth –an open source and development environment for Shibboleth, attribute authorities, resource managers, etc.
Both will operate under modified BSD licensing (see drafts at http://www.internet2.edu/members/html/intellectualproperty.html )
Internet2 and/or Club Shib membership may provide ongoing enhancements.
Marketplace issues
Federation oriented marketplace new and very active –
OASIS and SAML standards processes
Liberty Alliance
Microsoft .Net and GXA
Shibboleth
Shibboleth and PKI are complementary
The embedded base of work-arounds create inertia, but middleware development is active on many campuses right now
Build-on projects – digital rights management, K-12, etc.
Promotion and adoption process
SAML: Security Assertion Markup Language
Standards for XML-based authentication/authorization assertion formats,basic request-response protocol
Designed to support interop among web single-sign products (Netegrity,RSA, IBM, Entrust, many others)
OASIS technical committee formed in Jan 2001; difficult but successful standards process
Used Shibboleth as one of several scenarios to design
SAML 1.0 specs finished May 28 2002, awaiting OASIS ratification
Interop testing under way among many vendors
Spec punts on many issues, from communities to privacy
Shibboleth and SAML
SAML is specifying a format and a means to exchange authentication and authorization assertions
Shibboleth builds a general purpose public infrastructure around SAML by
developing user-navigation services, standards to manage the exchange of attributes, standard sets of attributes to be exchanged, and infrastructure and user tools to preserve and manage privacy. supporting groups using a common policy model; a scaleable
solution to common needs
SAML is creating a middleware equivalent of an IP address. Shibboleth adds services equivalent to DNS, routing, etc, to create a middleware equivalent of the Internet.
Liberty, Microsoft, etc
Liberty (www.projectliberty.org)
Sun, American Express, Citibank, United, Nokia …
federated identity and privacy management
technology uncertain; partnership is complex
Microsoft
GXA with derivative products (WSDL, etc.)
Passport and, once, Hailstorm
partial partnership with IBM
AOL
Magic Carpet
Shibboleth and PKI
Complementary technologies
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.).
Federations and Club Shib
Trust model continuum
Creating and managing federations
Club Shib
The Continuum of Trust
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
computing code Students in course Physics 201 @ Brown can access this
on-line sensor Members of the UWash 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 Identifiy yourself to this high security area
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 laws and rules
The Trust Continuum, Applications and their Users
Applications and their user community must decide where their requirements fit on the trust continuum.
Some apps can only be done at one end of the continuum, and that might suggest a particular technical approach.
Many applications fit somewhere in the middle and the user communities (those that trust each other) need to select a approach that works for them.
Shibboleth (and SAML) Federations
A group of organizations (universities, corporations, content providers, etc.) who agree to provide access to resources using the SAML/Shibboleth protocols. In doing so they agree to abide by common sets of rules.
The required rules and functions include:
A registry to process applications and administer operations
A set of best practices on associated technical issues, typically involving security and attribute management
A set of agreements or best practices on policies and business rules governing the exchange and use of attributes.
The set of attributes that are regularly exchanged (syntax and semantics).
A mechanism (WAYF) to identify a user’s security domains
Club Shib
A federation to support academic and research activities.
Members can be organizations that are : origins (IdSP’s) targets (student loan services, content providers) both (universities, museums, etc.)
Club functions : Central registry service and WAYF service Origin practices on attributes and authentication Target practices on the management of exchanged attributes Attribute sets (eduPerson and eduOrg) for use to exchange
attributes
Club Shib operation
Operated by Internet2, open to all interested parties; registration fees modest and likely absorbed internally for Internet2 members
Initial governance by NPPAC (I2 CIO policy/planning council) with the intent to propose a light-weight governance structure to club members
Registration services on line; distribution of registry updates nightly
Self-audits by members
Club Shib Application
Application must include appropriate technical details:
certs, org names, hs address, people contacts, etc.
Origin applicants must provide attribute management statement URL (see http://middleware.internet2.edu/shibboleth/samplepolicy/);
Must include eligibility, identification, authentication, and reuse information.
Target applicants must provide attribute handling statement.
The benefits and costs
Institutions can deploy a single interrealm authentication and authorization approach that can work for library, research and instructional needs.
Vendors can get their toes (big toe) into the web services water
A marketplace can be shaped that does not degrade privacy needlessly
A new widely used open-source web infrastructure can be created.
Institutions need to get their management processes aligned to support middleware
Middleware components need to be installed.
The Value of Shibboleth….
Institutions can deploy a single interrealm authentication and authorization approach that can work for library, research and instructional needs.
Enables greater granularity in access control policy
Part of the solution to the “higher degree of integration” problem
Establishes institutions as Identity Service Providers in upcoming competitive market
Promotes inter-institutional, attribute-based approach for institutional applications and services