Re: [keycloak-dev] [Improvment Request] Add context for an permission requests

Hi, I'd like to join the discussion. What do you think about such improvement? For me it seems to be a approach when domain can't be modeled in a simple way through use of resources and scopes or if the policies should be based on additional context that changes dynamically. My main concern is that such "context" that is part of "permissions" in JWT token isn't standard at all so we are extending the RPT token with custom fields. Bottom line is that this isn't compatible with UMA standard. Nonetheless, it seems to be useful. What do you think about this approach? Regards, Dariusz Chrząścik 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ń _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev CONFIDENTIALITY NOTICE ------------------------------------ This E-mail is intended only to be read or used by the addressee. The information contained in this E-mail message may be confidential information. If you are not the intended recipient, any use, interference with, distribution, disclosure or copying of this material is unauthorized and prohibited. Confidentiality attached to this communication is not waived or lost by reason of the mistaken delivery to you. If you have received this message in error, please delete it and notify us by return E-mail or telephone NOVOMATIC Technologies Poland S.A. +48 12 258 00 50. Any E-mail attachment may contain software viruses which could damage your own computer system. Whilst reasonable precaution has been taken to minimize this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening any attachments. ------------------------------------ NOVOMATIC Technologies Poland S.A., Poland, Krakowska 368, 32-080 Zabierzów