Michael R Gettes, Duke University On behalf of the shib project team Shibboleth Update Michael R Gettes, Duke University On behalf of the shib project team

What is Shibboleth? (Biblical) A word which was made the criterion by which to distinguish the Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce “sh”, called the word sibboleth. See --Judges xii. Hence, the criterion, test, or watchword of a party; a party cry or pet phrase. Webster's Revised Unabridged Dictionary (1913) CAMP Directory Workshop Feb 3-6, 2004

What is Shibboleth? (modern era) An initiative to develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services 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) CAMP Directory Workshop Feb 3-6, 2004

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? CAMP Directory Workshop Feb 3-6, 2004

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 interrealm trust fabrics: federations and virtual organizations Leverage campus expertise and build rough consensus Influence the marketplace; develop where necessary Support for heterogenity and open standards CAMP Directory Workshop Feb 3-6, 2004

Attribute-based Authorization Identity-based approach The identity of a prospective user is passed to the controlled resource and is used to determine (perhaps with requests for additional attributes about the user) whether to permit access. This approach requires the user to trust the target to protect privacy. Attribute-based approach Attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. This approach does not degrade privacy. CAMP Directory Workshop Feb 3-6, 2004

Stage 1 - Addressing Four Scenario’s Member of campus community accessing licensed resource Anonymity required Member of a course accessing remotely controlled resource Member of a workgroup accessing controlled resources Controlled by unique identifiers (e.g. name) Intra-university information access Controlled by a variety of identifiers Taken individually, each of these situations can be solved in a variety of straightforward ways. Taken together, they present the challenge of meeting the user's reasonable expectations for protection of their personal privacy. CAMP Directory Workshop Feb 3-6, 2004

Shibboleth Status V1.1 available August 2003 Relatively straightforward to install, provided there is good web services understanding and middleware infrastructure (authentication, directories, webISO, etc.). Target - works with Apache and IIS targets; Java origins. V2.0 likely to include portal support. Work underway on some of the essential management tools such as attribute release managers, target resource management, etc. Can take between 3 hours and 3 years to install How much infrastructure (core middleware) do you already have? CAMP Directory Workshop Feb 3-6, 2004

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.) CAMP Directory Workshop Feb 3-6, 2004

How Does it Work? Hmmmm…. It’s magic. :-) CAMP Directory Workshop Feb 3-6, 2004

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 CAMP Directory Workshop Feb 3-6, 2004

Technical Components Origin Site – Required Enterprise Infrastructure Authentication Attribute Repository Origin Site – Shib Components Handle Server Attribute Authority Target Site - Required Enterprise Infrastructure Web Server (Apache or IIS) Target Site – Shib Components SHIRE SHAR WAYF Resource Manager CAMP Directory Workshop Feb 3-6, 2004

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

From Shibboleth Arch doc Origin Target CAMP Directory Workshop Feb 3-6, 2004

From Shibboleth Arch doc Origin Target CAMP Directory Workshop Feb 3-6, 2004

From Shibboleth Arch doc Origin Target 1 SHIRE Local Navigation Page 3b 3 4 Handle Service Attribute Authority CAMP Directory Workshop Feb 3-6, 2004

From Shibboleth Arch doc Origin Target University Resource Provider HTTP Server 1 SHIRE Local Navigation Page 3b Authentication System 3 4 Enterprise Directory Handle Service 6 5 3c Attribute Authority CAMP Directory Workshop Feb 3-6, 2004

Demo! http://shibboleth.blackboard.com/ CAMP Directory Workshop Feb 3-6, 2004

Shibboleth Architecture (still photo, no moving parts) CAMP Directory Workshop Feb 3-6, 2004

Shibboleth Architecture -- Managing Trust engine Attribute Server Target Web Server Browser CAMP Directory Workshop Feb 3-6, 2004

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 CAMP Directory Workshop Feb 3-6, 2004

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 CAMP Directory Workshop Feb 3-6, 2004

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. CAMP Directory Workshop Feb 3-6, 2004

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 CAMP Directory Workshop Feb 3-6, 2004

Managing Authorization InCommon 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 CAMP Directory Workshop Feb 3-6, 2004

What are federations? Initially “Authenticate locally, act globally” 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… CAMP Directory Workshop Feb 3-6, 2004

Why Shibboleth Higher Ed is a collaborative enterprise Faculty have strong ties to peers at other institutions With wed-based IMS systems, faculty share resources with their peers Research is a collaborative enterprise Robert Zimmer reported that during the next three to five years, Brown will establish several multidisciplinary centers or institutes that will bring faculty expertise and resources together in optimal ways, possibly through collaboration with other institutions. “Research in the future will be all about collaboration and distributed research groups that are facilitated through technology.” - Andries van Dam, VP Research, Brown University CAMP Directory Workshop Feb 3-6, 2004

Why Shibboleth? Security Better security tools will make collaboration more “painless” and more secure Current "solutions" are primitive; we can do better today and without local overhaul Shibboleth Simplifies Management and Use of Distributed Systems CAMP Directory Workshop Feb 3-6, 2004

Why Shibboleth? Improved Access Control Use of attributes allows fine-grained access control Simplifies management of access to extended functionality Librarians, based on their role, are given a higher-than-usual level of access to an online database to which a college might subscribe. Librarians and publishers can enforce complicated license agreements that may restrict access to special collections to small groups of faculty researchers CAMP Directory Workshop Feb 3-6, 2004

Why Shibboleth? Federated Administration Leverages existing middleware infrastructure at origin (authN, dir) Users registered only at their “home” or “origin” institution Target does NOT need to create new userids Flexibly partitions responsibility, policy, technology, and trust Authorization information sent, instead of authentication information when possible, use groups instead of people on ACLs identity information still available for auditing and for applications that require it CAMP Directory Workshop Feb 3-6, 2004

Why Shibboleth? Privacy Higher Ed has privacy obligations In US, “FERPA” requires permission for release of most personal identification information; encourages least privilege in information access General interest and concern for privacy is growing Shibboleth has active (vs. passive) privacy provisions “built in” CAMP Directory Workshop Feb 3-6, 2004

Benefits to Campuses Much easier Inter-Domain Integration With other campuses With off-campus vendor systems Integration with other campus systems, intradomain LMS Med School…… Ability to manage access control at a fine-grained level Allows personalization, without releasing identity Implement Shibboleth once… And then just manage attributes that are released to new targets CAMP Directory Workshop Feb 3-6, 2004

Benefits to Targets/Vendors Unified authentication mechanism from the vendor perspective Much more scalable Much less integration work required to bring a new customer online. Ability to implement fine-grained access control (e.g. access by role), allowing customer sites to effectively control access by attributes and thus control usage costs, by not granting access unnecessarily Once the initial Shibboleth integration work has been completed on the vendor’s systems The incremental cost of adding new customers is relatively minimal In contrast to the current situation -- requiring custom work for each new customer Ability to offer personalization If your customers have Shibboleth implemented, easy implementation for them CAMP Directory Workshop Feb 3-6, 2004

Who is Using Shibboleth? CAMP Directory Workshop Feb 3-6, 2004

InQueue Origins 11.25.03 National Research Council of Canada Columbia University University of Virginia University of California, San Diego Brown University Penn State University Cal Poly Pomona London School of Economics University of North Carolina at Chapel Hill CU-Boulder UT Arlington UTHSC-Houston University of Michigan Rutgers University University of Wisconsin New York University Georgia State University University of Washington University of California Shibboleth Pilot University at Buffalo Dartmouth College Michigan State University Shibboleth Development Origin The Ohio State University UCLA Internet2 Carnegie Mellon University CAMP Directory Workshop Feb 3-6, 2004

Shib academic SIG Lots of interesting design issues for use of Shib, e.g Passing attributes during deep-linked text Handling meta-search engines Managing persistent identifiers where needed Dealing with proxies in a semi-Shibbed world The issues so far have all been solvable; the challenge is in picking the right solution. Subscribe and participate via the I2 listserv at http://www.internet2.edu/about/lists.html (sigh, soon to be Shibbed…) CAMP Directory Workshop Feb 3-6, 2004

Currently participating publishers, aggregators, technology partners Round 1 OCLC JSTOR EBSCO Elsevier Ex-Libris (sfx) Round 2 (being approached now) CSA (Cambridge Scientific Abstracts) ISI Ovid Proquest Gale Group Lexis-Nexis CAMP Directory Workshop Feb 3-6, 2004

Other Technology Partners LMS Systems Blackboard WebCT WebAssign Syquest/ Higher Markets Student Charge Card vendors Napster CAMP Directory Workshop Feb 3-6, 2004

Other Pilot Projects American Association of Medical Colleges NSDL (National Science Digital Library) SWITCH - The Swiss National Academic Community UK/JISC - Controlled Access to Licensed Resources Becta (British Educational Communications and Technology Agency) Univ Texas, Medical Center and instruction Washington Research Library Consortium (WRLC) CAMP Directory Workshop Feb 3-6, 2004

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 CAMP Directory Workshop Feb 3-6, 2004

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? CAMP Directory Workshop Feb 3-6, 2004

THE END? Acknowledgements: Design Team: David Wasley UCOP; 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) CAMP Directory Workshop Feb 3-6, 2004

Global? Trust Diagram (TWD) CAMP Directory Workshop Feb 3-6, 2004

Sample InterFederation CAMP Directory Workshop Feb 3-6, 2004

Shib/PKI Inter-Federations This model demonstrates the similarities of the PKI communities and Shib Federations. This does not mean that Shib == PKI, just that we can leverage the trust infra of a global PKI to maybe solve some larger inter-federation issues of other techno / policy spaces in a common fashion. CAMP Directory Workshop Feb 3-6, 2004

Got SHIB? CAMP Directory Workshop Feb 3-6, 2004

Shibboleth intra- as well as inter-realm Keith Hazelton University of Wisconsin I2 Middleware Arch. Comm. for Education

Shib intra/inter-realm Common Shib adoption driver will likely be libraries who want to connect to electronic resource providers Leveraging Shib as local infrastructure: intra-realm Shibboleth (with AuthN shim) as completion of the IdM loop: giving apps the info they need to make access control decisions (AuthZInfo Access) CAMP Directory Workshop Feb 3-6, 2004

Shib as WebISO Note: Shib as shipped assumes an existing WebISO But in a Shib environment for web apps the only web thing that needs an authentication step is the Handle Server (HS) (!!!) all target web apps leverage that single authentication step CAMP Directory Workshop Feb 3-6, 2004

Shib as WebISO WebISO solutions have lots moving parts that are handled by Shib So what’s the simplest AuthN shim for the HS? CAMP Directory Workshop Feb 3-6, 2004

Shib as WebISO HS runs as an Apache app How do we protect Apache apps? URL/directory based authN schemes Use Apache config file fiddling to specify how Shib 1.1 as shipped has way to do this with Public Key Infrastructure (PKI) user certs Apache Asks for client SSL authentication via apache-ssl or mod_ssl Right environment variables get populated, presto! CAMP Directory Workshop Feb 3-6, 2004

Shib as WebISO: PKI integ. U California System developed PKI support code (David Walker) Adopted & adapted by UT-HSC Houston (Barry Ribbeck & Mark Jones) ..and by Dartmouth (Bob Brentrup, Omen Wild & Mark Franklin) CAMP Directory Workshop Feb 3-6, 2004

Shib & PKI Migration Calif, Texas & Dartmouth pushing PKI, so happy to “force” its use for selected apps Most of us not there yet What if HS could try for PKI as above, but fail over to LDAP-supported un/pw AuthN over SSL? CAMP Directory Workshop Feb 3-6, 2004

Shib & PKI Migration More generally: Protect the HS app the Apache way with PKI, failover to {your favorite AuthN service here} So, coordinating with above named culprits, Ryan Muldoon at wisc.edu developed an Apache module-based approach CAMP Directory Workshop Feb 3-6, 2004

Shib HS & AuthN Shim Apache security directives in config allow you to specify a list of AuthN methods in order of preference, So… Try PKI via above approach Second on the list is a module that does your favorite AuthN trick & populates env. vars. Like REMOTE_USER Ryan’s code supports failover to un/pw with LDAP (uses mod_perl) CAMP Directory Workshop Feb 3-6, 2004

Shib HS & AuthN Shim Kerberos shops could write a module for Kerberos AuthN, etc. Allows transparent… migration to, or experimentation with or selective rollout… …of PKI behind Shib HS for a general web app AuthN solution CAMP Directory Workshop Feb 3-6, 2004

The IdM Picture completed To extent you Shibbify your target resources, this fills the gap of AuthZInfo delivery to web apps You’ve authenticated by choice of methods (which can be passed along to targets) You’ve given targets controlled access to user attributes With all the knobs for privacy & anonymity you might want CAMP Directory Workshop Feb 3-6, 2004

Shibboleth inter-realm: Federations Shibboleth has support for federations (0, 1 or many) Doesn’t prescribe how they work Or even require one e.g. Penn State <-> WebAssign is simple bilateral agreement So what are federations, really? CAMP Directory Workshop Feb 3-6, 2004

A Burton Group slide from Catalyst 2003 in San Francisco Towards a polycentric, federated environment Many islands will emerge Identity networks will link the islands: Centralized services Member owned services (as in the ATM world) Use of common rating systems (like Moody’s) As islands and networks inevitably collide, not clear how they’ll converge CAMP Directory Workshop Feb 3-6, 2004

Renee Woodten Frost 6 February 2004 Federations Renee Woodten Frost 6 February 2004

Federated all the way down Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so: Build consistent campus middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then Federate (multi-lateral) those enterprise deployments with inter-realm attribute transports, trust services, etc. and then Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, from p2p to virtual organizations, etc. while we Be cautious about the limits of federations and look for alternative fabrics where appropriate. CAMP Directory Workshop Feb 3-6, 2004

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.” Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*) and common attributes (e.g. eduPerson) 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. Several federations now in construction or deployment CAMP Directory Workshop Feb 3-6, 2004

Requirements for federations Federation operations Federating software Exchange assertions Link and unlink identities Federation data schema Federation privacy and security requirements CAMP Directory Workshop Feb 3-6, 2004

Federated administration VO VO O T Apps CM O T CM Apps Other feds Campus 1 Campus 2 T T T Federation CAMP Directory Workshop Feb 3-6, 2004

Shibboleth-based federations InQueue InCommon Club Shib Swiss Education and Research Network (SWITCH) National Science, etc. Digital Library (NSDL) ------------------------------------ State networks Medical networks Financial aid networks Life-long learning communities CAMP Directory Workshop Feb 3-6, 2004

The Research and Education Federation Space REF Cluster InQueue (a starting point) InCommon SWITCH The Shib Research Club Other national nets Other clusters Other potential US R+E feds State of Penn Fin Aid Assoc NSDL Indiana Slippery slope - Med Centers, etc CAMP Directory Workshop Feb 3-6, 2004

InQueue The “holding pond” Is a persistent federation with “passing-through” membership… Operational today. Can apply for membership via http://shibboleth.internet2.edu/ InQueue Federation guidelines Requires eduPerson attributes Operated by Internet2; open to almost anyone using Shibboleth in an R&E setting or not… Fees and service profile to be established shortly: cost-recovery basis CAMP Directory Workshop Feb 3-6, 2004

InQueue origins as of 11-25-03 Rutgers University University of Wisconsin New York University Georgia State University University of Washington University of California University at Buffalo Dartmouth College Michigan State University Shibboleth Development Origin The Ohio State University UCLA Internet2 Carnegie Mellon University National Research Council of Canada Columbia University University of Virginia University of California, San Diego Brown University Penn State University Cal Poly Pomona London School of Economics University of North Carolina at Chapel Hill CU-Boulder UT Arlington UT Health Science Center-Houston University of Michigan CAMP Directory Workshop Feb 3-6, 2004

Major targets Campuses that are also origins, wanting to share campus-based content Content providers – EBSCO, OCLC, JSTOR, Elsevier, Napster, etc Learning Management Systems – WebCT, Blackboard, OKI, etc Outsourced Service Providers – purchasing systems, dormitory management companies, etc. CAMP Directory Workshop Feb 3-6, 2004

InCommon basics Permanent federation for the R&E US sector To be operated by Internet2, open to .edu-qualified sites and business partners Attributes passed: eduPerson Privacy requirements to be developed Security requirements to be developed CAMP Directory Workshop Feb 3-6, 2004

InCommon federation Federation operations – Internet2 ProductionTeam Federating software – Shibboleth 1.0 and above Federation data schema - eduPerson200210 or later and eduOrg200210 or later Federation privacy and security requirements – in discussion; could be: Privacy requirements: Initially, destroy received attributes immediately upon use Security requirements: Initially, enterprises post local I/A and basic business rules for assignment of eduPersonAffiliation values Likely to progress towards standardized levels of authentication Logout issues CAMP Directory Workshop Feb 3-6, 2004

InCommon planning steps Planning activities by ad hoc group of CIOs from participating organizations Decided initial form is that of an Internet2 project Set criteria for membership Drafted InCommon Prospectus Developed an initial management structure Executive Committee of members, generally CIOs or content provider reps Staggered 3-year terms, nominated by participants in InCommon with input from NPPAC Facilitated by Internet2 Internal process being engineered with oversight by technical experts CAMP Directory Workshop Feb 3-6, 2004

InCommon current status InCommon Executive Committee established and meeting bi-weekly via conference calls Advising on internal processes Drafting campus policy statements, framework for sharing Tuning Prospectus Discussing pricing Internet2 building infrastructure InCommon CA Redundant WAYF Web Sites and Communications Open doors - ? Spring 2004? CAMP Directory Workshop Feb 3-6, 2004

InCommon, some time from now Established with several hundred participants Multi-layered strength-of-trust threads among participants Working with state and/or regional federations “Peering” with national federations in other countries “Gateways” with commercial federations CAMP Directory Workshop Feb 3-6, 2004