Identity Authentication Authorisation - Revision history

DavidStables: /* User session role and role attributes */

2020-08-06T12:38:07Z

User session role and role attributes

← Older revision		Revision as of 12:38, 6 August 2020
Line 128:		Line 128:
	The architectural difference in implementation is significant.		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.		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, a policy enforcement point (PEP) ~~is first accessed, often by intercepting an API~~. The PEP ~~sends a~~ request to ~~a policy~~ decision point (PDP)~~which then identifies~~ the policies relevant to the request~~, processes~~ the ~~policy rules using attributes from~~ the ~~user~~'~~s role~~, ~~and tests them against a set~~ of ~~attributes that~~ the ~~policy requires, and then issues a response~~.		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.		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.
Line 136:		Line 149:
	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.		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.

	=== ~~Job role~~, ~~organisation, project assignment, as attributes~~ ===		=== User, roles and sessions ===
	~~Roles~~ may ~~have an attribute~~ with ~~some form~~ of user ~~type ontology as its value e~~.~~g a role may~~ have a ~~role attribute that tends to indicate their job~~. This makes it easier to identify the role of a person simply by reading the job role~~. An example may be a Professor or Research assistant or a General Practice manager~~.		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.

	The main advantage of having a job role 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.		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.

	~~Because DDS access~~ is ~~based around~~ a ~~publisher subscriber model derived from organisations, 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~~).		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 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 ~~configuration.~~		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

	== Functional authorisation - Obligations ==		== Functional authorisation - Obligations ==
Line 159:		Line 182:

	== ABAC technical approach ==		== ABAC technical approach ==
			''main article :'' [[Discovery ABAC language]]

	The standard [[wikipedia:XACML\|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.		The standard [[wikipedia:XACML\|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.		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 ~~two~~ respects:		DDS follows this standard approach from a conceptual perspective, but simplifies this in three respects:

	# I uses a JSON profile of ABAC which is part of the common information modelling language.		# 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.		#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.		# 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.
Line 171:		Line 196:
	In other words, the [[Discovery ABAC language]] is used to represent role attributes, policies, requests, and responses and that language is part of the [[Information modelling language\|Discovery information modelling language]]		In other words, the [[Discovery ABAC language]] is used to represent role attributes, policies, requests, and responses and that language is part of the [[Information modelling language\|Discovery information modelling language]]

	~~=== User session role and role attributes ===~~		<br />
	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 . The user's session role has a set of attributes which describe the user in more detail.

	It should be noted that in ABAC, unlike RBAC, the attributes do not themselves necessarily imply permissions. Instead, the attributes describe the user in context so that a policy can test whether the user's attributes are of the right level to access the resource or perform an action on it.

	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.

DavidStables: /* User session role and role attributes */

2020-08-06T12:20:44Z

User session role and role attributes

@@ Line 174: / Line 174: @@
 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 . The user's session role has a set of attributes which describe the user in more detail.
-It should be noted that in ABAC, unlike RBAC, the attributes do not themselves necessarily indicate permissions. Instead, the attributes describe the user so that a policy can test whether the user's attributes are of the right level to access the resource or perform an action on it.
+It should be noted that in ABAC, unlike RBAC, the attributes do not themselves necessarily imply permissions. Instead, the attributes describe the user in context so that a policy can test whether the user's attributes are of the right level to access the resource or perform an action on it.
-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 session role,  as many policies may require a user to be authenticated by 2 factors. 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. <div class="toccolours mw-collapsible mw-collapsed">
+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.

DavidStables: /* User session role and role attributes */

2020-08-06T12:19:20Z

User session role and role attributes

Show changes

DavidStables: /* ABAC technical approach */

2020-08-04T08:08:12Z

ABAC technical approach

← Older revision		Revision as of 08:08, 4 August 2020
Line 169:		Line 169:
	# 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.		# 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.

	In other words, the [[Discovery ABAC language]] is used to represent role attributes, policies, requests, and responses and that language is part of the [[Discovery ~~common~~ information modelling language]]		In other words, the [[Discovery ABAC language]] is used to represent role attributes, policies, requests, and responses and that language is part of the [[Information modelling language\|Discovery information modelling language]]

	=== User session role and role attributes ===		=== User session role and role attributes ===

DavidStables: /* ABAC technical approach */

2020-08-04T08:06:22Z

ABAC technical approach

← Older revision		Revision as of 08:06, 4 August 2020
Line 159:		Line 159:

	== ABAC technical approach ==		== ABAC technical approach ==
	The standard [[wikipedia:XACML\|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~~, attribute designators~~, 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.		The standard [[wikipedia:XACML\|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 two respects:		DDS follows this standard approach from a conceptual perspective but simplifies this in two respects:

	# Attributes and attribute values are modelled in the common information model's semantic ontology. Thus the requests, policies, and ~~responses~~ are all using the same ontology. Consequently subsumption testing on attributes may be used ~~on object property values~~. All attributes and their allowable values can be viewed in the IM viewer~~. Role based attributes can be modelled and presented in the Discovery JSON syntax or one of the standard OWL2 syntaxes~~.		# I uses a JSON profile of ABAC which is part of the common information modelling language.
	# Instead of using the XACML specific query syntax, the policy rules can be built using the Discovery standard query language, operating on those attributes. ~~The~~ standard query language is a profile of SPARQL with entailment regime ~~in place~~. This then allows the same interpreters to be used on the attributes in the same way as any other query in the information model. ~~<br />~~		#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.

			In other words, the [[Discovery ABAC language]] is used to represent role attributes, policies, requests, and responses and that language is part of the [[Discovery common information modelling language]]

	=== User session role and role attributes ===		=== User session role and role attributes ===

DavidStables: /* Working example */

2020-08-04T07:58:11Z

Working example

DavidStables: /* Response */

2020-08-04T07:50:06Z

Response

← Older revision		Revision as of 07:50, 4 August 2020
Line 285:		Line 285:
	}		}
	}		}
	<syntaxhighlight></div></div>		</syntaxhighlight></div></div>

	=== Example 2 - Practice level and Drill down allowed ===		=== Example 2 - Practice level and Drill down allowed ===

DavidStables: /* Roles and authorisation- RBAC and ABAC */

2020-08-04T05:35:02Z

Roles and authorisation- RBAC and ABAC

← Older revision		Revision as of 05:35, 4 August 2020
Line 130:		Line 130:
	In RBAC the application, using the session state of the user’s role, determines whether an action can be performed.		In RBAC the application, using the session state of the user’s role, determines whether an action can be performed.

	In ABAC, a policy enforcement point (PEP) is first accessed by intercepting ~~the~~ API. The PEP sends a request to a policy decision point (~~which may be remote~~) which then identifies policies relevant to the request, ~~and~~ processes rules using attributes from the user's role ~~(which it independently accesses)~~ , and tests them against a set of attributes that the policy requires, and then issues a response.		In ABAC, a policy enforcement point (PEP) is first accessed, often by intercepting an API. The PEP sends a request to a policy decision point (PDP)which then identifies the policies relevant to the request, processes the policy rules using attributes from the user's role, and tests them against a set of attributes that the policy requires, and then issues a response.

	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.		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.		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.

	=== Job role, organisation, project assignment, as attributes ===		=== Job role, organisation, project assignment, as attributes ===
	~~roles are modelled as having~~ an ~~'has role'~~ attribute with some form of user type ontology as ~~values.i.~~e. ~~most roles will~~ have a role attribute that tends to indicate their job. This makes it easier to identify the role of a person simply by reading the job role. An example may be a Professor or Research assistant or a General Practice manager.		Roles may have an attribute with some form of user type ontology as its value e.g a role may have a role attribute that tends to indicate their job. This makes it easier to identify the role of a person simply by reading the job role. An example may be a Professor or Research assistant or a General Practice manager.

	The main advantage of having a job role 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. Thus attributes and values could be either inherited from (or copied from) the default template		The main advantage of having a job role 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.

	Because DDS access is based around a publisher subscriber model derived from organisations, 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 is a subscriber to data X) and also in any advanced ABAC rule ( can only see sensitive date ~~fro~~ their own organisation).		Because DDS access is based around a publisher subscriber model derived from organisations, 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 configuration.		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 configuration.

DavidStables: /* Users roles and authentication levels */

2020-08-04T05:25:06Z

Users roles and authentication levels

← Older revision		Revision as of 05:25, 4 August 2020
Line 120:		Line 120:
	Users who log on with self created accounts have the simplest of roles and normally require only single factor authentication.		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 ~~occurred~~.		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.

	== Roles and authorisation- RBAC and ABAC ==		== Roles and authorisation- RBAC and ABAC ==

DavidStables: /* Working example */

2020-08-04T05:23:36Z

Working example

← Older revision		Revision as of 05:23, 4 August 2020
Line 78:		Line 78:
	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 a 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.		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 a 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 now ~~sees she can~~ see practice level aggregate information. However, she can only see practice level information for practices in Cumbria.		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?'''		'''What are the characteristics of patients with AF who are not anticoagulated?'''

← Older revision		Revision as of 07:58, 4 August 2020
Line 62:		Line 62:
	'''Starting out, whats available to see?'''		'''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 ~~and~~ browsing the information model.		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- Specification\|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.		She clicks on the dashboard URL which brings up [[Discovery Explorer- Specification\|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 ~~or on to~~ the public dashboards. Explorer also shows her name and the fact that she has a role of 'General public'.		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 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.		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?'''		'''How are my practices doing?'''
Line 76:		Line 76:
	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.		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 a 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.		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.		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.
Line 84:		Line 84:
	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.		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 ~~that~~ has a data sharing agreement with Cumbrian providers to ~~view~~ patient level de-identified data, via Muncaster University’s secure data lake.		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 ~~then~~ states that this is her default role. She 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 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 ~~here~~ that her level of authentication is currently insufficient to use Discovery Analyser. 2 factor authentication is required. 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.		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.		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.
Line 98:		Line 98:
	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.		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~~.		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, 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.		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 ==		== User accounts across DDS ==