Page Comparison

...

This is described in specific detail in Admin User Management (roles and permissions) and summarised repeated below:

...

• can view/edit People limited to Trainees and Trainers 'related' to their Trust - (Trainee → All Placements → Sites → Trusts)
• can view/edit the People L3 tabs containing Personal Details, Placements and Programme Memberships, Sensitive Data (the 4 actual Sensitive Data fields are hidden)
• cannot view/edit the People L3 tabs containing Qualifications or Assessments
• can view only / not edit Posts, limited to posts 'related' to their Trust (Post → Site → Trust)
• can view only / not edit all Programmes.
• For clarity, HEE Trust Admins will NOT have access to the TIS Admin section

...

• , Revalidation & Concerns
• For clarity, as the Trainee 'related' to their Trust includes 'All' Placements, historical and future, the HEE Trust Admin will see Trainees across a range of Local Offices.

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 TrustImplementing authorisation following the existing (flawed) model as a tactical solution
3. Limiting access to TIS at the top menu level - Trust Admins will only have visibility and access to People, Post and Post Programmes L1 menu items (not Programmes, Assessments, Admin)
4. Limiting access to Sensitive data fields within the Sensitive data L2 menu in People - Trust Admins won't see the four sensitive data fields in People records
5. 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(s) of the Trust Admin
6. ReRead Only access to Programmes and Posts, Read/Write access to all data visible in all People L2 tabs

We will return to 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 (roles and permissions)

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

(Simon suggested Trust Code as unique and known by users or retrieval from TIS easily - which whilst initially we script the additions would potentially make it easier. Think it should be TrustID for consistency - need to examine how we'll specify trust users for Phase 1)

Phase 1

Initially we will create the table and populate manually using scripts

...

As a purely tactical solution ahead of re-designing a more secure implementation of Roles and Permissions, we will extend use the existing solution with the Profile service and common components front end session code to write the Trust ID Admin role to the User cookie with the existing Roles and Permissions - no change should be required here.

Limiting access to TIS top menu sections

Implement standard permission constraints for in the Front End cfor 'HEE Trust Admin' to only People and Posts L1 menu items. This role should also NOT be able to see sensitive data.

Limiting access to Sensitive Data Fields

Implement standard permission constraints in the Front End to limit 'HEE Trust Admin' role to not see the 4 Sensitive Data fields that are already hidden from standard HEE Admins

Limiting access to TIS records within People and Posts

People

Implement a PersonTrust table linking Trust ID can be established by navigating through a Person's Placements to its Post, to its Site, to its Trust. Because we expect this to be too slow to perform in real time, we're suggesting 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

1. Overnight scripted full update

...

1. to rebuild the table for all People
2. 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

...

1. to this table

Note: each Person's can have multiple placements - each will generate a TrustID entry, so a person will have multiple Trusts

For all People endpoints - List and CRUD - when checking the logged in users authorisation against the profile service - if the user is a Trust Admin and if so retrieve their TrustIDAlternatively 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?, retrieve their Trust ID (change to profile service and how its called?)

The People List endpoint would then return a filtered list of apply an extra parameter on the select to further filter the returned 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 TrustThe people CRUD endpoints will validate that the person record being acted on is linked to the TrustID and accessible to the Trust Admin, if not return a permission error to the Front End

Posts

Initially we need to performance test retrieving a list of Posts with an extra TrustID filter element to the SQL query - 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

Requirements

• link TIS user to Trusts and build management of table
• Develop add hard filters in TIS
• Add permissions & roles to key cloak

Discussion

...

Similarly to People, we then need to obtain the Trust ID from the profile service during authorisation if the user is a Trust Admin

For the Post List we need to limit the results returned against any search or filter to those related to the Trust using the logic Post-Site-Trust

For the Post CRUD endpoints we need to deny the front end access to posts they don't have a link to.

TIS Stories/Tasks

Discussion

• 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

Timing

...