The OpenAthens authentication point (AP) has been designed to work on the widest variety of browsers and platforms that it reasonably can - your users should not have any difficulty using it on a desktop, tablet or smartphone. Older browsers may have some display quirks, though.
The AP is where a user logs into the OpenAthens service, and a user will pass through it every time they access a resource - they will only see it or interact with it if they are not already signed in (the session lasts up to eight hours or until the browser is closed).
The AP supports logins from both OpenAthens accounts you create in the interface and also interacts with your local directory if that is connected; depending on what type of local authentication is connected, the user might see a login box for an LDAP or Sirsi connection or be transferred invisibly to a SAML login such as ADFS.
When the AP does not know where they are from, users will see the organisation discovery page. Here, they can search for and select their organisation, at which point the user will be taken to your organisation-specific login page or your local login point if you have a delegated local directory connection.
If the user has already specified their organisation, such as by using a WAYFless URL or OpenAthens Redirector link, they will be automatically passed through to the appropriate sign-in page.
Underneath the search is a link to the generic OpenAthens login page for situations where it is still required, e.g. logging in with an OpenAthens account under an organisation that has a delegated local directory connection.
Organisation login page
Your organisation-specific sign-in page is where users are taken when the AP has been told where the user is from, either by the resource the user is accessing, the find your institution page, or the AP remembering the users' choice on a previous visit. This version of the page has some additional text options under the domain preferences and does not have a link back to the organisation search.
The problems signing in link on your organisation-specific sign-in page will take a user to the forgotten password page (https://login.openathens.net/auth?#forgottenpassword).
If the AP doesn't know where the user is from, it will first ask the user for their home organisation. This is because it can only help if you have an OpenAthens account, and since more than 80% of users are from organisations that use a local directory it wants to direct them to that organisation's login page for help.
There is a link below the sign in button that can help users. Here they can find the forgotten password function. Users coming from the generic login page will be asked to search for their organisation before being taken to the password reset page. If they need help, users can then see the organisation contact details by clicking on the need further assistance link.
Does the user always have to search?
This only comes up if the user arrives at the AP and the AP doesn't know where they are from. There are three main ways that the AP might know that without the user having to search themselves:
- The user selected a home organisation at a service provider
Because the AP has a unique address for each organisation, selecting your organisation at the service provider (or by a wayfless URL) will get the user to the AP in a known-organisation state so can go immediately to the correct authentication method. This will ignore any organisation the user has previously selected.
- The home organisation has been previously discovered and remembered by the AP.
Both the first scenario OR a user using the search box can initiate this, but the location is not stored until the user successfully authenticates. The location is stored in a cookie, so will be affected by any circumstance that clears cookies such as being on a kiosk machine. The setting is also cleared if the user does not pass authentication (so that users who select the wrong organisation are not stuck forever)
- The user is accessing a resource via the Redirector
The redirector uses links that are specific to your OpenAthens domain so users should always be recognised by the AP
There is a link under the search box that will show a user a generic OpenAthens login if they need one
What if I have multiple local connectors?
The best user experience will come from only having one connection, but if you need more the user will have the option to select which one. Depending on the type of connectors this could be presented as a drop down list or a selection box. The AP will remember the users' choice after a successful local authentication for one month or until the cookie is cleared.
OpenAthens accounts can be entered at any brokered connection, but since a delegated connection hands off to your local authentication page you would need to set an additional domain preference to use them alongside SAML, ADFS or API connectors.
Can I connect local authentication systems to sub-organisations?
This is not usually desirable from a user experience standpoint because the pre-discovery scenarios described above can only direct users to the domain organisation, not a sub-organisation (not even one with a unique scope). Instead you should set up the connection at the domain level and use the map to sub-organisation function - sub-organisations found at the AP will use this connection.
Which organisations can be found in the search box?
Anything to watch out for?
If you have multiple organisations that will appear, you should make sure that they have different enough names that users can select the correct one.
If you set a local connection as default you cannot use any other connectors.