AuthNZ requirements

When procuring or creating a new service, consideration must be given to how users will prove who they are (authentication – AuthN) themselves to it and how the services decides on a given user’s level of access (authorisation – AuthZ).

At Kent we try to keep the authentication process as consistent as possible both for users’ benefit and our own security benefit (training users to only provide credentials to trusted web pages goes a long way to reducing the likelihood of being phished!) and the authorisation process as transparent as possible by using existing institutional data to drive systematic decision making.

To that end, we’ve come up with some requirements for assessing new services’ viability in this area which are broken down into various levels of acceptability.

The language used in these requirements should be read in line with RFC2119.

Gold

  1. The University’s preferred method of providing Authentication and Authorisation to new services is by means of Federated Single Sign On using SAML2 (authentication) with access control (authorisation) controlled by attributes asserted during log on.
  2. Maximum session length must be controllable on the Service.
  3. SAML2 based Single Log Out must be supported allowing another Service to trigger a logoff event and for this service to trigger an IDP logoff.
  4. Where appropriate, authorisation may be controlled out-of-band by another (scheduled) process based on up to date institutional data rather than from the SAML2 assertion.
  5. The service must not require the use of unsolicited or IdP initiated single-sign-on

Silver

  1. Some services support Federated Single Sign On via SAML2 but require the authorisation or role based access to be managed within the application. Where this in place, safeguards should be applied to limit general access (via front door checks such as filtering based on an Account Type attribute).
  2. Consideration must be given to the timely removal of specific access when a person changes role (for example a batch import process).
  3. SAML2 based Single Log Out must be supported allowing another Service to trigger a logoff event and for this service to trigger an IDP logoff.
  4. The service should not require the use of unsolicited or IdP initiated single-sign-on

Bronze

  1. If the service does not support Federated Single Sign On via SAML2 then we can offer a Single Source of Sign On service via Active Directory or LDAP based authentication and authorisation for services to be hosted within the Kent network or via point-to-point VPN. This must be supported over an encrypted protocol such as LDAPS or Kerberos.
  2. Authorisation should be based on up to date institutional data such as Active Directory Group or LDAP attribute filter. Where this is not possible and authorisation data is stored locally within the service, consideration must be given to the automated management of this data.

Disconnected

  1. Some services are technically limited such that they do not acknowledge any external sources of authentication or authorisation data and require users to be registered within the system and have local service passwords.
  2. These systems should:
    • allow a password policy at least as strong as the standard University policy;
    • allow user data to be batch imported to reduce the management overhead of maintaining the system.

A combination of the above levels may be appropriate where multiple access methods are required such as when dealing with both Interactive Users and Service API Calls.

These requirements are also included in Information Services’ standard set of non-functional requirements (Kent IT Account required) which are used when formally procuring new services.