Internet2 Shibboleth Project
TERENA Networking Conference 2002, Limerick, Ireland
RL “Bob”Morgan, Washington
Steven Carmody, Brown
Scott Cantor, Ohio State
Marlena Erdos, IBM/Tivoli
Michael Gettes, Georgetown
Keith Hazelton, Wisconsin
David Wasley, UCOP
... and many more
Ken Klingenstein, Director
Internet2 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
• I“nterrealm 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)
WAYF
Where 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
SHIRE
Indexical 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
SHAR
Attribute 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
SHAR
Attribute 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 Attributes
and 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
“active member of the community”
Member@washington.edu
EPPN
identity
gettes@georgetown.edu
Entitlement
An agreed upon opaque string
Urn:mace:infovendor:contract1234
OrganizationalUnit Department
Economics Department
EnrolledCourse
Physics 201
Opaque course identifier
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, privacyenabled, 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
Legal trust
contractual
consequences of breaking trust
more political (ostracism, shame,
etc.)
consequences of breaking trust
more financial (liabilities, fines and
penalties, indemnification, etc.)
fluid (additions and deletions
frequent)
more static (legal process time
frames)
shorter term
structures tend to clubs and
federations
privacy issues more user-based
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