Implementing Shibboleth A Publisher s Perspective UKSG Briefing Session

Implementing Shibboleth: A Publisher’s Perspective UKSG Briefing Session 3 -4 April 2006 Chris Shillum Vice President, Product Technology Elsevier

Agenda § § § § § Science. Direct background Authentication in general The Elsevier view Shibboleth specifics History of Shibboleth at Science. Direct Where are we now? Update from Terry Morrow: What is JISC Doing? Open issues and the future Questions 2

Science. Direct background § Elsevier’s primary online platform for full-text content § § Originally only locally hosted content (1994 onwards) 1999: commercial launch of online platform: www. sciencedirect. com Some facts: § § >2, 000 journals, >160 Book Series, 50 reference works Advanced browse and search, personalized alerts, history Extensive article and entity linking, federated searching Supports institutional subscriptions and individual article purchases 3

Authentication concepts in general Traditional authentication technologies § IP address checking § Username/password Shared authentication technologies § Centralized Authentication § Federated or Distributed Authentication 4

Authentication in general IP Address Checking Pros § Supports site-wide access § Supports anonymous access § Supports walk-ins Cons § Maintenance overhead for customer and vendor § Inherently insecure § Open proxy servers/IP spoofing § Dependency on network topology §Groups only identifiably if they have their own IP space § No native support for remote access § Proxy servers required 5

Authentication in general Username/Password Authentication Pros § Supports remote access Cons § Nightmare for users § Need a different username for every service § Complex administration for remote access § No standard between vendors § “Leaky” § Usernames can be shared with non-authorised users § No easy way to de-activate users when they leave the authorised community 6

Authentication in general Centralised Authentication User Online Service Auth. Server Campus Auth. Database Auth. Client Batch Upload Central Auth. Database Campus Administrator Admin Interface Campus Authentication System Vendor 7

Authentication in general Centralised Authentication Pros § Little or no IT implementation for customer Cons § Administrative overhead for customer § Difficult to maintain sychronisation between campus auth database and central auth database § Use different user credentials for central service logon vs campus logon § Batch, not real-time (aging technology) Example: “Classic” Athens (UK) 8

Authentication in general Federated Authentication User Auth. Service Campus Auth Database Campus Online Service Auth. Gateway Discovery/ Binding Service Authentication System Auth. Client Vendor 9

Authentication in general Federated Authentication Pros Cons § Allows access to remote services using campus logon credentials § No extra administrative overhead for customer § Simpler for users § More complex technical implementation for institution § Requires agreement on “rules of the game” between all vendors and institutions. Example: Shibboleth, Athens DA 10

Elsevier’s view on Shared Authentication § Strong supporter of Shared/Federated Authentication schemes § § § Fulfils customer needs Win/Win for customers and us (less admin) Has implemented Athens and Shibboleth We will continue to offer anonymous, campuswide access whatever the technology We will continue to offer personalisation (alerts, favourites, etc. ) in exchange for basic end-user registration 11

What is Shibboleth? § § A federated authentication protocol which enables online resources to be accessed with local credentials Developed by Middleware Architecture Committee for Education (MACE) of the Internet 2 Consortium in the US Based on standards such as SAML and PKI More info at shibboleth. internet 2. edu 12

Shibboleth is many things… § § A protocol specification An architecture Some open-source software which implements the architecture A project which manages definition of the protocol, architecture and development of the software 13

Shibboleth Software components User Online Service Auth. Service Handle Server WAYF Assertion Consumer Service Shibboleth Federation Campus Directory Attribute Authority Identity Provider Attribute Requester Service Provider 14

Role of Shibboleth Federations § § § Act as naming authority for members Gather, maintain and distribute operational metadata about members Establish trust framework » § § in practice by acting as Certificate Authority for SAML and SSL signing certificates Set common policies for members Vet members Provide infrastructure for identity provider discovery (WAYF) Define vocabularies of attributes and semantics 15

Shib benefits as we see them § Replacement for IP authentication for on-site access which: § § § Removes administrative burden of IP maintenance Decouples customer’s network architecture from authentication, so allows departmental purchases, etc. Allows personalized access to remote resources using local credentials Removes the need for users to remember different usernames and passwords Avoids problems of proxy servers for remote access Bottom line: helps us provide the broadest possible access to our customers’ user communities 16

Shib & SD history: ramp-up… § § § April 2002: Attended DLF/CNI workshop at NYU Held workshops with to involve customers and Internet 2 in the design process: Findings: § § Anonymous non-personalized access a must Provide option to personalize if an opaque, unique user identifier supplied (targeted ID) via normal end-user registration Needed support for deep linking May 2004: Initial Shib release § § Support for a single Federation …initially In. Queue Based on Shib v 1. 1 software 17

Shib & SD history: … testing… § § § May-Dec 2004: Pilot test Participants: Dartmouth; Georgetown; NYU; UCSD; Penn State Pilot aims: § § § No major problems getting up and running § § To determine what it takes to get campuses up and running with authentication via Shibboleth. To determine what end-user issues arise form the Shibboleth implementation on Science. Direct. Some issues with attributes, release policies, firewalls None of the pilot participants rolled out access to broad user community 18

Shib & SD history: … production! § Feb 2005: Moved in In. Common (US Production Federation) § § First vendor to use In. Common in production July 2005: Multi-federation support released § § § Main issue is branding and Identity Provider discovery in a multi-federation world Held more design workshops with representatives from multiple federations around the world Findings: » Need flexibility in which attribute assertions to request, according to Federation rules » Main issue is branding and Id. P discovery in a multifederation world » We have to know which WAYF to send user to… 19

The WAYF issue § WAYF (Where Are You From) page: from what institution are you? § § Normally operated by federation Multi-federation support means: from what federation are you? § No-one runs a WAYF of WAYFs End users don’t understand the federation concept … but federations are geographically oriented! § Elsevier’s solution: implement WAYF-functionality inside Science. Direct § Label federations geographically 20

Going forward… Elsevier status § § § Increasingly supporting US institutes via In. Queue/ In. Common SDSS (UK) - In production with LSE, preparing to roll out to all federation members Various various stages of pilot testing with five other European federations § § § SURFnet (Netherlands): completed pilot - now discussion move to production Switch. AAI (Switzerland) - currently conducting pilot HEAL-Link (Greece) - About to enter into pilot CRU (France) - About to enter into pilot HAKA (Finland) - About to enter into pilot Interest shown from: Denmark, Sweden, etc. 21

The example scenario… § § Logging in to Science. Direct with a local University of Tilburg username and password Live in production! 22

23

24

25

26

27

28

29

JISC Update Terry Morrow, JISC Consultant Joint Information Systems Committee

What is JISC doing? n Has written to institutions and suppliers explaining JISC’s strategy n Will create a UK Federation n Funding the Middleware Assisted Take-Up Service (MATU) – provides support for institutions - http: //www. matu. ac. uk/ n Providing case studies, reports, toolkits and advice – based on work carried out in its ‘early adopter’ programmes n Making MIMAS, EDINA and other JISC services Shibboleth compliant n Encouraging suppliers to investigate and implement Shibboleth technologies n Funding the provision of the Athens service until July 2008 n Funding the development of the Athens Gateways – support inter-working between Shibboleth and Athens sites and service providers. UKSG 2006 The JISC’s Shibboleth Programme 31

Timescales n July 2006: Renewal of Athens contract for 2 years; launch of the Athens Gateways n August 2006: First early adopters to join UK Federation n September 2006: Formal launch of the UK Federation n July 2008: End of JISC contract for Athens n 2006 onwards: Nesli 2 and other JISC contracts with suppliers will specify Shibboleth compliance UKSG 2006 The JISC’s Shibboleth Programme 32

Options for Publishers and other Service Providers Become a full member of the UK Access Management Federation, using community-supported tools BENEFITS No ongoing subscription costs, compliance with international standards and institutional requirements COSTS Internal effort to implement software, join federation and manage provider attributes Become a full member of the UK Access Management Federation, using tools with paid-for support BENEFITS Full support in implementation, compliance with international standards and institutional requirements COSTS Cost of support from supplier and internal effort in liaison between supplier and Federation Decide not to implement Shibboleth Continue with Athens or other access management solution BENEFITS Athens providers will have access to the Federation through the ‘gateway’, funded by the JISC at least until July 2008 UKSG 2006 The JISC’s Shibboleth Programme COSTS Providers using Athens will continue to pay current subscription and licence costs to Eduserv 33

Options for Institutions Become a full member of the UK Access Management Federation, using community-supported tools BENEFITS Full institutional control, skilled staff and access management solution for internal, external and collaborative resources COSTS Institutional effort to implement software, join federation and enhance institutional directories Become a full member of the UK Access Management Federation, using tools with paid-for support BENEFITS Full support in implementation and access management solution for internal, external and collaborative resources COSTS Cost of support from supplier and institutional effort in liaison with supplier and Federation Subscribe to an ‘outsourced Identity Provider’ to work through the Federation on your behalf (eg continued use of Athens with the gateways) BENEFITS Minimum institutional effort to achieve access to external resources only UKSG 2006 The JISC’s Shibboleth Programme COSTS Subscription costs to external supplier (from July 2008) and internal administration role 34

Closing Remarks Chris Shillum

Driving Adoption - Federations § Standardisation across federations is needed to ease Service Provider implementation, especially § § § Attribute syntax and semantics Certificates Metadata distribution policy Id. P granularity Advice: do what’s been done before, don’t reinvent the wheel 36

Driving Adoption – Publishers and SPs § Act now! § § Your customers will be asking you for this if they haven’t already Get involved in the community – shibboleth-users listserv (shibboleth-users@internet 2. edu) Understand the concepts and architecture Use the standard open-source implementation 37

Driving Adoption - Institutions § Decide who owns Shibboleth § § Largest barrier to implementation in establishing central source of identity for all users § § § Central IT? Library? Administration? Central Admin/HR database? Library patron database? Computing centre/IT user database? Once you have this, integrating the Shib software is relatively easy Need a killer-app to drive take-up, e. g. Napster at USC. 38

Open Issues and the Future… § § § Technology new, complex and rapidly changing Federations are in very early stages Uptake is key… we are in a critical phase Need to make implementation easier for smaller customers and vendors Elsevier is committed to making access easier for users and will continue to support Shibboleth 39

Thank you – Any Questions! Further information: Technology: Chris Shillum (c. shillum@elsevier. com) Product Manager: Ale de Vries (ale@elsevier. com)

End of presentation… 41

Shibboleth Mechanics

So what’s going on here? The Shibboleth framework allows Identity Providers (Id. Ps) to make Trusted Assertions about users to Service Providers (SPs) 43

Shibboleth Software components User Science. Direct Auth. Service Handle Server WAYF Assertion Consumer Service Shibboleth Federation Campus Directory Attribute Authority Identity Provider Attribute Requester Service Provider 44

Shibboleth Flow - Step 1 User Science. Direct Assertion Consumer Service Identity Provider § § § Service Provider User goes to protected resource, e. g. www. sciencedirect. com User requests to be authenticated by Shibboleth Resource passes control to SP’s Assertion Consumer Service 45

Shibboleth Flow – Step 2 User Science. Direct WAYF Assertion Consumer Service Shibboleth Federation Identity Provider § § § Service Provider SP’s Assertion Consumer Service redirects user to the “Where Are You From” service (WAYF) WAYF asks user who their Identity Provider is WAYF redirects user to their Id. P’s single sign-on system 46

Shibboleth Flow – Step 3 User Auth. Service Science. Direct Handle Server WAYF Assertion Consumer Service Shibboleth Federation Identity Provider § § Service Provider User logs in to their Id. P’s single sign-on system authenticates user 47

Shibboleth Flow – Step 4 User Auth. Service Science. Direct Handle Server WAYF Assertion Consumer Service Shibboleth Federation Identity Provider § Service Provider Id. P’s single sign-on system redirects user to SP’s Assertion Consumer Service providing unique handle for session 48

Shibboleth Flow – Step 5 User Science. Direct Assertion Consumer Service Campus Directory Attribute Authority Identity Provider § § § Attribute Requester Service Provider SP’s Attribute Requester uses handle to request needed information about the user from the IP’s Attribute Authority Id. P’s Attribute Authority retrieves requested attributes about user from campus directory and transmits securely to SP Upon receiving appropriate attributes, SP authorizes user’s request to access resource 49

How is trust established? § § § Assertions are signed using PKI certificates according to SAML standard (Security Assertion Markup Language) Interactions are SSL encrypted Trust is facilitated by “Federations” § Groups of organizations that agree to deploy Shibboleth according to certain operating principles, sharing common metadata and attribute definitions, etc. 50

Attribute Exchange § § Shibboleth facilitates exchange of attributes in a trusted manner between Identity Providers and Service Providers Examples of attributes – range from totally anonymous to personal information § § § Member of University of Jonestown Member of the Biology Faculty at the University of Jonestown John Smith, a professor in the Biology Faculty at the Springfield campus of University of Jonestown who’s eyes are blue and hair is grey 51

Attribute Policies § Attribute Release Policy (ARP) governed by Identity Provider, and eventually by users themselves § § May vary per target Service Provider Attribute Acceptance Policy (AAP) set by Service Provider § Defines which credentials the SP needs to provide access to the Service 52

Strong Privacy Protection § Service-provider and user-level Attribute Release Policies § Non-personally identifying attributes may be sufficient to grant access to services § “Targeted ID” mechanism § § Provides a unique, persistent identifier which is specific to an individual user accessing a specific SP from a specific Id. P Allows personalization while preventing aggregation of usage information across different SPs. 53