Creating test accounts

If you are having problems accessing a resource, the publisher may (quite reasonably) ask you for a test account to help them diagnose the problems. This may be a more complicated request than expected for a couple of reasons:

• A standard OpenAthens account provides access to a wide range of other publishers' content. While it's unlikely that they will attempt to access content from other publishers, the possibility exists and may carry licensing implications.
• If you are using a local connector, your IT team may require you to leave a body part in escrow before they give you a test account that can potentially access your entire network... if they even allow it at all

Both are legitimate and reasonable concerns and here's how to safely work around them to give the publisher the access they need.

First make a regular OpenAthens account that only has access to the relevant resource

(This assumes you are operating in restrictive mode - if not then you can't restrict access via permission sets) 

1. Create a special permission set and call it something distinctive such as 'test1'
2. Allocate the relevant resource to the permission set
3. Create an account and only allocate it the 'test1' permission set
   1. In this case you probably want to manually set the password, and give it a short expiry date. 

Whilst you can reuse the special permission set and just update the resource in it as appropriate, you should at a minimum change the password of the test account before passing it to a different publisher - you might prefer to use different accounts.

How you or the publisher uses it

If you use OpenAthens accounts, or the LDAP or Sirsi connectors, then the account can be used as normal.

If you use other types of local accounts (e.g. where the user sees your own sign-in page such as ADFS, Azure, G-suite, etc) then there is a small difference in that the test user will need to set up an OpenAthens session before attempting access, otherwise they will end up at your local authentication point (and be stuck) when they follow their login route. The way to do this is for them to sign-in to MyAthens first before accessing their own site - https://my.openathens.net.  

What does it tell you and the publisher?

If they cannot gain access with the test account then it confirms a problem at their end. 

If the test account / publisher can gain access and your users do not then it could mean any of:

• You and your users are accessing the resource differently from them in some way - e.g. a broken wayfless URL, confusing buttons on their webpage
  • If you're in conversation with them, tell them the steps you're following
• Your accounts are configured incorrectly - e.g. the resource isn't in the assigned permission set(s), or those permission sets have a different role attribute set from the one on the test account

Anything to watch out for?

It can be up to five minutes (typically less) before changes to permission sets take effect, so test the test account via MyAthens before passing it on.