Design authentication and authorization

High level requirements

• Access to each workspace is restricted to a group of users.
• One user can have access to multiple workspaces.
• Support Active Directory scenarios for Conditional Access and Privileged Identity.
• Auditing of auth events on workspace level.
  • Check HIPAA requirements
• A user can either have the role of an workspace owner of the workspace or a researcher of the workspace.
• A user can be a TRE administrator to manage shared services and other aspects that spans workspaces.
• The roles a user have in each workspace will depict what actions can be performed.
• Users who need access to a workspace can originate from multiple organizations.

What we’re not doing

• User and group management - Managing roles/groups and users will initially be managed via Azure Active Directory

[christoferlof]

Few related issues just created to reflect the current direction using Azure AD and app roles. #95 , #96 , #208, #211, #220, #221,

[askew]

I’ve modified the ADDA code to use standard Azure AD rather than Azure AD B2C and that allows it to use an App Role for the global role. With the B2C solution we needed a User Admin role, but with normal AAD we now only need a single Resource Admin role. I’ve also added a Member role as you might want to restrict access to the TRE rather then allow the entire domain.

These a are really simple to handle, you just get the names of the app roles in a Roles claim.

For all other permissions on specific resources (workspaces and services) the app needs to manages these with resource assignments in the database.