[keycloak-dev] [Improvment Request] Add context for an permission requests
Tomek
thom.nocon at gmail.com
Thu Dec 7 10:04:15 EST 2017
Hello guys,
we would like to propose an improvment that can be added to the *Entitlment
API*. This topic was already opened in this mail: link
<http://lists.jboss.org/pipermail/keycloak-user/2017-February/009391.html>.
The main purpose of this improvment is to add an optional contextual data
for an permission requests.
Let's take into account an examle bussines case: evaluate permission to
orders in the context of specific shops. Those shops can be added to
the *Keycloak
*as a specific resources or scopes inside the *Order* resource. In our
point of view this is an overhead when we must synchronize all shops from
DB with *Keycloak*.
We have prepared a simple improvment. Here is an example of entitlment
request:
*POST /auth/realms/{realmName}/authz/entitlement/{clientName}*
*{*
* "permissions": [*
* {*
* "resource_set_name": "Orders Resource",*
* "context": {*
* "shops": ["shop1", "shop2"]*
* }*
* },*
* {*
* "resource_set_name": "Shop Resource"*
* }*
* ]*
*}*
The *context* is a map: *Map<String, Collection<String>> *and it could be
injected to the *Attributes* inside the *EvaluationContext* class before
policy evaluation.
The result of this request is an *RPT* token that also contains the
contextual data, so it can be later re-used. An example encoded *RPT* token:
*{*
*.....*
* "authorization": {*
* "permissions": [*
* {*
* "resource_set_id": "76bb1db0-b3c3-47a1-9d06-8f3b98d2ba10",*
* "resource_set_name": "Default Resource",*
* "context": {*
* "shops": ["shop1", "shop2"]*
* }*
* }*
* ]*
* }*
*.....*
*}*
The reason for this improvement is the overhead that arises when we have a
lot of resources to handle and they are added dynamically.
I have already implemented a working proof of concept, that is accessible
in the following link
<https://github.com/nocotom/keycloak/tree/feature/permission-context>.
(the context in the returned *RPT *token is missing, but the input context
is propagated to the policy evaluation)
Is this something *Keycloak *might have implemented?
What you think, guys?
Regards,
Tom Nocoń
More information about the keycloak-dev
mailing list