Shibboleth & Federations

1. Shibboleth& Federations Renee’ Shuey May 4, 2004 ITS – Emerging Technologies The Pennsylvania State Universtiy

2. Agenda • Shibboleth - Background and Status • Technical Review -- how does it work? • Federations • InCommon Status • Shibboleth - Why?

3. What is Shibboleth? • An initiative to develop an architecture and policyframework 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)

4. 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

5. 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

6. 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.

7. 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.)

8. 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

9. 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

10. 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

12. OK, I redirect your request now to the Handle Service of your home org. Please tell me where are you from? I don’t know you. Not even which home org you are from. I redirect your request to the WAYF I don’t know you. Please authenticate Using WEBLOGIN 2 3 4 5 6 1 7 Credentials SHIRE HS 8 Handle User DB Handle Resource Manager Handle 9 AA SHAR OK, I know you now. I redirect your request to the target, together with a handle Attributes 10 Attributes I don’t know the attributes of this user. Let’s ask the Attribute Authority Let’s pass over the attributes the user has allowed me to release OK, based on the attributes, I grant access to the resource Shibboleth AA Process WAYF Users Home Org Resource Owner Resource

13. Shibboleth Architecture (still photo, no moving parts)

14. 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

15. Typical Attributes in the Higher Ed Community

16. 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.

17. 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

18. 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

19. 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…

20. 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.

21. 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

22. 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

23. 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

24. 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…

25. 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

26. 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….

27. 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)