OpenAthens can connect to several types of resources and sometimes it is not possible for the resource catalogue to contain an access URL that works for everyone; in some cases there may not be any pre-configured access URL at all - this will be indicated by an icon on the catalogue card and generally applies to resources that are not in the OpenAthens federation:
OpenAthens resources will almost always have an access URL. The difficulty arises with resources in other federations because there is no standard way of providing access URLs via the federation metadata due to the way that the earliest federations were planned and implemented so there are times when we just do not have the data.
What this means to you is that before allocating a new resource to permission sets, you should look at the access URL, add one if necessary (ask the resource provider for a "WAYFless URL") and test it before allocating the resource to your users.
We can add access URLs for resources as we become aware of them but for resources outside of the OpenAthens federation we have no direct relationship with the providers ourselves and whilst we may have a good idea of what any given access URL will be, we do not ourselves have access so cannot test it. You can help by passing on any working URLs you are given by the service providers when you have needed to add one. Our service desk can check them and then include them with the resource in the catalogue for all to benefit from.
If your users are being presented with redirector links the access URL will usually be bypassed in favour of the specified target URL.
There are two common types of access URL for federated resources (often called WAYFless URLs because they bypass the step where the user has to select an organisation on the Where Are You From page).
The main type is where you pass your entityID and sometimes a target page to the service's sign on point such as:
You should use your own entityID in these links.
The second type is where you pass the service's entityID and sometimes a target page to your own login page such as:
This second type is based on the SAML1 standard that was superseded by SAML2 in 2005 so should not only be rare, but also avoided where possible.
Other types... are neither predictable nor consistent. In those cases you have to contact the supplier for a suitable access URL and apply it manually.