Brown University Shibboleth at Brown University James Cramton April 2, 2009 Copyright © James Cramton 2009 This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author. Gilead then cut Ephraim off from the fords of the Jordan, and whenever Ephraimite fugitives said, 'Let me cross,' the men of Gilead would ask, 'Are you an Ephraimite?' If he said, 'No,' they then said, 'Very well, say Shibboleth.' If anyone said, 'Sibboleth', because he could not pronounce it, then they would seize him and kill him by the fords of the Jordan. Forty-two thousand Ephraimites fell on this occasion. Judges 12:5-6, NJB

2 Topics Shibboleth terminology & use at Brown WebAuth vs. Shibboleth Shibboleth-enabled services Attribute release policies and ARPviewer Installation and configuration Federation Logout Considerations

Shibboleth at Brown Standards-based web Single Sign On (SSO) service Can operate across domain boundaries Will replace WebAuth as Brown’s intra-campus SSO Currently supported by more than 100 applications Allows granular control of personal attribute release Provides access to many more attributes than WebAuth Can allow external federated users to access Brown resources without Brown credentials Can allow Brown users to access federated resources outside Brown using their Brown credentials 3

Shibboleth Terminology Identity Provider (IDP) –Performs user authentication for SP –Provides a customized set of attributes for each SP Service Provider (SP) –Runs on application host as an Apache OR IIS module or other interface –Authorizes user based on authentication & attributes from the IDP Attribute –A property describing a user within the system Human-friendly examples: brownType, brownStatus, displayName, isMemberOf Minimal identifier: an opaque (gibberish) identifier unique to each user at each SP –Typically used for authorization or UI customization Federation –A group of organizations who share a common trust framework 4

WebAuth vs. Shibboleth Brown’s WebAuth Proprietary, and compatible only with Apache and IIs (sort of) 10 years old, unsupported Dependent on Brown Grouper –Also proprietary and unsupported Limited and arbitrary set of attributes released to apps Limited to Brown users Not load balanced Not redundant Internet2’s Shibboleth Standards-based –LDAP, SQL, SAML 1.1 and 2.0, ADFS Actively supported by community source model, Internet2 and partners Used by more than 100 applications Policy driven attribute release User-controlled attribute release Supports federation with 15M users –Use of Brown resources by external users –Use of external resource by Brown users Load balanced and redundant 5

Shibboleth-capable Services Currently in use at Brown All Apache web servers –Webpub –LAMP –WebApps All IIs web servers WebCT Brown Confluence Wiki University Tickets Dining Service’s Interphaze Coeus Planned or Possible Sympa list manager People Admin Outsourced NIH, NSF, NASA Grants Mgmt Microsoft Dreamspark Free MS software for students Discount student airline tickets caBIG Cancer grid computing TerraGrid grid computing Cern Large Hadron Collider Virtual Organizations (VOs) Many more… 6

Attribute Release Policies Protect user identity by releasing only necessary attributes to SP Attribute release policies are configurable per SP, and per attribute Default attribute release policies –External SP sees only a unique, opaque identifier (gibberish) –Trusted Brown SPs see a more useful set of attributes, including: brownShortId, brownNetID, brownBruID, brownUUID, eduPersonPrincipalName mail, mailRoutingAddress DisplayName, givenName, sn, LOA (Level of Assurance) brownType, eduPersonPrimaryAffiliation, eduPersonAffiliation, eduPersonScopedaffiliation isMemberOf (full list of group memberships) –Default policies at SP owners may request exceptions to default policies Users can be required to manually approve attribute release –ARPViewer to present user an approval form –Approval or denial is audited 7

ARPViewer Example 8 ARPViewer can be triggered for each SP, or for a particular attribute condition for an SP When triggered, a user must confirm that they approve the release of the displayed information before the attributes are released to the SP. This process puts the attribute release decision in users’ hands. All responses are auditable.

Federation Shibboleth can leverage the federation’s trust relationships –Authenticate users at their local institution’s IDP –Pass attributes to a remote SP according to local attribute release policies –Grant access to remote resources based on released attributes Brown is a member of the InCommon federation, along with 2.2M users from more than 100 US higher ed institutions Inter-federation agreements can extend user base up to 15M A supportable solution to requests to grant access to Brown resources to non-Brown users –No need to establish Brown affiliate or guest accounts –External user’s home institution must belong to InCommon federation –Or user must use a credential from a supported provider like Protect Network Also allows Brown users to access external systems using Brown credentials: NIH grants, MS DreamSpark, University Tickets, etc. 9

Service Provider Installation If not using a CIS-supported application server, application admins can install and configure the Service Provider (SP) Typically, Linux SP installations use rpms; Solaris requires build CIS is available to assist, and has built known Solaris platforms SP configuration templates come from Subversion Once configured, notify Shibboleth administrator of SP metadata Complete details at 10

Example.htaccess ACLs # use Shibboleth to authenticate and authorize access AuthType shibboleth # Set ShibRequireAll to On to perform an AND operation for require statements # set ShibRequireAll to Off to perform an OR operation for require statements ShibRequireAll On # valid-user is minimum require statement to restrict access—use if handling authorization within application require valid-user # Usually better to limit access at least to active members of BROWN:COMMUNITY:ALL group require Shibboleth-isMemberOf BROWN:COMMUNITY:ALL require Shibboleth-brownStatus active # examples of course-specific ACLs to add to active members of brown:community:all ACL # allow members of Chem 1060 L01 Fall 2008 require Shibboleth-isMemberOf COURSE:CHEM:1060:2008-Fall:L01:All # allow members of Chem 1060 Fall 2008 all sections and labs require Shibboleth-isMemberOf ~ COURSE:CHEM:1060:2008-Fall:.+:All # allow students of Chem 1060 Fall 2008 all sections and labs require Shibboleth-isMemberOf ~ COURSE:CHEM:1060:2008-Fall:.+:Student # allow instructors of Chem 1060 Fall 2008 all sections and labs require Shibboleth-isMemberOf ~ COURSE:CHEM:1060:2008-Fall:.+:Instructor 11

Additional Information Brown’s Shibboleth project wiki: –Project schedule –Technical documentation for IDP and SP owners and administrators –Full attribute release policies and procedures for exception requests –Links to background information on Shibboleth Internet2’s Shibboleth wiki: –Background information on Shibboleth –Lists of Shibboleth-enabled software and services –Links to Shibboleth user list and other support options InCommon federation website: –Lists of participating institutions and vendors Protect Network website: –Information about obtaining InCommon-compatible credentials from Protect Network 12