I am still new to Keycloak and am trying to model our role and permission model. We have a microservice architecture and have the following use case:
A customer can have multiple accounts and each account belongs to exactly one customer. For example:
user1@customerA.com has edit access to defaultAccountCustomerA and view access to premiumAccountCustomerA
How would I model this?
I have had different options that I am not quite sure what the best practice is and how I could model this exactly:
Option 1
Set up scopes for every account.
I would then have something like this => scope: customerA:defaultAccount:edit customerA:premiumAccount:view. However I feel like the number of scopes becomes unmaintainable very soon.
Option 2
Set up hierarchical groups such as described here: Keycloak authorization: Adding a Role to a domain object or an entity
I could have my groups defined hierarchically and expose the group membership through the JWT token such that:
user1@customerA.com is a member of /customerA/defaultAccount and /customerA/premiumAccount
I could also go one level further and add the group /customerA/defaultAccount/edit and /customerA/premiumAccount/view.
However I feel like I am misusing groups and I have to parse the group_membership from the JWT token in my services manually.
Also the number of Groups is also quite big as the number of accounts increases as I would have at least the view and edit group per account. (Should I use the keycloak admin sdk and create the groups programatically for that?)
Option 3
Work with permissions in keycloak.
How would I model this?
Should I create a resource for /customerA/defaultAccount with the scope view edit or should I create a more fine grained resource such as /customerA/defaultAccount/bills for every resource belonging to one customer?
How would I manage permissions and policies for this use case?
I created a resource /customerA/defaultAccount and /customerA/premiumAccount and now I am a bit unsure how to proceed and how to map user1@customerA.com to these accounts - should I create roles for user1 such as defaultAccountCustomerA_Viewer and create a permission to /customerA/defaultAccount with the role scope?
This seems like doubling the efforts and still having the same cardinality issue as with the scopes (just as roles)
Can you guys give me pointers on how to model my issue and how to check/authorize this use case in my services?
What I would like to have user1@customerA.com to call http://accountservice.com/accounts and only receive accounts that are relevant for him as the other accounts should be a secret, I would love to filter the accounts to only work with the accounts he has (view)access to. To do this I would require a JWT token containing exactly this information
