View
55
Download
0
Category
Tags:
Preview:
DESCRIPTION
Shibboleth & Federations. Renee’ Shuey May 4, 2004 ITS – Emerging Technologies The Pennsylvania State Universtiy. Agenda. Shibboleth - Background and Status Technical Review -- how does it work? Federations InCommon Status Shibboleth - Why?. What is Shibboleth?. - PowerPoint PPT Presentation
Citation preview
Shibboleth& Federations
Renee’ Shuey
May 4, 2004
ITS – Emerging Technologies
The Pennsylvania State Universtiy
Agenda
• Shibboleth - Background and Status• Technical Review -- how does it work?• Federations• InCommon Status• Shibboleth - Why?
What is Shibboleth?• An initiative to develop an architecture and policy
framework supporting the sharing – between domains -- of secured web resources and services
• Built on a “Federated” Model• A project delivering an open source implementation of the
architecture and framework
Deliverables:• Software for Origins (campuses)• Software for targets (vendors)• Operational Federations (scalable trust)
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.• 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 for heterogeneity and open standards
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 AuthN and AuthZ to Applications
Shibboleth Status
• Software Availability• Version 1.1 available August, 2003• Version 1.2 available April, 2004• Version 1.3 available Summer, 2003• Target implementation - works with Apache and IIS targets
• Campus Adoption accelerating…• Working with second round of information vendors• Java target implementation underway• Work underway on some of the essential
management tools such as attribute release managers, target resource management, etc.
Shibboleth Status
• Likely to coexist well with Liberty Alliance and may work within the WS framework from Microsoft.
• Growing development interest in several countries, providing resource manager tools, digital rights management, listprocs, etc.
• Used by several federations today – NSDL, InQueue, SWITCH and several more soon (JISC, Australia, etc.)
High Level Architecture
•Federations provide common Policy and Trust•Destination and origin site collaborate to provide a privacy-preserving “context” for Shibboleth users
•Origin site authenticates user, asserts Attributes•Destination site requests attributes about user directly from origin site
•Destination site makes an Access Control Decision•Users (and origin organizations) can control what attributes are released
Technical Components
• Origin Site – Required Enterprise Infrastructure• Authentication• Attribute Repository
• Origin Site – Shib Components• Handle Server
• Attribute Authority• Attribute Release Policy
• Target Site - Required Enterprise Infrastructure• Web Server (Apache or IIS)
• Target Site – Shib Components• SHIRE• SHAR• WAYF• Resource Manager
SAML
• Security Assertion Markup Language• A method of representing authentication and
authorization data in XML• The origin university signs the SAML assertion
with an x.509 signing certificate• Encryption can be provided by W3C's XML-
Encryption standard or by transporting the assertion in an SSL wrapped protocol
• Any protocol can be used to transport the SAML assertion.
• Developed by OASIS, Version 1.0.• Used by Shibboleth & Liberty Alliance
Shibboleth AA ProcessR
eso
urc
e
WAYF
Users Home Org Resource Owner1
SHIRE
I don’t know you.Not even which home
org you are from.I redirect your request
to the WAYF32
Please tell me where are you from?
HS
5
6
I don’t know you.Please authenticateUsing WEBLOGIN
7
User DB
Credentials
OK, I know you now.I redirect your requestto the target, together
with a handle
4
OK, I redirect yourrequest now to
the Handle Service of your home org.
SHAR
Handle
Handle8
I don’t know theattributes of this user.Let’s ask the Attribute
Authority
Handle9AA
Let’s pass over the attributes the userhas allowed me to
release
Attributes 10
Res
ou
rce
Man
ag
er
Attributes
OK, based on theattributes, I grant
access to the resource
Shibboleth Architecture (still photo, no moving parts)
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
Typical Attributes in the Higher Ed Community
Affiliation “active member of community”
member@washington.edu
EPPN Identity gettes@duke.edu
Entitlement An agreed upon opaque URI
urn:mace:vendor:contract1234
OrgUnit Department Economics Department
EnrolledCourse Opaque course identifier urn:mace:osu.edu:Physics201
Trust, and Identifying Speakers
•Federations distribute files defining the trust fabric• Individual sites can create bilateral trust•When a target receives a request to create a session, the AuthN Assertion must be signed by the origin (PKI validation), and the origin must be a member of a common Federation.
•When an Origin receives a request for attributes, it must be transported across SSL.
•The name of the Requestor (from the certificate) and the name of the user (mapped from the Handle) are used to locate the appropriate ARP.
Target – Managing Attribute Acceptance
•Rules that define who can assert what…..•MIT can assert student@mit.edu•Chicago can assert staff@argonne.gov•Brown CANNOT assert student@mit.edu
•Important for entitlement values
Managing Authorization
•Federations will NOT require members to do business with each other
•Target manages Access Control Policy specifying
•what attributes must be supplied •and from which origins• in order to gain access to specific resources
•Rules are attribute based
What are federations?
•Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions
•Built on the premise of •Initially “Authenticate locally, act globally”•Now, “Enroll and authenticate and attribute locally, act federally.”
•Federation provides only modest operational support and consistency in how members communicate with each other
•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.
•Over time, this will all change…
What is InCommon?• InCommon is…
• a formal federation of organizations focused on creating a common framework for trust in support of research and education…
• whose purpose is to facilitate collaboration through the sharing of protected resources, by means of an agreed-upon, common trust fabric.
• The InCommon federation is intended to support production-level end-user access to protected resources by providing the means to allow organizations to make effective decisions about sharing resources, based upon the attributes presented by a request user.
InCommon Federation Overview
•Federation operations – Internet2•Federating software – Shibboleth 1.1 and above
•Federation data schema - eduPerson200210 or later and eduOrg200210 or later
•Becomes operational April 2004, with several early entrants to help shape the policy issues.
•Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon
•http://incommon.internet2.edu
InCommon Management• Operational services by I2
•Member services •Backroom (CA, WAYF service, etc.)
• Governance
•Executive Committee - Carrie Regenstein - chair (Wisconsin-Madison), Jerry Campbell, (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teetz, (OCLC), David Yakimischak (JSTOR).
•Project manager – Renée Frost (Internet2)• Membership open to .edu and affiliated business partners
(Elsevier, OCLC, Napster, Diebold, etc…)• Contractual and policy issues being defined now…• Likely to take 501(c)3 status
InCommon Pilot• Phase One participants
• Cornell, Dartmouth, Penn State, SUNY-Buffalo, University of Rochester, USC, UT-Health Science Center-Houston, UVa, JSTOR, OCLC
• Exec Group’s Policy Sub-Committee (Tracy Mitrano, chair)
• Drafting evolutionary policies and procedures for members of federation.
• Considering other policy frameworks, e.g., EDUCAUSE Higher Ed Bridge Cert Authority (HEBCA), I2’s US Higher Ed Root (USHER) Cert Authority, etc.
• Exec Group’s Communications, Membership, Pricing and Packaging Sub-Committee (Susan Perry, chair)
• Who can join? How?• Getting the word out … in English
The potential for InCommon
• 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…
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
•Grid, Virtual Organizations
•SAML V2.0, Liberty, WS-Fed
•NSF grant to Shibboleth-enable open source collaboration tools
•LionShare - Federated P2P
Why Shibboleth & InCommon at Penn State?
• True collaborative effort• Open Source/Open Standards• Solves today’s problems• Leverages existing infrastructure• Authentication agnostic• Emphasis on privacy (FERPA)• Position to co-exist/support other federated
identity solutions on the horizon• We like Ken….
THE END
• Acknowledgements:
• Design Team: David Wasley (U of C); RL ‘Bob’ Morgan (U of Washington); Keith Hazelton (U of Wisconsin
(Madison));Marlena Erdos (IBM/Tivoli); Steven Carmody (Brown); Scott Cantor (Ohio State)
• Important Contributions from: Ken Klingenstein (I2); Michael Gettes (Duke), Scott Fullerton (Madison)
• Coding: Derek Atkins (MIT), Parviz Dousti (CMU), Scott Cantor (OSU), Walter Hoehn (Columbia)
Recommended