We need a scheme for mapping users' AAD identities to permissions across data platform, including tools access, catalogue access and role as well as access to the data directly, preferentially stored in AWS but as a stretch, also in Azure or on prem.
Value / Purpose
Before we can implement a proof of concept for permissions management, we need to agree on the process of mapping these permissions to users. Currently, we use a number of approaches, depending on the tool.
Catalogue identities are managed in AzureAD but role assignments are managed locally within the catalogue
Control panel uses a combination of identity providers including Github and hmpps-auth with authorisation information managed in Auth0 and dedicated postgres database.
AWS access is managed in part via roles configured in the Control panel and in part using AWS Identity Center with an Github source of identity.
Useful Contacts
No response
User Types
Devs, DP/AP users, data management personas
Hypothesis
If we are able to implement a unified solution that is simple for people to use and understand, we will improve the overall security posture of the platform as well as disincentive users/owners/operators from granting overly broad permissions to minimise effort.
Proposal
No response
Additional Information
No response
Definition of Done
[ ] Proposal(s) for mapping strategy for user permissions in catalogue, control panel/UI/aws defined
[ ] Liase with Data Engineering to discuss integration of database access repo into the unified permissions management
[ ] Proposal(s) reviewed by team and stakeholders
[ ] Way forward agreed
[ ] Decision documented in the ADR and data platform documentation
User Story
We need a scheme for mapping users' AAD identities to permissions across data platform, including tools access, catalogue access and role as well as access to the data directly, preferentially stored in AWS but as a stretch, also in Azure or on prem.
Value / Purpose
Before we can implement a proof of concept for permissions management, we need to agree on the process of mapping these permissions to users. Currently, we use a number of approaches, depending on the tool.
hmpps-auth
with authorisation information managed in Auth0 and dedicated postgres database.Useful Contacts
No response
User Types
Devs, DP/AP users, data management personas
Hypothesis
If we are able to implement a unified solution that is simple for people to use and understand, we will improve the overall security posture of the platform as well as disincentive users/owners/operators from granting overly broad permissions to minimise effort.
Proposal
No response
Additional Information
No response
Definition of Done