Identity Authentication Authorisation

This version : (0-1 Draft)

Abstract

The Discovery Data Service (DDS) enables access to data by subscribers, that data being sent to discovery by publishers.

Whilst some of the data held within Discovery is openly available, the vast majority of the data is sensitive personal data. In order to protect the privacy of that data, DDS operates a triple lock approach, which can be summarised as follows

• Lock 1. Data controllers must explicitly agree to the use of their data by subscribers via data sharing agreements. A data sharing agreement operates between a set of publishers and set of subscribers and the agreement describes the purposes of data sharing, the type of data being shared, and general consent policy followed by that agreement.

• Lock 2. Data is only made available as defined within data sharing projects. A data sharing project is inherently tied to one data sharing agreement. The project defines data sharing for specific purposes and includes the exact means by which specified data is made available, including the format and the scheduling. Furthermore the data that is available must be a subset of the data set within the data sharing agreement and subscribers and publishers must be a subset of the subscribers and publishers in the data sharing agreement.

• Lock 3. Data is made available to particular systems or people using attribute based access control. In this mechanism, a subject, (who may be a system or user) , via the application, requests access to a resource, (which may be a data resource, application or component), to perform a certain action (which is usually a function or function description), in the context of an environment. One or more policies are established independently of the application, the policy containing rules that determine which attribute values of the subject, resource or environment are needed to provide permission.

This specification focuses on Lock 3. This involves different types of activities with a number of different levels of security considerations.

Status of this document

This is the first and incomplete draft, focusing on some implementation capabilities required for the release of some utilities.

There have been no substantial changes since the previous version. For minor changes see the change log

Levels of management of identity, authentication and authorisation

Conceptually, DDS operates 3 levels of each of these categories.

Identity management levels

DDS supports 3 level of identity management.

• Level 0. Network level identity only. Personal Identity is unmanaged and unknown. DDS knows only the IP address , ports and other standard artefacts such as cookies, but does not know the identity of the subscriber. This level is used for access to the web site and this Wiki. Access may be blocked fod security reasons

• Level 1. Self managed identity. A user self registers with their personal details i.e. creates their own account. DDS does not manage identity, but may reserve the right to block access if possible if unused. This would enable access to public facing applications such as regional dashboards or browsing the common information model but would not be sufficient to enable access to data. In other words, managed by exception

• Level 2. Managed identity. The identity of a user or system is ascertained, according to a trusted authority who is operating an identity service. This is likely to use processes of identity management delegation, depending to the likely level of authorisation that would be given to the user. For example, a General Practice would manage the recording of identity of it's staff as long as they followed the processes described by the data sharing agreements.

Identity management itself is not part of DDS. DDS assumes that identity has been ascertained. However DDS, supports identity management via managed authentication and managed authorisation.

Authentication levels

DDS supports 3 conceptual levels of authentication

• Level 0. Network level authentication. This supports level 0 identity management and is managed by various infrastructure settings and applications settings to block access or detect attacks.

• Level 1. Single factor authentication. User would use user ID and password, with a managed refresh interval. DDS uses the open ID connect protocol to enable a client (application) to verify the identity of the user against the authentication method employed by the DDS authorisation server.

• Level 2. Two factor authentication. User would use a user id and password together with a device based token generating a number. The same protocol as level 1 is followed.

Authorisation levels

DDS supports 3 conceptual levels of authorisation.

• Level 0. Application managed authorisation. The user or system, by dint of authentication, can access any resource, or perform any action, that the application itself has permission to use. In effect this means that DDS trusts the application to have authenticated the user and no further permissions are required beyond those set by lock 1 and lock 2 data provisions.

• Level 1. Application managed role based access control. A user, during the authentication process has been assigned a role. The role comes with a fixed set of permissions, usually in the form of a code. The application uses the role codes to determine whether a user can access the resource or perform an action. The application itself must understand the relationship between the role based codes and the actions it is trying to perform.

• Level 2. Attribute based access control. This extends level 0 and level 2 to separate off the permissions system (known as the policy decision point) from the application by intercepting the APIs, connecting to an enforcement point that passes on the request to a decision point. The decision point examines the attributes of the request and the attributes of the subject making the request, searches for relevant policies, and operates a set of rules comparing the attributes of the resource, together with environment features, against the attributes of the subject, to determine whether permission to proceed is granted or not.

User accounts across DDS

A particular person should preferably have a single account across DDS. It may be the case that the same person has more than one account by dint of entering different details, and as result of a failure of identity management, but this would normally be avoided.

A single account consists of:

• An internal identifier

• A profile consisting of a user name or device name, and for people, email addresses, mobile phone, and personal information such as forename, last name, gender, date of birth, password.
• A status, indicating whether an account is active or not.

A single user (via their account) is associated with one or more roles as described below

Users roles and authentication levels

A user (via their account) is related via one or more job roles to an organisation. In the case of public access utilities that support self account creation, the organisation would be the world and this would be automatically connected to the user. All users that are people, are automatically assigned as a Discovery user to the world organisation.

In addition, each user's specific job role is associated with a set of RBAC roles, which themselves are associated with a set of policies, with each policy containing rules. In other words the net effect is a type of Attribute based access control which can be represented via XACML , and implemented in a pragmatic manner.

This does not mean though that a person has a single set of authorisations, or a even a single authentication mechanism. Different facilities within DDS require users to have a role within an organisation and a user may be assigned different access profiles as a result of different DDS roles. In addition, when accessing utilities in the context of a project, a particular role may be associated with particular data access policies. Furthermore, when a user intends to access sensitive data, they may need to authenticate using 2 factor authentication at which point they are assigned a new RBAC role.

User job role and RBAC

For the purposes of person management, a user will be assigned at least one 'job' role associated with an organisation. A user may have more then one job role in an organisation if the policies assigned to that user differ with the roles.

A job role is not necessarily any particular ontological 'job' concept in the sense of a semantically defined occupation such as a Doctor or nurse. It is simply a way of seeding default policies for a list of job roles. These job roles will be based on the NHS job roles and related RBAC codes initially and these may be used within the applications where relevant.