IdP initiated logins to OpenAthens

Some SAML local authentication sources are capable of performing what are known as IdP initiated logins where the end-user starts by following a link to the local source instead of the resource. The local source authenticates the user and then sends them to a target in a way that starts a session. This is something that is intended to be used for final destination targets such as Email systems or VLEs and is not supported with middleware such as OpenAthens.

Why IdP initiated logins are not necessary with OpenAthens:

IdP initiated logins are not necessary because any time an end-user ends up at an OpenAthens authentication point without an OpenAthens session, they can start one - in cases where local SAML sources have been connected, the end-user is simply transferred to the local authentication source's sign-in and a session is established when they are returned:

In the diagram above, the user visits a page of service links and selects which resource they are interested in. The resource transfers the user to OpenAthens where either they have a session and attributes are returned, or they do not have a session and are referred to the local sign-in to establish one before returning attributes.

This transfer to your login from OpenAthens usually does not involve end-user interaction as they are almost always passed to OpenAthens in a way that identifies your organisation - i.e. the service links use the redirector or a WAYFless format, or the user has identified your organisation when the resource asked them. Users only see our sign-in page if it doesn't know where they are from and even then they will usually only need to see it once as it can remember where they were successfully authenticated before.

Should you wish to use IdP initiated links anyway, here is what you need to know:

It will not work as you might expect, and probably won't work at all.

It probably will not work because in this situation, your SAML connection is the IdP and OpenAthens is the SP. This is completely separate from using OpenAthens to access a resource where OpenAthens is the IdP and the resource is the SP.

An IdP initiated login URL might look something like this:

https://login.yourdomain.com/SSO?SPentityID=https://login.openathens.net/saml/2/metadata-sp&RelayState={ReturnURL} 

The first part will vary by your implementation, and the SP entityID parameter will in this case be OpenAthens. It is the RelayState parameter (or equivalent) at the end that is important to this discussion.

The relay state (or return URL) is where to return the end-user after establishing a session and should be a location in your own application or portal that is expecting the user to be sent there. The SAML standard requires this location to be consistent and opaque to your end-users, it also imposes a maximum size of 80 bytes.

A typical return URL has a short path and is a 302 redirect to a location such as a library catalogue where the end-users could be presented with WAYFless or Redirector links for access to resources:

In the diagram above, you can see that the end-user has to take a considerably longer route to the page of service links than the normal method covered at the top of the page.

The obvious complication is that if the user simply bookmarks the service links page when they get there, on future visits they would bypass the IdP initiated login and proceed as per the normal method. If you wanted to avoid this you would need to ensure that all visitors to that page were redirected via your IdP initiated login route on entry. This may entail significant work as your service links page would require some session management of its own.

Preventing phishing

To avoid being vulnerable to phishing, the URL that an end-user follows to launch this process must be an opaque link to a secure location in your application or portal which then forwards the end-user to the IdP initiated login URL.

Anything else to watch out for?

A common misconception is that the return URL or relay state can be the WAYFless or redirector URLs that would otherwise appear in your portal. This can seem attractive because it would be a simple way to avoid the problem of the user bookmarking the page of service links discussed above, however any attempt to do so is discouraged for a number of reasons:

• It opens the end-user to phishing attacks
• It forces both parties to do the work of establishing a session even when there already is one
• It goes against the SAML standard, which means...
  
  • It is unsupported
  • It cannot become supported