Shibboleth and InCommon: Making Secure Collaboration a Reality shibbolethternet2/

Shibboleth and InCommon:Making Secure Collaboration a Realityhttp://shibboleth.internet2.edu/ Scott Cantor (cantor.2@osu.edu) 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.

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

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

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)

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

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)

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.

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

2000: Federated Administration2003: 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

Let me in! Knock, Knock Who’s There? Resource Resource Resource AuthnAuthority Mary abcde12345 AssertionConsumerService AttributeAuthority AttributeAuthority abcde12345 who? Mary, faculty, contract:001 AttributeRequester AttributeRequester High Level ArchitectureKnock, Knock…

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

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

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.

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)

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.

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 Dimensions of the Trust Continuum

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

InCommonhttp://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

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.

SAML 1.1http://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

Liberty Alliance ID-FF 1.2http://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

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.

Current StatusPilots Current Status • 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

Getting Startedhttp://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

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

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

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

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

Shibboleth and InCommon: Making Secure Collaboration a Reality shibbolethternet2/