Transcript Shibboleth and InCommon: Making Secure Collaboration a Reality http://shibboleth.internet2.edu/ Scott Cantor ([email protected]) Internet2/MACE and The Ohio State University.

Shibboleth and InCommon:
Making Secure Collaboration a Reality
http://shibboleth.internet2.edu/
Scott Cantor ([email protected])
Internet2/MACE and The Ohio State University
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.
2
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
3
Outline
What is Shibboleth?
Shibboleth Federations and Trust
Standards Convergence
Current Status
Library Considerations
4
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)
5
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
6
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)
7
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.
8
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
9
2000: Federated Administration
2003: 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
10
High Level Architecture
Knock, Knock…
Knock, Knock
Resource
Who’s There?
Authn
Authority
Mary
Resource
abcde12345
Attribute
Authority
abcde12345 who?
Attribute
Requester
Attribute
Authority
Mary, faculty,
contract:001
Attribute
Requester
Let me in!
Assertion
Consumer
Service
Resource
11
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
12
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
13
Outline
What is Shibboleth?
Shibboleth Federations and Trust
Standards Convergence
Current Status
Library Considerations
14
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.
15
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)
16
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.
17
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
18
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
19
InCommon
http://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
20
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.
21
Outline
What is Shibboleth?
Shibboleth Federations and Trust
Standards Convergence
Current Status
Library Considerations
22
SAML 1.1
http://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
23
Liberty Alliance ID-FF 1.2
http://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
24
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.
25
Outline
What is Shibboleth?
Shibboleth Federations and Trust
Standards Convergence
Current Status
Library Considerations
26
Current Status
Pilots
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
27
Getting Started
http://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
28
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
29
Outline
What is Shibboleth?
Shibboleth Federations and Trust
Standards Convergence
Current Status
Library Considerations
30
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
31
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
32
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 multiauthentication environment
•Institutional vs. library patron data
33