{"id":357,"date":"2016-03-15T15:08:01","date_gmt":"2016-03-15T15:08:01","guid":{"rendered":"http:\/\/blogs.kent.ac.uk\/unseenit\/?page_id=357"},"modified":"2018-10-16T16:32:35","modified_gmt":"2018-10-16T15:32:35","slug":"authnz-requirements","status":"publish","type":"page","link":"https:\/\/blogs.kent.ac.uk\/unseenit\/authnz-requirements\/","title":{"rendered":"AuthNZ requirements"},"content":{"rendered":"

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

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.<\/p>\n

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.<\/p>\n

The language used in these requirements\u00a0should be read in line with RFC2119<\/a>.<\/em><\/p>\n

Gold<\/h3>\n
    \n
  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.<\/li>\n
  2. Maximum session length must<\/strong> be controllable on the Service.<\/li>\n
  3. SAML2 based Single Log Out must<\/strong> be supported allowing another Service to trigger a logoff event and for this service to trigger an IDP logoff.<\/li>\n
  4. Where appropriate, authorisation may<\/strong> be controlled out-of-band by another (scheduled) process based on up to date institutional data rather than from the SAML2 assertion.<\/li>\n
  5. The service must not<\/strong> require the use of unsolicited<\/em> or IdP initiated<\/em> single-sign-on<\/li>\n<\/ol>\n

    Silver<\/h3>\n
      \n
    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<\/strong> be applied to limit general access (via front door checks such as filtering based on an Account Type attribute).<\/li>\n
    2. Consideration must<\/strong> be given to the timely removal of specific access when a person changes role (for example a batch import process).<\/li>\n
    3. SAML2 based Single Log Out must<\/strong> be supported allowing another Service to trigger a logoff event and for this service to trigger an IDP logoff.<\/li>\n
    4. The service should not<\/strong> require the use of unsolicited<\/em> or IdP initiated<\/em> single-sign-on<\/li>\n<\/ol>\n

      Bronze<\/h3>\n
        \n
      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<\/strong> be supported over an encrypted protocol such as LDAPS or Kerberos.<\/li>\n
      2. Authorisation should<\/strong> 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<\/strong> be given to the automated management of this data.<\/li>\n<\/ol>\n

        Disconnected<\/h3>\n
          \n
        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.<\/li>\n
        2. These systems should<\/strong>:\n