Identity Authentication Authorisation

From Endeavour Knowledge Base
Revision as of 14:29, 30 July 2020 by DavidStables (talk | contribs) (Created page with "'''This version : (0-1 Draft)''' == Abstract == The Discovery Data Service (DDS) enables subscribers and publishers to access data either via the use of web applications, or...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This version : (0-1 Draft)

Abstract

The Discovery Data Service (DDS) enables subscribers and publishers to access data either via the use of web applications, or if accessed via a non Discovery application, via a set of APIs. Subscribers may be systems or people. Publishers are systems. Within the context of this specification, user accounts apply both to people's accounts and system accounts.

User accounts are managed via the user manager and organisation manager utilities. These are provisioned as web based application modules, accessible within broader Discovery applications such as the Data Sharing Manager or Discovery Explorer. Behind the scenes these utilities link to authentication and authorisation servers which support open standard approaches such as Oauth 2.0- enabling API or user access via OpenID Connect.

This document specifies a number of components of these utilities and back end requirements.

Status of this document

This is the first and incomplete draft, focusing on some implementation capabilities required for the release of some utilities. i.e. does not specify account management in total at this stage

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

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.