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 and securely stored.

Whilst some of the data held within Discovery is openly available, the vast majority of the data is deemed 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 by 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 as part of the project 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 signed up to 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 an 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 and 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 three levels of each of these three categories.

Identity management levels

DDS supports 3 level of identity management.

• Level 0. Network level identity only. Personal Identity is unmanaged and unknown. DDS perhaps knows only the IP address , ports. The applications may use other standard artefacts such as cookies, but neither DDS nor the applications know the identity of the subscriber. Examples of this approach include access to the web site and this Wiki. Access may be blocked for security reasons

• Level 1. Self managed identity. A user self registers with their personal details i.e. creates their own account. No one manages identity but people are identified. DDS reserves the right to block access if possible if misused. 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, identity is 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 a process 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 referred to 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 application settings to block access or detect attacks.

• Level 1. Single factor authentication. User would use a 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 by DDS.

It should be noted at this point that authentication and identity may operate out of synchronisation (see the working example below). A particular person may authentication by level 0, level 1, or level 2 at different times. This is achieved by the use of roles.

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 the data controllers trusts the application (which may or may not be part of DDS) to have authenticated the user and no further permissions are required beyond those set by lock 1 and lock 2 data provisions. Access to sensitive data via this mechanism remains common practice in the NHS. DDS itself applies at least level 1 to 'systems' that have permissions to access data, allowing the system to handle end user authorisation, but over time, this is likely to be deprecated.

• Level 1. Application managed role based access control (RBAC). A user, during the authentication process has been assigned a role. The role comes with a set of permissions derived from a template, a permission 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 1 to support more granular rules and separates off the permissions system (known as the policy decision point). This operates 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, 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, and request to determine whether permission to proceed is granted or not.

In practice DDS, operates a combination of level 1 and level 2 with ABAC support becoming the norm when accessing sensitive data, in order to support granular permissions in line with professional policy.

Working example

The specification uses this working example that takes a professional through a journey of acquiring multiple roles, each requiring different levels of identity management, authentication, and use of rule based authorisation policies.

Dr Lonsdale is a senior General Practitioner who is also involved in epidemiological research at the University of Muncaster and is a clinical information officer for Cumbria CCG.

Starting out, whats available to see?

One day she hears about the the Discovery data service and goes to this Wiki, where she (rather spookily) reads about her journey. She does not enter any personal information. After reading the Wiki she becomes interested in browsing some of the public facing dashboards that are available and browsing the information model.

She clicks on the dashboard URL which brings up Discovery Explorer. Explorer requests a user id and password and also provides an option to "create account". Not having an account, Dr Lonsdale creates an account and enters her details, with her home email address as user id and a password from her 'low security list' of passwords she uses on public sites.

After having done this Explorer lets or on to the public dashboards. Explorer also shows here name and the fact that she has a role of 'General public'.

The next day she clicks on the information model URL which brings up the IM viewer. This also prompts for her user id and password, and her browser helpfully populates these. The IM viewer passes her directly on to the viewer application. She finds she can go back and forth from Explorer also without logging on again.

The next week she tries again to access Explorer using a different browser. She has forgotten her password so clicks on the 'forgotten password?' button. This asks here to verify her email and an email is sent with a link to re enter another password.

How are my practices doing?

After looking at the public dashboard she becomes interested in seeing how the practices in Cumbria are doing. Being a clinical information officer, the CCG agrees to create a user account for her, using her NHS email address. They send her an email which arrives with a link and she follows the link to add additional details such as her data of birth and a password.

She logs on to Discovery Explorer, this time with her NHS email user id and new password. Explorer lets her in. She now sees that she has a role assigned as "Health care professional at Cumbria CCG". When she uses the dashboard, she now sees she can see practice level aggregate information.

What are the characteristics of patients with AF who are not anticoagulated?

The research department of Muncaster University have been given permission to analyse, at patient event level, de-identified data in relation to a list of patients with AF, compared with a control population.

Dr Lonsdale notes that whilst she can see the dashboard AF information, she cannot see patient lists, or build queries. So she contacts the CCG to see if they can 'up' her permission. The CCG cannot do this but they refer he to the local AHSN that has a data sharing agreement with Cumbrian providers to view patient level de-identified data via Muncaster Universities secure data lake.

The AHSN assigns an additional role to Dr Lonsdale. Next time she logs on she is now offered two roles and she now selects "AHSN authorised Researcher at Muncaster University". She then states that this is her default role. She notices that the Explorer app has a new menu item ' Discovery reports'. She clicks on this which then directs here to a new URL but this appears blocked.

Dr Lonsdale has been advised that in order to build reports and view lists she must log on to the Discovery secure zone via a 'VPN'. She gets instructions and having established the VPN connection she now enters the URL again. She does not need to re-enter her details, but she goes to 'Discovery Reporter' where she is able to author reports and view some patient lists in a de-identified manner.

Who are my patients who need anti-coagulation?

Dr Lonsdale knows there are good reasons why many patients who appear to require anti-coagulation don't get it. Chronic diseases, dementia etc. So she authors some more advanced filter reports to reduce the list somewhat. However, there are many borderline cases that should be considered on a case by case basis so she also authors advanced concept criteria which display the relevant characteristics of patients when the record is accessed.

She is really interested in her own patients. As it currently stands she is unable to access identifiable lists but notices there is a link on Discovery Reporting and Discovery explorer called "Active patient link". On selecting this she is informed she does not have the rights to access this data.

This time she asks her practice manager to assign her a role in Discovery "GP at Ravenglass Railway Medical Centre". She is given instructions that in order to access data she must download an app for her phone, scan in a bar code, and get set up for 2 factor authentication.

When set up, she logs on, this time with the new third role, clicks the link and the user interface asks her for the one time pass code which she enters after selecting the phone app. She can now drill down and view her patient's records which are presented using the concepts she has already authored.

User accounts across DDS

Dr Lonsdale should preferably have a single user account across DDS. It may be the case that she has more than one account by dint of entering different details at some point, and as result of lack of, or perhaps failure of, identity management, but this would normally be avoided.

Her single account has a user profile which 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
• A status, indicating whether here account is active or not.

Her account is associated with one or more roles as described below

Users roles and authentication levels

One person two roles

A user (via their account) may be linked to one or more roles. In the case of public access utilities that support self account creation. Users' who create their own accounts would have a role of "General public". Users who have their account created will also have their role assigned to an organisation.

Users who log on with self created accounts have the simplest of roles and normally require single factor authentication.

Some roles require two factor authentication before they can be assigned at log on. In the example, the second role as a GP role requires 2 factor authentication.

Roles and authorisation- RBAC and ABAC

RBAC-> ABAC

DDS uses an amalgam of simple Role based access control and attribute based access control.

The architectural difference in implementation is significant.

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.