implementing shibboleth: a publisher’s perspective chris shillum vice president, product...
TRANSCRIPT
Implementing Shibboleth: A Publisher’s Perspective
Chris Shillum Vice President, Product TechnologyElsevier
UKSG Briefing Session3-4 April 2006
2
Agenda ScienceDirect background Authentication in general The Elsevier view Shibboleth specifics History of Shibboleth at ScienceDirect Where are we now? Update from Terry Morrow: What is JISC Doing? Open issues and the future Questions
3
ScienceDirect 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
4
Authentication concepts in general
Traditional authentication technologies IP address checking Username/password
Shared authentication technologies Centralized Authentication Federated or Distributed Authentication
5
Authentication in generalIP 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
6
Authentication in generalUsername/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
7
Authentication in generalCentralised Authentication
VendorVendorVendorCampusCampusCampus Authentication System
CentralAuth.
Database
Auth.Server
Auth.Client
CampusAuth.
DatabaseBatch
Upload
AdminInterface
Campus Administrator
OnlineService
User
8
Authentication in generalCentralised 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)
9
Authentication in generalFederated Authentication
VendorVendorVendorCampusCampusCampus
Authentication System
Auth.Client
Discovery/BindingService
OnlineService
CampusAuth
Database
User
Auth.Service
Auth.Gateway
10
Authentication in generalFederated Authentication
Pros Allows access to remote services using campus logon credentials No extra administrative overhead for customer Simpler for users
Cons More complex technical implementation for institution Requires agreement on “rules of the game” between all vendors and institutions.
Example: Shibboleth, Athens DA
11
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, campus-
wide access whatever the technology We will continue to offer personalisation (alerts,
favourites, etc.) in exchange for basic end-user registration
12
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 Internet2 Consortium in the US
Based on standards such as SAML and PKI More info at shibboleth.internet2.edu
13
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
14
Shibboleth Software components
Service ProviderIdentity Provider
OnlineService
CampusDirectory
ShibbolethFederation
AssertionConsumer
ServiceWAYF
User
Auth.Service
HandleServer
AttributeRequester
AttributeAuthority
15
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
16
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
17
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 InQueue Based on Shib v1.1 software
18
Shib & SD history: … testing… May-Dec 2004: Pilot test Participants: Dartmouth; Georgetown; NYU; UCSD;
Penn State Pilot aims:
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 ScienceDirect.
No major problems getting up and running Some issues with attributes, release policies, firewalls
None of the pilot participants rolled out access to broad user community
19
Shib & SD history: … production! Feb 2005: Moved in InCommon (US Production
Federation) First vendor to use InCommon 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 IdP discovery in a multi-federation world
» We have to know which WAYF to send user to…
20
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
ScienceDirect Label federations geographically
21
Going forward… Elsevier status Increasingly supporting US institutes via InQueue/
InCommon 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 SwitchAAI (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.
22
The example scenario…
Logging in to ScienceDirect with a local University of Tilburg username and password
Live in production!
31UKSG 2006 The JISC’s Shibboleth Programme
What is JISC doing?
Has written to institutions and suppliers explaining JISC’s strategy
Will create a UK Federation
Funding the Middleware Assisted Take-Up Service (MATU)
– provides support for institutions - http://www.matu.ac.uk/
Providing case studies, reports, toolkits and advice
– based on work carried out in its ‘early adopter’ programmes
Making MIMAS, EDINA and other JISC services Shibboleth compliant
Encouraging suppliers to investigate and implement Shibboleth technologies
Funding the provision of the Athens service until July 2008
Funding the development of the Athens Gateways
– support inter-working between Shibboleth and Athens sites and service providers.
32UKSG 2006 The JISC’s Shibboleth Programme
Timescales
July 2006: Renewal of Athens contract for 2 years; launch of the Athens Gateways
August 2006: First early adopters to join UK Federation
September 2006: Formal launch of the UK Federation
July 2008: End of JISC contract for Athens
2006 onwards:Nesli2 and other JISC contracts with suppliers will specify Shibboleth compliance
33UKSG 2006 The JISC’s Shibboleth Programme
Options for Publishers and other Service Providers
Become a full member of the UK Access Management Federation, using community-supported tools
BENEFITSNo ongoing subscription costs, compliance with international standards and institutional requirements
COSTSInternal 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
BENEFITSFull support in implementation, compliance with international standards and institutional requirements
COSTSCost 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
BENEFITSAthens providers will have access to the Federation through the ‘gateway’, funded by the JISC at least until July 2008
COSTSProviders using Athens will continue to pay current subscription and licence costs to Eduserv
34UKSG 2006 The JISC’s Shibboleth Programme
Options for Institutions
Become a full member of the UK Access Management Federation, using community-supported tools
BENEFITSFull institutional control, skilled staff and accessmanagement solution for internal, external andcollaborative resources
COSTSInstitutional effort to implement software, joinfederation and enhance institutional directories
Become a full member of the UK Access Management Federation, using tools with paid-for support
BENEFITSFull support in implementation and accessmanagement solution for internal, external andcollaborative resources
COSTSCost 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)
BENEFITSMinimum institutional effort to achieve access toexternal resources only
COSTSSubscription costs to external supplier (from July 2008) and internal administration role
36
Driving Adoption - Federations Standardisation across federations is needed to
ease Service Provider implementation, especially Attribute syntax and semantics Certificates Metadata distribution policy IdP granularity
Advice: do what’s been done before, don’t reinvent the wheel
37
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 ([email protected])
Understand the concepts and architecture Use the standard open-source implementation
38
Driving Adoption - Institutions Decide who owns Shibboleth
Central IT? Library? Administration?
Largest barrier to implementation in establishing central source of identity for all users
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.
39
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
Thank you – Any Questions!
Further information:
Technology: Chris Shillum ([email protected]) Product Manager: Ale de Vries ([email protected])
43
So what’s going on here?
The Shibboleth framework allows
Identity Providers (IdPs)
to make
Trusted Assertions
about users to
Service Providers (SPs)
44
Shibboleth Software components
Service ProviderIdentity Provider
ScienceDirect
CampusDirectory
ShibbolethFederation
AssertionConsumer
ServiceWAYF
User
Auth.Service
HandleServer
AttributeRequester
AttributeAuthority
45
Shibboleth Flow - Step 1
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
Service ProviderIdentity Provider
ScienceDirect
AssertionConsumer
Service
User
46
Shibboleth Flow – Step 2
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 IdP’s single sign-on system
Service ProviderIdentity Provider
ScienceDirect
ShibbolethFederation
AssertionConsumer
ServiceWAYF
User
47
Shibboleth Flow – Step 3
User logs in to their IdP’s single sign-on system IdP’s single sign-on system authenticates user
Service ProviderIdentity Provider
ScienceDirect
ShibbolethFederation
AssertionConsumer
ServiceWAYF
User
Auth.Service
HandleServer
48
Shibboleth Flow – Step 4
IdP’s single sign-on system redirects user to SP’s Assertion Consumer Service providing unique handle for session
Service ProviderIdentity Provider
ScienceDirect
ShibbolethFederation
AssertionConsumer
ServiceWAYF
User
Auth.Service
HandleServer
49
Shibboleth Flow – Step 5
SP’s Attribute Requester uses handle to request needed information about the user from the IP’s Attribute Authority
IdP’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
Service ProviderIdentity Provider
ScienceDirect
CampusDirectory
AssertionConsumer
Service
User
AttributeRequester
AttributeAuthority
50
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.
51
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
52
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
53
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 IdP
Allows personalization while preventing aggregation of usage information across different SPs.