Getting production ready with Keystone

This page covers the tests your application needs to pass before publication in the OpenAthens Federation. The goal is not to tick boxes, but to make sure that our mutual customers get the best experience from us both. This includes being able to link seamlessly to your content from other applications. This can include content discovery services and user portals.

You shoujld review our best practices and technical recommendations first.

Pre-checks you should perform before submitting to OpenAthens for publication

Organisation discovery (WAYF, or Where are you from)

• There must be a method of signing in on the website via federated access, this should be labelled institutional login.
  1. Should be available on the homepage
  2. Should be available on content pages
  3. Should not mention specific software or technology e.g. Shibboleth/OpenAthens.
  4. Should not ask user to select the federation or region their organisation is from.
  5. If using your own organisation discovery service, it should allow organisation name search alongside any other methods such as email address.

Authentication / authorisation check

• Can you sign in to your application using your test OpenAthens credentials (Configuring your OpenAthens IdP for testing)

  1. If successful

     1. user should be able to tell that they are signed in e.g. “Access provided by {organisationName}”

     2. the sign-in button should no longer be displayed, or is replaced by a sign-out button (or equivalent)

  2. If unsuccessful

     1. user must be informed in some way that access has been denied access e.g. “You have successfully signed-in but your organisation does not have a subscription. Please contact your organisation's administrator”.

     2. user should be guided towards who they should contact e.g. “You have successfully signed-in but your organisation does not have a subscription. Please contact your organisation's administrator”

• Can you grant/limit access to match your differing subscription/license terms e.g. Concurrent users, a specific department within an organisation, partner organisations such as overseas campuses.

WAYFless linking

• Must have a WAYFless link syntax that contains the identity provider’s entityID such as https://auth.example.com/wayfless?entity={entityID}

  • e.g. https://auth.example.com/wayfless?entity=https://idp.example.edu/entity

  • When not already logged in to OpenAthens you should see that you are redirected to your test OpenAthens IdP for authentication

  • after signing in, you are returned to the homepage as a recognised subscriber

Deep-linking

• Directly from a deeper page within your application (i.e. not your homepage), go through the organisation discovery process and sign in via your test IdP. You should be returned to the specific page where you started the login process.

• Via a WAYFless link. Example syntax: https://auth.example.com/wayfless?entity={entityID}&target={contentURL}

  • e.g. https://auth.example.com/wayfless?entity=https://idp.example.edu/entity&target=https://example.com/some/webpage

Personalisation

• If you provide personalisation, e.g. bookshelves, favourites, watch lists, CPD (Continual Professional Development) credits, any such ‘profiles’ should be linked to the unique user identifier(s) you support via single sign-on.

• You should allow some flexibility on what attributes you need for the user identifier. Whilst federation customers will be able to send targetedID, they are changing to Pairwise-ID and if you intend to support 1:1 connections the customer might not be able to send either. 

  • We recommend building support for at least urn:oid:1.3.6.1.4.1.5923.1.1.1.10 (eduPersonTargetedID), and urn:oasis:names:tc:SAML:attribute:pairwise-id (Pairwise-ID) as a minimum for federation users.

• Profile provisioning - you should consider the provisioning options you support and whether they may be configurable per organisation. Things to consider:

  • Personally Identifiable Information (PII) should not be required

  • Auto-provisioning of new profiles

  • Whether a user needs to self-register

    • registering should be optional

    • not registering should still allow access to content

    • continuing without registering personally identifiable information should still allow personalisation

  • If you provide a registration form, or require PII, some organisations may request you to disable this for all of their users

Logout functionality

• If you provide a logout function, it must not automatically log the user out of their single sign on system. It may offer the user the choice to do so.

Check all the information for your application within the SP dashboard is production ready

Submit a publication request