P3 WAYF Pilot

Privacy Preserving Persistent WAYF Pilot Proposal

RA21 Privacy Preserving Persistent WAYF Pilot Proposal

To join the community discussion list for this pilot, please subscribe at https://lists.refeds.org/sympa/info/p3w-community.

Project Description

The RA21 Privacy Preserving Persistent WAYF (P3W) pilot seeks to validate the use of SAML-based federated authentication technologies to provide seamless access to scholarly resources for authorized users at participating institutions. The pilot seeks to demonstrate how institutional login credentials can be leveraged to provide a similar level of seamless access to scholarly resources that today’s IP address authentication provides through significantly streamlined Where Are You From (WAYF) UI flows whilst preserving the privacy of the end user.

The pilot will include participants at academic institutions that subscribe to scholarly resources, publishers, educational access management federations, vendors and service providers.

Objectives

The pilot project will focus on access to publisher resources by authorised users using desktop or mobile devices both within and outside the campus network by enabling a smart, shared discovery service so that users can authenticate to their institution, receiving authorization to access publisher material online, without having to select from too many options to find their Identity Provider.

The specific goals of this client-based WAYF pilot are as follows:

  1. To improve current Identity Provider (IdP) discovery processes by incorporating additional “WAYF hints” such as email domain and IP address into federation IdP metadata
  2. To improve current Identity Provider (IdP) discovery processes by developing a shared discovery service that uses both browser information and shared metadata hints to prioritise Identity Provider options for the user.
  3. To improve current resource provider sign-in UI flows by making use of available WAYF hints in IdP discovery flows whilst preserving user privacy via deep integration of the shared discovery service
  4. To determine the best way to populate the metadata registry with hints from the Service Providers regarding what Identity Providers are likely to work in an authorization scenario.
  5. To enable cross-resource-provider persistence of WAYF choice in a privacy preserving manner by using a client-based approach to persist user IdP choice in browser local storage
  6. To explore the current large installed base of institutional URL-rewriting proxy servers as a bridge technology between existing library and institutional authentication systems and SAML-based Service Providers (SPs)

The Discovery Service

This pilot would take advantage of an existing identity federation registry called the Trusted Academic Certification Authority Repository (TACAR) which would form the base repository of information on what Identity Providers exist in the world. This registry would be queried and stored in the samlbits.org infrastructure. The samlbits.org servers would run a telemetry service that acts like any SP registered in TACAR, and as such queries every IdP in the registry. From there, it builds a database of what SPs will work with what IdPs, based on automated responses (e.g., which IdPs throw an error when queried by an SP).

When a user uses a particular browser for the first time to access an SP, the discovery service will first check the browser’s local store and display the last IdP (or set of IdPs) used by the user. Users do not then need to deal with a large list of IdPs. However, if the local browser store is empty, or if the user chooses not to use any of the IdPs offered, the user will be presented with a search interface or a list that is built based on the database of IdPs that will be known to work with that SP.

If the IdP for the user does not show up on that list, it is quite likely it will not work (perhaps because the IdP is not releasing the necessary attributes for that SP) and it may be possible to generate an informative error message that explains why any specific IdP is not automatically on the list.

The telemetry approach has been tested as part of the eduGAIN connectivity test facility and is expected to be a good predictor of whether an IdP is useful for a given SP. In addition, the project will explore ways to improve the accuracy of the IdP selector by using additional data provided by the SP.

The User Experience

The first time that a user visits a participating Service Provider (SP) using a given browser/device, they will go through a streamlined WAYF UI in order to select their preferred Identity Provider (IdP) using the shared discovery service. The streamlined UI will use various hints from federation metadata (such as email domain, IP address, GEO locations, to suggest to the user the most relevant IdPs to select from. From the user’s perspective, they will only be presented with IdPs that have worked for them in the past or which are known to work with a given SP. Further error handling is possible, but will be unlikely in most use cases.

The user’s choice of IdP will be stored locally in their browser using browser local storage. The user will then be directed to authenticated via the chosen IdP.

On a subsequent visit to any participating service provider using the same browser/device, the preselected IdP choice(s) will be retrieved from local storage, and the user will automatically be redirected to authenticate via that IdP. If they already have a session established with that IdP, they will be returned to the SP as an authenticated user, yielding an experience almost as seamless as today’s IP-based authentication.

Roles and Participants

The Role of Participating Universities/Libraries

Libraries and university IT departments interested in participating in this pilot would need to be prepared to do the following:

  1. Set up a campus IdP and join an identity federation, if they have not already done so potentially making use of a third-party proxy solution from a participating service provider
  2. Work with the campus IdP to add agreed upon WAYF hints to their federation metadata.
  3. Trial the system with users, and collect feedback on their experience with the system.
  4. If interested, help to define the streamlined WAYF UI flows
  5. If interested, participate in developing the shared discovery service software for the purposes of the pilot
  6. If interested, help to define the WAYF hints to be added to federation metadata

The Role of Participating Resource Providers

Information resource providers interested in participating in this pilot would need to be prepared to do the following:

  1. Incorporate the remote discovery service and streamlined WAYF UI into their services
  2. Have a test SP that is configured to use the remote Discovery Service.
  3. Be prepared to test different ways to inform the discovery service about what IdPs the SP trusts (e.g., known customers; work with IdPs to ask them to decorate their own metadata with what SPs the IdP is willing to work with; using entity categories)
  4. Be prepared to help design a query interface or API so that the discovery service can ask “is this a customer of yours” and get back a response that would be automatically added to the discovery service database.
  5. Trial the system with users, and collect feedback on their experience with the system.
  6. If interested, help to define the streamlined WAYF UI flows
  7. If interested, participate in developing the shared discovery service for the purposes of the pilot
  8. If interested, help to define the WAYF hints to be added to federation metadata

The Role of Participating Educational Identity Federations

Vendors and service providers interested in participating in this pilot would need to be prepared to do the following:

  1. Help to define the WAYF hints to be added to federation metadata
  2. Incorporate the agreed upon WAYF hints in their federation metadata
  3. If interested, help to define the streamlined WAYF UI flows
  4. If interested, participate in developing the shared discovery service for the purposes of the pilot

The Role of Vendors and Service Providers

Vendors and service providers interested in participating in this pilot would need to be prepared to do the following:

  1. If interested, help to define the streamlined WAYF UI flows
  2. If interested, help to define the WAYF hints to be added to federation metadata
  3. If interested, participate in developing the shared discovery service for the purposes of the pilot
  4. If relevant, adapt their proxy software to act as a bridge between existing campus authentication systems/patron databases and participating SPs by acting as a SAML IdP.

Deliverables

The pilot process will be documented and a report will be provided to the RA21 community at the end of the pilot phase.  A shared registry will be made available for ongoing testing, and a list of best practices for handling the sharing of metadata in a shared model will be published.

  • A set of recommendations for WAYF hints to be incorporated into federation metadata
  • A recommendation on a streamlined WAYF UI flow
  • A working shared discovery service to meet the needs of the pilot
  • A proposal on how the pilot can be taken forward into a sustainable production service
  • A report on experience learned during the pilot and the pros/cons of taking it forward into production

Assumptions

  1. Resources/people are available as needed at participating organizations.
  2. That we can use existing infrastructure (samlbits.org) and review the tools and outcomes of a smaller pilot (this has been tested by SWiTCH in Switzerland)
  3. Any resulting software developed during the pilot will be released as Open Source

Work Breakdown Structure

There will be three independent work streams that can proceed in parallel:

  1. Incorporation of additional WAYF hints such as email domain and IP address ranges into participating federation’s IdP metadata, and utilization of this metadata in streamlined IdP discovery workflows by participating Service Providers
  2. Deployment of a shared discovery service which allows an end-user’s preferred IdP account to be selected and stored securely in their browser, and for this choice to be securely accessed by participating SPs thus allowing the user’s WAYF choice to be persisted across sites.
  3. Configuration and deployment of institutional URL-rewriting proxy servers as “SAML bridges”: instead of proxying traffic to participating SPs, they will instead redirect requests to access a participating SP site by redirecting to appropriate WAYFless URLs.

Participating organisations may choose to engage in one or more of these workstreams.

A fourth workstream will start after a testing environment is in place.

  1. Collect feedback from participants
    1. From resource providers/SPs – ease of implementation and input on different ways they would prefer to see the discovery service database updated
    2. From libraries – input on the user experience with using this kind of service and ease of implementation
    3. From federations – input on their willingness to see this metadata registry in production

Resources

The pilot group will need to include individuals with the following skills/experience

  • Software developers with experience of SAML, OpenID Connect and/or web application development
  • UI/UX experts
  • Individuals with expertise in SAML metadata schemes and standards
  • Project management

Participants in the P3W pilot include:

  1. Project Management
    1. GÉANT
  2. Educational Access Management Federations
    1. Sunet & SWAMiD (Swedish Federation)
    2. CANARIE
    3. InCommon
    4. eduGAIN
    5. EduServ
  3. Subscribing institutions
    1. MIT
    2. Johns Hopkins University
    3. Erasmus University Rotterdam
    4. University of Nottingham
  4. Service Providers
    1. ProQuest
    2. LibLynx
    3. Ebsco
    4. UNiDAYS
  5. Publishers
    1. Elsevier
    2. American Chemical Society

 

Schedule

The pilot will commence in Q2 2017 and aim to provide final recommendations by Q1-Q2 2018.