4

I am new to the Keycloak framework and after writing my own solution painfully we are hoping to convert to KeyCloak. It seems to be a promising solution but unfortunately lacking self describing documentation. I have gone through the tutorials and the terminology, however, I can not seem to mold a suitable model for my authorization use case through Keycloak concepts. I posted my question! in Keycloak mailing list without any response so I decided to reach out here.

Please consider this use scenario:

  • You provide a SaaS solution for Car Dealerships.
  • Every dealership inherits a set of default roles upon creation e.g. admin, manager, sales, accountant,..)
  • Dealership could add/remove permissions to the default roles.
  • Dealership can define their own custom roles.
  • A dealership has multiple vendors and each vendor has a couple of roles (admin, accountant, vendor)
  • A dealership has numerous departments and each department may have their own roles for that department.
  • Basically you have different roles in different contexts.

In my built-in model, I have a table that connects a Role to a Principal (an entity) and the ACLs (or permissions) are assigned to the roles. The Principal could be any of "DealershipA", "DealershipB", "Vendor1" "Department0".

Now my questions is: What is the best practice to implement this scenario in Keycloak.

  • How would you add/assign a role to an entity?
  • Would you consider a Dealership, Vendor or a Department a Resource?

Thank you in advance for all your help,

Arash
  • 121
  • 3

1 Answers1

2

IIUC this scenario could be achieved with different approaches, based on the level of KeyCloak integration you want to do. Let me try to articulate one such way. This could most probably be suboptimal, however you could probably use it as a starting point.

As a start, the Dealership could be considered as a tenant separator, so users in a single Dealership could be gathered to a KeyCloak Realm 1. A Realm groups users together and it sounds like a Dealership is a such separator (if users are indeed allowed to have access to different Dealerships through the same user profile, then this separation cannot be applied).

On to Roles, in one approach each Dealership, Vendor, Department role (admin, sales, acct etc) could be a Realm Role 2. These are Roles available to users in a specific Dealership. However I can't think of a KeyCloak native way to differentiate between Dealership roles vs Vendor roles vs Department roles. These could be differentiated through a naming standard perhaps (ex: vendor-admin)?

In another approach, each entity (Dealership, Vendor, Department) could also be a Group with own attributes and Roles [3]. One advantage could be that the relationship between the entities could be replicated in Group-Subgroup relationship. sample-group-hierarchy attributes-of-a-dept-group

This could give you a start on modeling the entities inside KeyCloak.

In authorization, it looks like you will be able to use the Authorization Services available in KeyCloak [4]. I haven't personally used this feature but if you want to rely on KeyCloak as the PAP, PDP and the PEP [5] this looks like the way to go.

For an example, users can be granted or denied access to resources on a specific vendor or department, since user information contains the user's group relationship. This seems like something achievable with a Group based Policy [6].

To give a more direct answer to the questions,

  1. User creation process should make sure proper Role and (or) Group associations are made

  2. Resources seem to be the services offered by each entity type (ex: add_vendor(), view_accounts())

Hope this helps to get a design going. Since most details are not clear at this moment, the design will have to be redone based on future requirements, but at least with a model to validate against you will be able to do it better.

1 - https://www.keycloak.org/docs/6.0/server_admin/#core-concepts-and-terms#realms

2 - https://www.keycloak.org/docs/6.0/server_admin/#realm-roles

[3] - https://www.keycloak.org/docs/6.0/server_admin/#groups

[4] - https://www.keycloak.org/docs/5.0/authorization_services/

[5] - https://www.keycloak.org/docs/5.0/authorization_services/#_overview_architecture

[6] - https://www.keycloak.org/docs/5.0/authorization_services/#_policy_group

chamilad
  • 1,619
  • 3
  • 23
  • 40