Narrative

Keycloak provides very course grained control for permissions in the Admin API/UI through roles like view-clients and manage-clients. For smaller deployments this is usually perfectly fine, but for larger deployments this all or nothing permissions approach is not suitable resulting in too broad permissions being granted. Typically in a larger deployment a manager should only be able to manage specific users, and not all users, as well as only be able to grant certain groups or roles to users. Similarly a group of developers should only have permissions to update clients associated with the applications they are responsible for, and not all clients.

A general term for this is least privilege access where users are only granted the minimum permissions needed to complete their required tasks.

Frequently in a fine-grained admin permissions use-case there are multiple personas involved;

1. Resource creator
2. Permissions manager
3. Delegated resource administrator

This has implications on the UX around fine-grained admin permissions, as the permissions manager would benefit from centrally managing permissions. This is provided by authorization services. However, fine-grained admin permissions does not leverage authorization services very well from this regard, and instead to set up permissions one is required to navigate around to the different resources, without any good centralized view or control of permissions.

One important aspect of fine-grained admin permissions is that it is difficult to define a MVP based on use-cases. Typically, with fine-grained authorization there is a very wide set of requirements, and the feature needs to be very flexible (quite like a Swiss army knife with loads of attachments).

Fine-grained admin permissions was introduced as a tech-preview feature in Keycloak for a long time ago to solve this problem. However, the feature has remained as a tech preview feature for a long time, making it unsupported in production environments.

Value Proposition

By making fine-grained admin permissions feature supported it will be possible to follow least privilege access principals when providing access to Admin APIs and UIs to users. Significantly reducing the risks associated with granting admin permissions to users.

Acceptance Criteria

• The team should build a good understanding of the feature; how to use it, as well as how to maintain it in the future
• Review and create an inventory of current capabilities in the fine-grained admin permissions feature
• Define a set of common use-cases for fine-grained admin permissions, and access the viability of using the current implementation to solve these use-cases
• Common use-cases should be simple to achieve, but the implementation needs to be flexible and support more advanced (and potentially undefined use-cases), some consideration should still be made in terms of not supporting completely unnecessary capabilities as these leads to higher security risks, worse usability, and higher maintenance costs
• Do a thorough review of the current implementation from a security perspective, including defining a threat model
• Review usability, including documentation, to identify if the feature can be made easier and more straightforward to use
• Focus on the central permissions management scenario required by a permissions manager
• Review and make sure there are no important open or unidentified bugs, including review of test cases for the feature
• Review and make sure the Admin UI works as expected with fine-grained admin permissions
• Make the feature fully supported