About the security model and why I cannot do X or Y

OpenAthens is a shared service in the same way as a cellular phone service is - one core service where customers pay for the use of it. This means that all of our customers and their users' accounts are contained within a shared platform, and because of this we need to make sure that no one has access to anything they should not - e.g. the administrator at University A must not be able to view details of the accounts of Hospital B and so on. This is enforced by the security model.

Some parts of it you will expect to be there and are things like:

• You cannot view, modify, delete or even infer anything about any other organisations' accounts.
• If the username and/or password are incorrect when you log in, you are denied access. 
• You cannot modify your own expiry date.
• After a time not interacting with the system you will need to re-authenticate.
• If your browser does not support required security technologies such as TLS, you are denied access.
• The sign out button does things on the back-end that simply closing your browser does not.

Excepting those, you will generally only run into the security model when you are from a large organisation with many sub-administrators and things come up with accounts that are no longer under your control. E.g:

• You click on an account on the audit page, but the account has been moved to a different organisation. If that organisation is not downstream of yours, then you will see a permission denied message.
• You move an account to a different organisation by using the action on the account details page. If that organisation is not downstream of yours, then you will see the details page replaced by a permission denied message when the move completes.
• You follow a link to a specific account's details. If that account is not (or is no longer) under your control, then you will see a permission denied message.
• You perform an all organisations search (if available) and the results page shows limited information for accounts that are not under the control of you or your own sub-organisations.

Will any of this affect my end users / patrons?

To a small degree, yes, but likely no more than they are accustomed to.

Because we need to protect against unauthorised access attempts, there are some error messages that we cannot make as helpful as we might like, e.g:

• The authentication point will not reveal whether it is the username or password that is incorrect, or if multiple wrong passwords have locked the account.
• The forgotten password function will not confirm if a username / email address is valid or not.

Whilst we would all like to be helpful to the user having difficulty, it has become more important that we do not reveal to an unauthorised user whether or not they have entered a valid username or email address which would allow them to focus their efforts.

We also limit the effectiveness of brute force attacks by disabling accounts for a few minutes if the password is repeatedly entered incorrectly (this appears in the audit log when it happens).

There are also some limitations on what can be used as a password, and there is monitoring that will disable an account automatically if it appears to be in several different countries on the same day.