...
- 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 AdminRe
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 table in the Profile service which will contain the relationship between the TIS Username and the Trust ID
(Simon suggests suggested Trust Code as unique and know by usersknown 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
...
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
- 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 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
<<check comment about Sites can have a parent SIte or a Trust?>>
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
...
For the Post CRUD endpoints we need to deny the front end access to posts they don't have a link to
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
...
to.
TIS Stories/Tasks
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
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
...