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

[Dariusz Chrzascik]

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



>>> Tomek <thom.nocon at gmail.com> 12/07/17 5:35 PM >>>
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 at 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