Shibboleth and InCommon: Making Secure Collaboration a Reality Scott Cantor Internet2/MACE and The Ohio State University Scott Cantor Internet2/MACE and The Ohio State University

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

3 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

4 Outline What is Shibboleth? Shibboleth Federations and Trust Standards Convergence Current Status Library Considerations

5 What is Shibboleth? 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 (

6 What is Shibboleth? 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

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

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

9 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

: 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

11 High Level Architecture Knock, Knock… Resource Knock, Knock Resource Who’s There? Assertion Consumer Service abcde12345 Authn Authority Mary Attribute Requester Attribute Authority abcde12345 who? Attribute Requester Attribute Authority Mary, faculty, contract:001 Resource Let me in!

12 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

13 Shibboleth Project Deliverables An open source SAML implementation ( 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

14 Outline What is Shibboleth? Shibboleth Federations and Trust Standards Convergence Current Status Library Considerations

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

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

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

18 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

19 Federation Examples InQueue (Internet2 pilot federation) InCommon (Internet2/US, forthcoming) SWITCH (Swiss federation) Statewide initiatives Intra-university deployments Other international collaborations

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

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

22 Outline What is Shibboleth? Shibboleth Federations and Trust Standards Convergence Current Status Library Considerations

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

24 Liberty Alliance ID-FF 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

25 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 Q Migration to new standard will increase commercial interoperability and functionality.

26 Outline What is Shibboleth? Shibboleth Federations and Trust Standards Convergence Current Status Library Considerations

available since July 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 Current Status Pilots Current Status

28 Getting Started 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

29 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

30 Outline What is Shibboleth? Shibboleth Federations and Trust Standards Convergence Current Status Library Considerations

31 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

32 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

33 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 multi- authentication environment Institutional vs. library patron data