Page Comparison

What is a Trust?

• Trust is a grouping of sites

<insert relationship diagram>

Permissions (strict)

What can a Trust admin do in TIS?

Trust administrators need access to TIS data, but only to the data relating to their Trust - they should NOT have access to other TIS data

This is described in specific detail in Admin User Management and summarised below:

• Trust Users should only see own the posts and people (trainees & trainees/ trainers) related to their TrustPeople (current, future, past) <<
• Trust users should be able to see the Placements and Assessments of People they can access
• Trust users should NOT be able to see the sensitive data fields of People they can access
• Ideally a Trust's People list will show future and past trainees as well as current (possible to also achieve past/future via reporting, without implementing in TIS)
• For clarity, Trust admins will NOT have access to the TIS Admin section, Programmes, Revalidation & Concerns

Solution Design

<draw into diagram>

The design includes some basic elements:

1. Allocating all Trust administrators to a new role in Keycloak - one role for all Trust admins
2. Linking a Trust Admin to their Trust - initially only one Trust
3. Implementing authorisation following the existing (flawed) model as a tactical solution

...

1. Limiting access to TIS at the top menu level - Trust Admins will only have visibility and access to People and Post L1 menu items (not Programmes, Assessments, Admin)
2. Limiting access to TIS data within People and Post - the List and CRUD for both People and Posts will only show People/Posts relating to the Trust of the Trust Admin
3. Re-implementing authorisation once a new design has been established to provide appropriately secure roles and permissions

Allocating Trust admins to a new Role

We will create a new 'HEE Trust Admin' role in Keycloak, in parallel to the existing roles - Admin User Management

Linking a Trust admin to their Trust

We will create a new table in the Profile service which will contain the relationship between the TIS Username and the Trust ID.

Phase 1

Initially we will create the table and populate manually using scripts

Phase 2

Develop a Trust Admin page(s) within TIS Admin which: (Matt Leech (Unlicensed) to consider design here)

• Search for a Trust by trust name
• Multi-select the Trust admins associated with that Trust (search dropdown of all HEE Trust Admin role members)
• Do we need to show a list of Trusts which have Trust admins assigned to them? Don't need to show a full list of Trusts as only a small % will have admins

Develop a User creation page within TIS Admin:

In order that Trust Admin creation is a streamlined process, we might need to implement the User creation page within TIS Admin which pushes a new user and their Groups and Roles to Keycloak via the API whilst creating in parallel in the Profile service. (this removes the need for the Trust Admin to login a first time to populate the Profile service, before the TIS Admin can link them to a Trust which would make first time login an awkward 2 step process)

Implementing authorisation for Trust Admins

As a purely tactical solution ahead of re-designing a more secure implementation of Roles and Permissions, we will extend the Profile service and common components to write the Trust ID to the User cookie with the existing Roles and Permissions

Limiting access to TIS top menu sections

Implement standard permission constraints for 'HEE Trust Admin' to only People and Posts L1 menu items

Limiting access to TIS records within People and Posts

People

Implement a PersonTrust table linking a PersonID to a TrustID - 1:many (1 Person can be in Many Trusts).

Use the PersonOwner table/solution as a model for this - overnight scripted full update with Placement updates also triggering individual record level updates

Trust ID can be established by navigating through a Person's placement to its Post, to its Site, to its Trust

Extend the Person List endpoint to check whether the TIS user is a Trust Admin and if so retrieve their TrustID

Alternatively would we put the TrustID into browser local storage on logon so it can be checked directly from there in the Front End and passed to the Person List endpoint if present?

The People List endpoint would then return a filtered list of People by joining to the PeopleTrust table on the TrustID

<<check comment about Sites can have a parent SIte or a Trust?>>

We need to design and implement a way to check that a CRUD request from a Trust Admin user can only load existing details of a Person related to that Trust

Posts

Initially we need to performance test retrieving a list of Posts with an extra TrustID filter - navigating from each Post to its Site, then to its Trust

If this isn't performant enough in realtime we will need to explore denormalising the TrustID into the Posts table or a linked table

We need to adapt the Posts List endpoint to enable the TrustID to be provided by the Front End

We need to design and implement a way to check that a CRUD request from a Trust Admin user can only load existing details of a Post related to that Trust

old content below here...

Rules

• all sites have a trust or another site
• Site can be trust and a site
• 1:many site to trust relationship
• Only one main parent of a site

...

• need to build relationship in profile service and securities in TIS
• Deploy permissions into end point for posts & trainees
• Only relevant for current trusts
• Look at how to hook a Trust's Trainers into the People list filter - is their a past/future concept with Trainers?
• Concerns
• Performance challenge by adding new filter (can be checked in half day)
• Can one user be linked to multiple trusts?
• Where do we get the trust information?
• How many trusts do not have people linked? Which ones?
• Changes to URL can bypass permissions controls << security can be built later

...