Design authentication and authorization

[christoferlof]

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

[iankelly-github]

We need to be very clear and consistent using the 'labels' we create for roles. We should avoid using 'a user' references if we have defined roles.

[iankelly-github]

I question if we can actually specify a 'TRE Administrator' role, and if access to a workspace can be managed across organisations? It sounds like these are outside of our scope. I think our environment plugs in to the existing AAD, and there will typically be standard operating procedures and self-service tools in place to manage this.

[christoferlof]

@iankelly-github , Yep, we will require an existing Azure AD and at this point we envision that cross organizational use will rely on AAD guest/b2b features where a researcher from another org needs to be invited to the AAD of the org owning the AzTRE instance. We are not planning to build any "user management" type of features at this moment.
Roles will most likely be implemented with AAD application level roles.

[christoferlof]

@marrobi @Lybecker @askew , I suggest we spend some time on this shortly to decide on the approach. Additional impl tasks moved to backlog until the high-level design is in place.

[marrobi]

@christoferlof @Lybecker @askew based on #158 , putting some thoughts down.

Role Definitions

Key	Value description
id	A unique role id.
name	Role Name.
permissions	Granted permissions.

Permissions

Key	Value description
WorkspaceWrite	Permission to write a workspace.
WorkspaceRead	Permission to read a workspace.
WorkspaceDelete	Permission to delete a workspace.
WorkspaceCreateService	Permission to create a service.
WorkspaceUserRead	Permission to read workspace users.
WorkspaceUserManage	Permission to manage workspace users.
ServiceRead	Permission to read a service.
ServiceWrite	Permission to write a service.
ServiceDelete	Permission to delete a service.

Resource assignment

Key	Value description
id	A unique assignment id.
claim	claim name
claimValue	claim value
resourceId	Resource id.
role	Granted role

For Azure AD in the initial iteration we use, claim = group (or could even be claim =user)

It's then down to the UI implementation (or could do within TF) to add the appropriate values when creating a workspace.

Then if wanted to add another id provider down the line it shouldn't be too difficult.

[christoferlof]

As noted previously, for roles/groups from Idp we have 2 options with Azure AD:

1. use approles - will require one app registration per workspace since role assignments are per workspace. Alternatively create some sort of naming convention on role to include workspace id also.
2. use ad groups (can be translated into role claim).

The immediate challenge with requesting ad groups is the potential number of groups a user can be a member of. There's a limit and AD will not create tokens containing > 200 groups. In those cases, an hasgroups claim will be issued to indicate that the graph endpoint needs to be used to retrieve the groups for the user. I expect other idps/token servers to behave similarly why we should expect to have a way of handling token responses per idp type to allow for additional processing and queries to take place.

[Lybecker]

App Roles:

• I've tested. We can modify an existing App Role registration and assign the new role to a user.
• To be able to assign Security Groups to an App Role requires AAD Premium.

AD Groups:

• To overcome the >200 groups in claims system can query Microsoft Graph. It is more work, but the way to overcome the challenge.

[marrobi]

@Lybecker agree, the demo I use uses app roles, also worth noting, Azure AD can be configured to only returned groups associated with the roles reducing the group count. I've not tested to see at what point need to query the userinfo endpoint for groups not returned in the token.

Only the people needing to do the group assignments needs a premium license, so don't see it as a blocker.

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

[christoferlof]

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

[christoferlof]

We will use a multi-app-registration approach with Azure AD, giving the flexibility of enforcing roles and features such as conditional access on a per workspace basis. Clients will have to handle multiple tokens for TRE vs Workspace operations

Issue #236 to describe this in more detail.