What is a Trust?
- Trust is a grouping of sites
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 the posts and people (trainees & trainers) related to their Trust
- 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:
- Allocating all Trust administrators to a new role in Keycloak - one role for all Trust admins
- Linking a Trust Admin to their Trust - initially only one Trust
- Implementing authorisation following the existing (flawed) model as a tactical solution
- 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)
- 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
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
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
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 use the existing solution with the Profile service front end session code to write the Trust 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 'HEE Trust Admin' to only People and Posts L1 menu items
Limiting access to TIS records within People and Posts
People
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 scripted full update to rebuild the table for all People
- Placement updates also triggering individual record level updates 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, retrieve their Trust ID (change to profile service and how its called?)
The People List endpoint would then apply an extra parameter on the select to further filter the returned People by joining to the PeopleTrust table on the TrustID
The 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 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
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
Add Comment