Identity Authentication Authorisation
This version : (0-1 Draft)
The Discovery Data Service (DDS) enables access to data the data having been sent to Discovery by providers of healthcare services.
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 a 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 made available as part of the project must be a subset of the data covered by the data sharing agreement.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
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 self identified. 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 Sensitive data.
- 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. For example, a General Practice would manage Identity for staff members.
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.
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. A 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. A 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 authenticate by level 0, level 1, or level 2 at different times. This is achieved by the use of roles.
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 trust the application 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 but over time this is reducing.
- 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 designers of the application 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) from the application to an extent. This operates by intercepting the APIs that the application may use, connecting to a policy enforcement point that passes on the request to a policy decision point. The decision point examines the attributes of the request, searches for relevant policies, and operates a set of rules set by the policy, and responds with a permit or deny statement.For example, the policy may compare the attributes of the resource, together with environment features, against the attributes of the subject. In addition to permission being given, certain caveats can be given also.
In practice DDS, operates a combination of level 1 and level 2 with ABAC support becoming the norm when accessing sensitive data.
This 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 Discovery data service and goes to this Wiki. 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, as well as 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 low risk sites.
After having done this Explorer lets he view the public dashboards. Explorer also shows her 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. Unfortunately she has forgotten her password so she 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.
But there is a problem. Whilst Dr Lonsdale can see the practices in Cumbria she does not have authority to see practices in Yorkshire. To solve this problem the CCG has created an access policy that says that their clinical information officers can only view practice level data for those practices commissioned by Cumbria, but can view CCG information for the country. Somehow, this constraint must be taken account of.
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 can now see practice level aggregate information. However, she can only see practice level information for practices in Cumbria.
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 her to the local AHSN. The AHSN has a data sharing agreement with Cumbrian providers to analyse patient level de-identified data, for the purposes of population level analysis, via Muncaster University’s 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 states that this is her default role. She now notices that the Explorer app has a new menu item ' Discovery Analyser'. She clicks on this which then directs here to a new URL but this appears blocked.
The system informs her that her level of authentication is currently insufficient to use Discovery Analyser and that 2 factor authentication is required. She contacts the AHSN and she is given instructions to download an app for her phone, scan in a bar code, and set up for 2 factor authentication.
Having set this up she logs on to the application, this time entering a one time pass code and she can now access Discovery analyser where she can author reports and create record view concepts, and view de-identified patient lists.
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 should 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". As she has already set up 2FA she is ready to go.
When set up, she logs on without 2FA, this time with the new third role which she selects. She clicks the link and the user interface asks her to log on with 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
A user's account may be linked to one or more "roles". Roles may have names, and various attributes. In the case of public access utilities that support self account creation, users who create their own accounts could have a role of "General public". Users who have their account created by someone else 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 only single factor authentication.
Some roles require two factor authentication before they can be used to their full extent. As a matter of course, application functionality that access sensitive data will require 2 factor authentication. In other circumstances, ABAC Policies may enforce the requirement that 2 factor authentication has been performed.
DDS uses an amalgam of simple role based access control and attribute based access control.
The architectural difference in implementation is significant.
In RBAC the application, using the session state of the user’s role, determines whether an action can be performed according to the permissions associated with the RBAC codes assigned to the user in that role.
In ABAC there is a separation of concerns at an architectural level (and potentially at an infrastructure level). Also, there is a separation between the attributes of a user in a role, and the decision making process as to whether a particular resource can be accessed.
The Request -decision- response flow
The data flow supported by ABAC consists of the following:
- The application makes a request to it's policy enforcement point (PEP).
- The PEP packages the request and passes it to the Policy decision point (PDP).
- The PDP examines the request and looks for policies stored in the policy information point (PIP), by searching for policies relevant to the request and decides whether the request can be granted.
- The PDP passes the response back to the PEP. If the request is granted the PDP may also oblige the PEP to perform some other activity as part of the action.
- The PEP returns the response to the application. The application may also need to understand the obligations in respect of the access, although this could be delegated to the PEP, depending on the degree of separation of concerns in the application flow.
Such an approach enables a rule of any level of detail to be processed, whether this is purely related to application functionality, or the attributes of the resource itself.
For example, it is theoretically possible without any additional application development work, to deny access to the clinical record of a specific X GP or perhaps any GP over the age of 60 who is over 6 ft tall and of a taciturn nature.
User, roles and sessions
A user account may be associated with one or more roles. During the course of authentication a user selects one of the roles they wish to adopt for the session, which means that the user is operating in that role .
Roles will have a name. This makes it easier to identify the role of a person simply by reading the job role.
They may have a type from the ontology e.g a role may have a role type attribute that tends to indicate their job. An example may be a Professor or Research assistant or a General Practice manager. The main advantage of having a job role type is that it provides a visible basis for templates that pre-define default role attributes and values.
For example, it is likely that a General practitioner would have access to all the record of their patients. Therefore, having a role of being a GP enables a policy to test that the subject requesting access is a senior clinician. Thus attributes and values could be either inherited from (or copied from) the default template. it should be noted though that the fact of being a general practitioner does not imply a particular level of access. In ABAC it is up to the policy to determine access rights, but the policy may use the role type to make the decision.
The user's session role has a set of attributes which describe the user in more detail including their identity, level of security clearance, seniority and so on.
The fact of logging on with an authentication level (single or two factor) is also captured and assigned as an attribute to the user thus creating a user in session role. This flexibility enables a user in ROLE A to access some data but not others, unless fully authenticated but they do not have to change roles.
Organisation and project assignments
A user often performs a role in the context of working for a particular service or organisation. Their role often comes with an association with an organisation. Thus a user in role is likely to be assigned to an organisation.
Because DDS access is based around a publisher subscriber model derived from organisations, and as it would be the norm for most roles to be associated with an organisation, which can then be used both for conventional data sharing testing (i.e. a user's role's organisation S is a subscriber to data X) and also in any advanced ABAC rule ( can only see sensitive date from their own organisation).
The data sharing project attribute provides an additional attribute type, enabling a user in ROLE A to be assigned to PROJECT P. so that only a certain set of data or functionality can be accessed according to the project the user is assigned to
It is all very well having a permissions system that says "permit" or "deny" for accessing an application function or data resource, but in the working example there are also some additional constraints on what levels of data access is allowed by the different roles.
It is impractical to attempt to model advanced functionality within the policy definitions themselves. Therefore In order to facilitate this, a map is established between the application functionality (which many be very sophisticated) and the policy (which is bound to be relatively simple).
Blocks of functionality are known as functions, and logical parameters can be defined that are then used by the function. The actual function performed may be a class method or interface, which is mapped to the function.
The means by which the policy decision point informs the application of any additional constraints it must apply, is via the use of policy Obligations. An obligation may say "you have permission to access data A if you can confirm you will limit access to that data via functionality B with parameters P".
In the working example, the application requirement is to be able to limit access to data at different levels of aggregation e.g. CCG, provider, or perhaps residential borough. In addition having accessed data at the level of aggregation, the list of providers at that level may be limited by some other set of relationships.
Thus a policy may state that certain roles can access only certain levels of aggregation, and at those levels can only access certain sources of data according to some attribute of the patient record.A function name would be created and used within the policy. The application must know about all function names that the policy might return in an obligation for the type of request an application makes.
ABAC technical approach
main article : Discovery ABAC language
The standard XACML specifies a language that may be used to implement ABAC. XACML includes a set of grammatical concepts such as policy sets, policies, rules, combination rules, targets, obligations, effects and so on with many and variable sophisticated tokens and functions used to build the policy rules. XACML has its own XML syntax that can be used directly.
XACML is pretty complex, a steep learning curve, and appears fairly bound up with the XML syntax approach to language creation.
DDS follows this standard approach from a conceptual perspective, but simplifies this in three respects:
- It uses a pragmatic JSON profile of ABAC which is part of the common information modelling language.
- Attributes and attribute values are modelled in the common information model's semantic ontology. Thus the role attributes,requests, policies, and response are all using the same ontology. Consequently policies can easily match to role attributes and subsumption testing on attributes may be used. All attributes and their allowable values can be viewed in the IM viewer.
- Instead of using the XACML specific query syntax, the policy rules can be built using the Discovery standard query language, operating on those attributes. As the objects and attributes are all triples, the standard query language (a limited profile of SPARQL with an entailment regime) is used. This then allows the same interpreters to be used on the attributes in the same way as any other query in the information model.