little-megabyte-1074
fierce-student-84107
03/21/2023, 7:51 PMfierce-student-84107
03/21/2023, 9:34 PMAuthenticationFilter
-> doFilter
we derive these tenant information from received tokens using getClaims
. A newly defined object TenantContext
(which is also a ThreadLocal) holds tenant information derived and gets bundled with AuthenticationRequest
context. With this context passed, the tenant information was made available to relevant processing threads.
Disadvantage to this approach:
• We ended up passing tenantId
and tenantDb
to all necessary called routines, so that Data Store can be updated/read.
• Maintenance of this delta code is a challenge for each DataHub version upgrade.
We kind of used similar approach towards GraphQLController
, Kafka etc.
What are your thoughts about above approach? Please let us know if you have any suggestions to overcome the disadvantages mentioned.
Thank you.fierce-student-84107
03/23/2023, 4:40 PMbrainy-tent-14503
04/05/2023, 1:52 PMcorpGroup
fundamental ids should likely include a component for the tenant. The approach above is essentially routing users to data and imho more error prone to exposing data then actually basing the access grants on a tenant scoped unique identifier. The jwt token already includes the user urn and the tenant id is naturally extracted from the urn without modifying the filtering. The application code does have to extract and use the tenant id for data access. That said I am only one voice at Acryl and would need a bit of thought from others like @big-carpet-38439 and @mammoth-bear-12532 here as well.fierce-student-84107
04/05/2023, 4:07 PMquiet-kangaroo-60946
04/25/2023, 6:51 PMsalmon-exabyte-77928
05/03/2023, 5:19 PMbetter-battery-99932
10/09/2023, 3:21 PMbulky-shoe-65107
10/16/2023, 12:44 AM