Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


For the first scenario you will need to implement a discovery service (sometimes called a WAYF for Where Are You From) in which users will be able to choose their organisation from a list so you can send them to their institutional log on page with a SAML request. This list will ideally be accessed via a type-ahead rather than a drop down as there can literally be thousands of IdPs that appear. You can write your own, but using a central discovery service such as OpenAthens Wayfinder is encouraged for consistency (See: Discovery)

For the second scenario where users follow a curated link, wayfless URLs should be supported if possible - i.e. links that include the IdPs entityID and avoid additional discovery; e.g.<IdP_entityID>&target=<targetURL>. This kind of URL is incredibly popular with IdPs who wish to simplify user access. These links should use federation entityIDs rather than your own customer IDs for compatibility with other systems.


A common method to authorise users is based on the organisation they are from, and this can be implemented by making use of the organisation identifier (scope). You should not use entityID for authorisation as it prevents you providing different levels of subscription across large organisations or consortia. It is also possible to perform more granular authorisations based on attributes such as role or entitlements.


You may want to use some items of personal end-user data to enhance their experience, e.g. to avoid a separate registration process. The GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA attempts to define behavioural rules for Service Providers which want to receive user attributes from the Identity Providers managed by the Home Organisations. It is our experience though that identity providers are very reluctant to release personal information, even without GDPR and similar legislation, so you should not expect to be able to it and must not require it.

Deep linking

Deep linking (or article level linking) via authenticated links should be supported wherever possible as this is highly desirable to your customers. Your implementation should allow a target page variable to be passed to the authentication process for the user to be directed to after authorisation and any customer identifiers included in these access URLs should be those used by the federation to allow links to be tokenised in a consistent way (e.g. use the subscribers' federation entityIDs rather than your own subscriber number).


If you wish to offer the user the option to also logout from their identity provider when they log out of your site, it must be separate from the logout of your site – i.e. a user choice. See: Logout function

Expired Sessions

When sessions expire, you should wherever possible allow them to restart their session at the same page.