Transcript Federated Identity Management: The Shibboleth Approach Renee Woodten Frost Internet2 Middleware and Security University of Michigan 22 March 2005

Federated Identity Management:
The Shibboleth Approach
Renee Woodten Frost
Internet2 Middleware and Security
University of Michigan
22 March 2005
• Copyright Renee Woodten Frost, 2005. This work is
the intellectual property of the author. Permission is
granted for this material to be shared for noncommercial, educational purposes, provided that this
copyright statement appears on the reproduced
materials and notice is given that the copying is by
permission of the author. To disseminate otherwise or
to republish requires written permission from the
author.
22 Mar 2005
Midwest Regional
2
Topics
• What is Identity Management (IdM)? Federated
IdM?
• What is Shibboleth?
• Why Shibboleth?
• Federations
– InQueue
– InCommon
• For more information
22 Mar 2005
Midwest Regional
3
Identity Management (IdM)
Set of standards, policies, procedures, and
technologies that provide electronic credentials to
individuals and maintain authoritative information
about the holders of those credentials . . and assist
in determining and granting access to resources
and services . .
• Identity Management in this sense is
sometimes called “Identity and Access
Management”
• What problems does Identity Management
solve?
22 Mar 2005
Midwest Regional
4
What We’re All Trying to Accomplish
•
•
•
•
Simplify end user access to multitude of online services
Facilitate operation of those services by IT organizations
Increase security
Enable online service for our constituents earlier in their
affiliation with us, wherever they are, and ongoing
• Participate in new, inter-organizational, collaborative
architectures and environments
22 Mar 2005
Midwest Regional
5
Federated Identity Management
Relying on the Identity Management infrastructure
of one or more institutions or units . .
to authenticate and pass authorization-related
information to service providers or resourcehosting institutions or enterprises . .
via institution-provider agreements . .
facilitated by common membership in a federation
(like InCommon)
22 Mar 2005
Midwest Regional
6
Federated Administration
VO
VO
O
Apps CM
O
RP
CM Apps
RP
Campus 1
Campus 2
RP
22 Mar 2005
RP
RP
Midwest Regional
Federation
7
Other
feds
Federated Administration for HE
Given the strong collaborations within the academic
community, there is an urgent need to create inter-realm
tools, so . .
• Build consistent campus and enterprise middleware
infrastructure deployments, with outward facing
objectclasses, service points, etc. and then
• Federate those enterprise deployments, using the
outward facing campus infrastructure, with inter-realm
attribute transports, trust services, etc. and then
• Leverage that federation to enable a variety of applications
from network authentication to instant messaging, from video
to web services, and then, going forward
• Create tools and templates that support the management
and collaboration of virtual organizations by building on the
federated campus infrastructures.
22 Mar 2005
Midwest Regional
8
What is Middleware?
• Specialized networked services that are shared by
applications and users
• A set of core software components that permit
scaling of applications and networks
• Tools that take the complexity out of application
integration
• A second layer of the IT infrastructure, sitting above
the network
• A land where technology meets policy
• The intersection of what networks designers and
applications developers each do not want to do
22 Mar 2005
Midwest Regional
9
A Map of Campus Middleware Land
22 Mar 2005
Midwest Regional
10
Core Middleware Scope
• Identity and Identifiers – namespaces, identifier crosswalks,
real world levels of assurance, etc.
• Authentication – campus technologies and policies, interrealm
interoperability via PKI, Kerberos, etc.
• Directories – enterprise directory services architectures and
tools, standard objectclasses, interrealm and registry services
• Authorization – permissions and access controls, delegation,
privacy management, etc.
• Integration Activities – open management tools, use of virtual,
federated and hierarchical organizations, enabling common
applications with core middleware
22 Mar 2005
Midwest Regional
11
Internet2 Middleware and
the NSF Middleware Initiative (NMI)
• Internet2 Middleware a major theme for last five years, drawing
support from 206 university members, 60+ corporate members,
international partners and government grants and interactions
• Internet2 has integrator role within NMI, the key NSF Program
to develop and deploy common middleware infrastructures
• NMI has two major themes
– Scientific computing and data environments (ala Grids)
– Common campus and inter-institutional middleware
infrastructure (ala Internet2/EDUCAUSE/SURA work)
• Issues periodic NMI releases of software, services,
architectures, objectclasses and best practices – R6 most
current release in Dec 2005
22 Mar 2005
Midwest Regional
12
What is Shibboleth? (Biblical)
• 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)
22 Mar 2005
Midwest Regional
13
What is Shibboleth?
• An initiative to develop an architecture and policy
framework supporting the sharing – between domains - of secured web resources and services
• A framework built on a “Federated” model
• A project delivering an open source implementation of
the architecture and framework
• Deliverables:
–Software for identity providers = campuses (origins)
–Software for resource providers (targets)
–Operational Federations (scalable trust)
22 Mar 2005
Midwest Regional
14
Shibboleth Goals
• Use federated administration as the lever; have the
enterprise broker most services (authentication,
authorization, resource discovery, etc.) in inter-realm
interactions
• Provide security while not degrading privacy
–Using Attribute-based Access Control
• Foster inter-realm trust fabrics: federations and virtual
organizations
• Leverage campus expertise and build rough consensus
• Influence the marketplace; develop where necessary
• Support heterogeneity and open standards
22 Mar 2005
Midwest Regional
15
Attribute-based Authorization
• Identity-based approach
–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.
–This approach requires the user to trust the
resource provider to protect privacy.
• Attribute-based approach
–Attributes are exchanged about a prospective user
until the controlled resource has sufficient
information to make a decision.
–This approach does not degrade privacy.
22 Mar 2005
Midwest Regional
16
Typical Attributes in the
Higher Ed Community
Affiliation
“active member of
community”
[email protected]
EPPN
Identity
(eduPersonPrincipalName)
[email protected]
Entitlement
An agreed upon
opaque URI
urn:mace:vendor:contract1234
OrgUnit
Department
Economics Department
EnrolledCourse
Opaque course
identifier
urn:mace:osu.edu:Physics201
22 Mar 2005
Midwest Regional
17
Addressing Four Scenarios
• 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-university information access
–Controlled by a variety of identifiers
•Taken individually, each situation can be solved in a variety of
straightforward ways.
• Taken together, they present the challenge of meeting users’
reasonable expectations for protection of personal privacy.
22 Mar 2005
Midwest Regional
18
So… What is Shibboleth?
• A Web Single-Signon System (SSO)?
• An Access Control Mechanism for Attributes?
• A Standard Interface and Vocabulary for
Attributes?
• A Standard for Adding Authentication and
Authorization to Applications?
22 Mar 2005
Midwest Regional
19
Shibboleth Architecture
(still photo, no moving parts)
22 Mar 2005
Midwest Regional
20
Development Milestones
• Project formation - Feb 2000; process began late
summer 2000 with bi-weekly calls to develop
scenarios, requirements and architecture
• Linkages to SAML established - Dec 2000
• Architecture and protocol completion - Aug 2001
• Design - Oct 2001
• Coding began - Nov 2001
• Alpha-1 release - April 24, 2002
• OpenSAML release - July 15, 2002
• v1.0 April 2003; v1.1 July 2003; v1.2 May 2004
• v1.3 Q1 2005 e-auth certified
• v1.4 Q1 2006 WS-Fed compliant
• v2.0 likely end of the major evolution
22 Mar 2005
Midwest Regional
21
Current Status: Shibboleth v. 1.2.1
• Open-source, standards-based, privacy-preserving federating
software
• Accelerating deployment globally: InCommon, NSDL, SWITCH,
Finland, Netherlands, United Kingdom (three), Australia,
InQueue, League of Federations
• Commercial information providers in production: Elsevier
Science Direct, OCLC, etc.
• Resource Provider component works with Apache(1.3 and 2.0)
and IIS
• Identity Provider component is Java-based for a variety of
platforms
• Working on Underlying Attribute Authority GUI and resource
protection
• Growing international development interest providing resource
manager tools, email list software, etc.
22 Mar 2005
Midwest Regional
22
Shibboleth -- Next Steps
• Full Implementation of Trust Fabric
–Supporting multi-federation origins and targets
• Support for Dynamic Content (Library-style Implementation
in addition to web server plugins)
• Sysadmin GUIs for managing origin and target policy
• Integration with Grids, Virtual Organizations
• Integration with SAML V2.0, Liberty Alliance, WS-Fed
• NSF grant to Shibboleth-enable open source collaboration
tools
• Integration with P2P - LionShare
22 Mar 2005
Midwest Regional
23
Why Shibboleth?
Improved Access Control
• Use of attributes allows fine-grained access control
–Med School Faculty get access to additional resources
–Specific group of students have access to restricted
resources
• Simplifies management of access to extended functionality
–Librarians, based on their role, are given a higher-thanusual level of access to an online database to which a
college might subscribe
–Librarians and publishers can enforce complicated
license agreements that may restrict access to special
collections to small groups of faculty researchers
22 Mar 2005
Midwest Regional
24
Why Shibboleth?
Federated Administration
• Flexibly partitions responsibility, policy, technology, and trust
• Leverages existing middleware infrastructure at origin authentication, directory
–Users registered only at their “home” or “origin” institution
–Resource Provider does NOT need to create new userids
• Authorization information sent instead of authentication
information
–When possible, use groups instead of people on ACLs
–Identity information still available for auditing and for
applications that require it
22 Mar 2005
Midwest Regional
25
Why Shibboleth?
Privacy
• Higher Ed has privacy obligations
– In US, “FERPA” requires permission for release
of most personal identification information;
encourages least privilege in information access
– HIPAA requires privacy in medical records
handling
• General interest and concern for privacy is growing
• Shibboleth has active (vs. passive) privacy
provisions “built in”
22 Mar 2005
Midwest Regional
26
Benefits to Campuses
• Much easier Inter-Domain Integration
–With other campuses
–With off-campus resource provider systems
• Integration with other campus systems, intra-domain
–Learning Management Systems
–Med School……
• Ability to manage access control at a fine-grained level
• Allows personalization, without releasing identity
• Implement Shibboleth once…
–And then just manage attributes that are released to
new resource providers
22 Mar 2005
Midwest Regional
27
Benefits to Resource Providers
• Unified authentication mechanism from the vendor perspective
– Much more scalable
– Much less integration work required to bring new customers online
• Ability to implement fine-grained access control (e.g. access by role),
allowing customer sites to effectively control access by attributes and
thus control usage costs, by not granting access unnecessarily
• Once Shibboleth integration completed on vendor’s systems
– Incremental cost of adding new customers is relatively minimal
– In contrast to the current situation -- requiring custom work for each
new customer
• Ability to offer personalization
• Enables attribute-based Service Level Model
• If universities have Shibboleth implemented already, easy
implementation for them
22 Mar 2005
Midwest Regional
28
What are Federations?
• Associations of enterprises that come together to
exchange information about their users and resources in
order to enable collaborations and transactions
• Enroll and authenticate and attribute locally, act federally.
• Uses federating software (e.g. Liberty Alliance, Shibboleth,
WS-*) common attributes (e.g. eduPerson), and a security
and privacy set of understandings
• Enterprises (and users) retain control over what attributes
are released to a resource; the resources retain control
(though they may delegate) over the authorization
decision.
• Several federations now in construction or deployment
22 Mar 2005
Midwest Regional
29
Business drivers for R&E (again)
Given the strong collaborations within the academic community,
there is an urgent need to create inter-realm tools, so
• Build consistent campus middleware infrastructure
deployments, with outward facing objectclasses, service
points, etc. and then
• Federate (multilateral) those enterprise deployments with
inter-realm attribute transports, trust services, etc. and then
• Leverage that federation to enable a variety of applications
from network authentication to instant messaging, from video
to web services, from p2p to virtual organizations, etc. while
we
• Be cautious about the limits of federations and look for
alternative fabrics where appropriate.
22 Mar 2005
Midwest Regional
30
Policy Basics for Federations
• Enterprises that participate need to establish a trusted
relationship with the operator of the federation; in small
or bilateral federations, often one of the participants
operates the federation
• Participants need to establish trust with each other on a
per use or per application basis, balancing risk with the
level of trust
• Participants need to agree on the syntax and semantics
of the information to be shared
• Privacy issues must be addressed at several layers
• All this needs to be done on scalable basis, as number of
participants grow and number of federations grow
22 Mar 2005
Midwest Regional
31
Unified Field Theory of Trust
• Bridged, global hierarchies of identification-oriented,
often government-based trust: laws, identity tokens, etc.
– Passports, drivers licenses
– Future is typically PKI oriented
• Federated enterprise-based trust: leverages one’s
security domain; often role-based
– Enterprise does authentication and attributes
– Federations of enterprises exchange assertions (identity & attributes)
• Peer-to-peer trust: ad hoc, small locus personal trust
– A large part of our non-networked lives
– New technology approaches to bring this into the electronic world.
– Distinguishing P2P apps architecture from P2P trust
• Virtual organizations cross-stitch across one of the above
22 Mar 2005
Midwest Regional
32
Federal Guidelines of Relevance
• NIST Guideline on Risk Assessment
Methodologies
• NIST Guideline on Authentication
Technologies and their strengths
• Federal e-Authentication
22 Mar 2005
Midwest Regional
33
•
•
•
•
Shibboleth-based Federations
InQueue
InCommon
Club Shib
Swiss Education and Research Network
(SWITCH)
• National Science Digital Library (NSDL)
-----------------------------------• State networks
• Medical networks
• Financial aid networks
• Life-long learning communities Midwest Regional
22 Mar 2005
34
The Research and Education
Federation Space
REF
Cluster
Other
potenti
al
US
R+E
feds
InQueue
(a starting
point)
Other
clusters
Other
national nets
SWITCH
InCommo
n
NSD
L
Indiana
The
Shib
Resear
ch Club
State of Penn
Fin Aid Assoc
22 Mar 2005
Slippery slope
- Med Centers, etc
Midwest Regional
35
InQueue
• The “holding pond”
• Is a persistent federation with “passing-through”
membership…
• Operational today. Can apply for membership via
http://shibboleth.internet2.edu/ InQueue Federation
guidelines; approximately 150 participants
• Requires eduPerson attributes
• Operated by Internet2; open to almost anyone using
Shibboleth in an R&E setting or not…
• Fees and service profile to be established shortly:
cost-recovery basis
22 Mar 2005
Midwest Regional
36
InQueue Origins 2.12.04
•Rutgers University
•University of Wisconsin
•New York University
•Georgia State University
•University of Washington
•University of California
•University at Buffalo
•Dartmouth College
•Michigan State University
•Georgetown
•Duke
•The Ohio State University
•UCLA
•Internet2
•Carnegie
Mellon University
22 Mar 2005
•National Research Council of Canada
•Columbia University
•University of Virginia
•University of California, San Diego
•Brown University
•University of Minnesota
•Penn State University
•Cal Poly Pomona
•London School of Economics
•University of North Carolina at Chapel Hill
•University of Colorado at Boulder
•UT Arlington
•UTHSC-Houston
•University of Michigan
•University of Rochester
Midwest Regional
•University of Southern
California
37
Federation
•
•
•
•
A permanent federation for the R&E US sector
Federation operations – Internet2
Federating software – Shibboleth 1.2 and above
Federation data schema - eduPerson200210 or later
and eduOrg200210 or later
• Federated approach to security & privacy with posted
policies
• Became fully operational mid-September, with several
early entrants shaping the policy & process issues.
• Precursor federation, InQueue, in operation for about a
year, feeds into InCommon
http://www.incommonfederation.org
22 Mar 2005
Midwest Regional
38
Principles
• Support the R&E community in inter-institutional
collaborations
• InCommon itself operates at a high level of security
and trustworthiness
• InCommon requires its participants to post their
relevant operational procedures on identity
management, privacy, etc
• InCommon will be constructive and help its
participants move to higher levels of assurance as
applications warrant
• InCommon will work closely with other national and
international federations
22 Mar 2005
Midwest Regional
39
Uses
• Institutional users acquiring content from popular
providers (Napster, etc.) and academic providers
(Elsevier, OCLC, JSTOR, EBSCO, Pro-Quest, etc.)
• Institutions working with outsourced service
providers, e.g. grading services, scheduling systems
(Blackboard, WebCT, WebAssign, etc.)
• Inter-institutional collaborations, including shared
courses and students, research computing sharing,
etc.
• (Shared network security monitoring, interactions
between students and federal applications, peering
with international activities, etc.)
22 Mar 2005
Midwest Regional
40
Trust in
- Initial
• Members trust the federated operations to perform its
activities well
– The operator (Internet2) posts its procedures, attempts to
execute them faithfully, and makes no warranties
– Enterprises read the procedures and decide if they want to
become members
• Origins and targets trust each other bilaterally in out-ofband or no-band arrangements
– Origins trust targets dispose of attributes properly
– Targets trust origins to provide attributes accurately
– Risks and liabilities managed by end enterprises, in
separate ways
22 Mar 2005
Midwest Regional
41
Trust - Ongoing
• Use trust  Build trust cycle
• Clearly need consensus levels of I/A
• Multiple levels of I/A for different needs
– Two factor for high-risk
– Distinctive requirements (campus in Bejing or
France, distance ed, mobility)
• Standardized data definitions unclear
• Audits unclear
• International issues
22 Mar 2005
Midwest Regional
42
Management
• Operational services by Internet2
– Member services (Application, etc)
– Backroom (Certificate Authority, WAYF service, etc.)
• Governance
– Steering Committee: Carrie Regenstein, Chair (Wisconsin), Jerry
Campbell (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas
System), Ken Klingenstein (Internet2), Mark Luker (EDUCAUSE),
Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teets (OCLC),
David Yakimischak (JSTOR)
– Two Steering Committee working groups
• Policy: Tracy Mitrano, Chair
• Communication, Membership, Pricing/Packaging: Susan Perry,
Chair
– Technical Advisory Group: Scott Cantor (OSU), Steven Carmody
(Brown), Bob Morgan (Washington), Renee Shuey (PSU)
• 22Initially
an LLC and likely to take 501(c)3 Midwest
status
Mar 2005
Regional
43
Documents (to date)
• Membership criteria
• Pricing/packaging cost recovery model
• Federation Operating Practices and Procedures
and Technical Operations Docs
• Participant Agreement
• Participant Operational Practice (POP)
22 Mar 2005
Midwest Regional
44
Participants
• Two types of participants:
– Higher ed institutions - .edu-ish requirements
– Resource providers – commercial partners
sponsored by higher ed institutions, e.g. content
providers, outsourced service providers, etc
• Participants can function in roles of identity
providers and/or resource providers
– Higher ed institutions are primarily identity
(credential) providers, with the potential for multiple
service providers on campus
– Resource (service) providers are primarily offering a
limited number of services, but canMidwest
serve
as
22 Mar 2005
Regional
credential providers for their employees as45 well
• Goals
Pricing
– Cost recovery
– Manage federation “stress points”
• Prices
– Application Fee: $700 (largely enterprise I/A, db)
– Yearly Fee
• Higher Ed participant: $1000 per identity management
system
• Sponsored participant: $1000
• All participants: 20 ResourceProviderIds included;
additional ResourceProviderIds available at $50 each per
year, available in bundles of 20
22 Mar 2005
Midwest Regional
46
Operations
• Operational services by Internet2
– Storefront (process maps, application process)
– Backroom (CA, WAYF service, etc.)
– Federation Operating Practices and Procedures
(FOPP)
• InCommon Process Technical Advisory
–
–
–
–
Scott Cantor, OSU
Jim Jokl, University of Virginia
RL Bob Morgan, University of Washington
Jeff Schiller, MIT
• Key Signing Party
– March 30, 2004 in Ann Arbor
– Videotaped and witnessed
22 Mar 2005
Midwest Regional
47
Operations Docs
• InCommon_Federation_Disaster_Recovery_Procedures_ver_0.1
– An outline of the procedures to be used if there is a disaster
with the InCommon Federation.
• Internet2_InCommon_Federation_Infrastructure_Technical_Refer
ence_ver_0.2
– Document describing the federation infrastructure.
• Internet2_InCommon_secure_physical_storage_ver_0.2
– List of the physical objects and logs that will be securely
stored.
• Internet2_InCommon_Technical_Operations_steps_ver_0.35
– This document lists the steps taken from the point of
submitting CSR, Metadata, and CRL to issuing a signed cert,
generation of signed metadata, and publishing the CRL.
• Internet2_InCommon_Technical_Operation_Hours_ver_0.12
– Documentation of the proposed hours of operations.
22 Mar 2005
Midwest Regional
48
CA Operations Docs
• CA_Disaster_Recovery_Procedure_ver_0.14
– An outline of the procedures to be used if there is a disaster with
the CA.
• cspguide
– Manual of the CA software planning to use.
• InCommon_CA_Audit_Log_ver_0.31
– Proposed details for logging related to the CA.
• Internet2_InCommon_CA_Disaster_Recovery_from_root_key_c
ompromise_ver_0.2
– An outline of the procedures to be used if there is a root key
compromise with the CA.
• Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61
– Draft of the PKI-Lite CPS.
• Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21
– Draft of the PKI-Lite CP.
• Internet2_InCommon_Certificate_Authority_for_the_InCommon
_Federation_System_Technical_Reference_ver_0.41
– Document
22 Mar 2005
describing the CA.
Midwest Regional
49
Key Signing Process
•
2. Hardware descriptions
a. Hardware will be laptop and spare laptop with no network
capabilities, thumb drive, CDRW drive, media for necessary software
3. Software descriptions
a. OS, OpenSSL, CSP, Java tools for meta data
4. Log into computer
5. Generation of the CA Private Root key and self-signing
6. Generation of the Metadata signing key
7. Generate CSR for Internet2 origin
8. Signing of new metadata sites and trusts files
9. Backup copies of all private keys and other operational backup data
are generated.
10. Verify CD's and MD5 checksum
11. Write down passphrase and put in envelopes and sign envelopes
12. Securely store CA hardware and contents of local safe in safe
13. Log that these actions occurred on the log in safe and then close
and lock the safe
14. Put thumb drive into secure db and copy data onto secure db
15. Take private key password archive and other contents to Private
Key Password safe deposit box and record in log that this was done.
16. Take operational data archive to Operation Data safe deposit box
and record in log that this was done.
22 Mar 2005
Midwest Regional
50
The Potential for
• The federation as a networked trust facilitator
• Needs to scale in two fundamental ways
– Policy underpinnings need to move to normative
levels among the members; “post and read” is a
starting place…
– Inter-federation issues need to be engineered; we
are trying to align structurally with emerging
federal recommendations
• Needs to link with PKI and with federal and
international activities
• If it does scale and grow, it could become a most
significant component of cyberinfrastructure…
22 Mar 2005
Midwest Regional
51
, some time from now
• Established with several hundred participants
• Multi-layered strength-of-trust threads among
participants
• Working with state and/or regional federations
• “Peering” with national federations in other
countries
• “Gateways” with commercial federations
22 Mar 2005
Midwest Regional
52
Acknowledgements
• Design Team: David Wasley (retired U of C); RL ‘Bob’ Morgan
(Washington); Keith Hazelton (Wisconsin - Madison); Marlena
Erdos (IBM/Tivoli); Steven Carmody (Brown); Scott Cantor
(Ohio State)
• Important Contributions from: Ken Klingenstein (Internet2);
Michael Gettes (Duke), Scott Fullerton (Wisconsin - Madison)
• Coding: Derek Atkins (MIT), Parviz Dousti (CMU), Scott Cantor
(OSU), Walter Hoehn (Columbia/U of Memphis)
22 Mar 2005
Midwest Regional
53
For More Information
• Websites
http://middleware.internet2.edu
http://shibboleth.internet2.edu
http:/www.incommonfederation.org
Renee Woodten Frost
[email protected]
22 Mar 2005
Midwest Regional
54