[keycloak-dev] Custom Policy Enforcer

Pedro Igor Silva psilva at redhat.com
Mon Nov 11 16:14:42 EST 2019


Are you able to write a simple quickstart (maybe based on
https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-rest-employee)
so that we can PoC the idea ?

On Mon, Nov 11, 2019 at 6:12 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> You should be able to obtain the context instance like that [1]. And then,
> invoke the method to programmatically enforce access.
>
> If I understand correctly, the permission map you pass is basically the
> set of resource/scopes that you want to return in a permission ticket and
> later on check if the resulting RPT is granted with the same set. We should
> ideally reuse as much as possible the main logic in the enforcer. And the
> enforcement mode should be permissive or disabled to allow the request to
> reach your endpoint so you can enforce access by yourself.
>
> In any case, the PE should allow the request to pass with an empty
> authorization context so that you can invoke the appropriate method to
> enforce access.
>
> [1]
> https://www.keycloak.org/docs/latest/authorization_services/index.html#_enforcer_authorization_context
>
> On Mon, Nov 11, 2019 at 5:56 PM Sushil Singh <sushil.singh at guavus.com>
> wrote:
>
>> Just by looking , changes look good .
>>
>> I have a question , how will I invoke it programatically , I mean on what
>> object i have to call ,  giving permission (Map) as as an input parameter.
>>
>> If I specify enforcement mode as Enforcing or Permissive , permission
>> will always be null
>>
>> Also it will be good if we can incorporate audit logging , if not now
>> then we can consider it in future
>>
>>
>>
>> ------------------------------
>> *From:* Pedro Igor Silva <psilva at redhat.com>
>> *Sent:* 12 November 2019 01:58
>> *To:* Sushil Singh <sushil.singh at guavus.com>
>> *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
>> *Subject:* Re: Custom Policy Enforcer
>>
>> I see. I'm just trying to figure out if we can't somehow address the
>> problem by enhancing the configuration. For instance, in regards to the
>> `/api/datasets/{databasename}` I think we have a similar approach in the
>> Photoz quickstart, where the path parameter representing the ID of the
>> resource is used to automatically create the ticket and enforce access
>> later on when an RPT arrives.
>>
>> But yeah, the other scenarios are not covered.
>>
>> I'm OK to improve this based on your changes and following an approach
>> similar to what I shared from my branch. Does it make sense for you ? I may
>> have removed some bits from your original changes but the idea is just to
>> show how we could leverage the `AuthorizationContext`, which is already
>> available to the application through `KeycloakSecurityContext`.
>>
>> On Mon, Nov 11, 2019 at 4:25 PM Sushil Singh <sushil.singh at guavus.com>
>> wrote:
>>
>> @Pedro Igor Silva <psilva at redhat.com>
>>
>> I want to clarify  little bit about the example you are stating ,
>>
>> {
>>         "path" : "/someUri/*",
>>         "methods" : [
>>           {
>>             "method": "GET",
>>             "scopes" : ["view"]
>>           },
>>           {
>>             "method": "DELETE",
>>             "scopes" : ["delete"]
>>           }
>>         ]
>>       },
>>
>> See , if our resources are static and not dynamic , I can put them in a
>> keycloak.json file no worries.
>>  But when it comes to resources which are not end-point specific or not
>> directly related to endpoint , but the actual data itself. I think it is
>> better to keep them on server side rather than a config file . It can be
>> 1000 at present , it can be lakhs and crores if i consider the future scope
>>
>> for eg-: /api/datasets/{datasetname} , each dataset will be resource and
>> we will be configuring resources as /datasets/dataset1
>> /datasets/dataset2
>>
>> So, each dataset will be a resource and will be created in keycloak
>> server when the actual Data is created. So , every time i create a resource
>> , i won't require to configure keycloak.json.
>>
>> The current implementation of configuring paths that keycloak provides is
>> good when resources are static. for eg-: if end points are resources , so
>> they are most likely static . But for our case it won't work
>>
>> Another example can be , if there is a non rest resource and scope /
>> action is coming as a query parameter. Current keycloak implementation will
>> not work as we can configure only on URL's . So the customEnforcer will
>> provide the flexibility to cover all these cases.
>>
>> There are other cases , where there is a pipeline which is dependent on
>> another resources.
>>
>> So let's consider Non Rest resource such as PIPELINE , A pipeline itself
>> will contain a set of resources , So Pipeline can have a scope START, STOP
>> , DELETE , RESTART etc.
>> So resources and actions can come as a query parameter . So , the
>> custom-enforcer functionality can provide us enforcing policies with use
>> cases like that
>>
>> Hope the use case is getting more clearer to you
>>
>> Thanks
>>
>> Sushil Pratap Singh
>>
>> ------------------------------
>> *From:* Pedro Igor Silva <psilva at redhat.com>
>> *Sent:* 11 November 2019 23:33
>> *To:* Sushil Singh <sushil.singh at guavus.com>; keycloak-dev <
>> keycloak-dev at lists.jboss.org>
>> *Subject:* Re: Custom Policy Enforcer
>>
>> Here is a scratch [1]. But I'm not fully convinced about the changes you
>> are proposing. Maybe what is missing is an example of how this will be used
>> in practice.
>>
>> Isn't that the same thing as configuring a path like this?
>>
>> ```
>> {
>>         "path" : "/someUri/*",
>>         "methods" : [
>>           {
>>             "method": "GET",
>>             "scopes" : ["view"]
>>           },
>>           {
>>             "method": "DELETE",
>>             "scopes" : ["delete"]
>>           }
>>         ]
>>       },
>> ```
>>
>> [1] https://github.com/pedroigor/keycloak/tree/KEYCLOAK-11300
>>
>> On Mon, Nov 11, 2019 at 1:44 PM Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>> OK. I'm going to write something and give to you ...
>>
>> On Mon, Nov 11, 2019 at 1:41 PM Sushil Singh <sushil.singh at guavus.com>
>> wrote:
>>
>> @Pedro Igor Silva <psilva at redhat.com>
>>
>> Can you suggest pseudo flow what you are trying to say
>>
>> It will be good for me to understand how it can be achieved using
>> AuthorizationContext .
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>> ------------------------------
>> *From:* Pedro Igor Silva <psilva at redhat.com>
>> *Sent:* Monday, November 11, 2019 10:05:06 PM
>> *To:* keycloak-dev <keycloak-dev at lists.jboss.org>; Sushil Singh <
>> sushil.singh at guavus.com>
>> *Subject:* Custom Policy Enforcer
>>
>> Hi,
>>
>> We have started some discussions about a custom policy enforcer at
>> https://github.com/keycloak/keycloak/pull/6448.
>>
>> For those interested in how to programmatically enforce permissions,
>> please look at that PR and discussions that should start to happen here.
>>
>> @Sushil Singh <sushil.singh at guavus.com>, If the idea is to expose the PE
>> functionality so that you can programmatically get the same behavior to
>> when requests are processed, I think we can still make it through the
>> `AuthorizationContex` interface.
>>
>> In fact, the code won't change much from what you did so we basically
>> encapsulate the call to the actual policy enforcer.
>>
>> Regards.
>> Pedro Igor
>>
>>


More information about the keycloak-dev mailing list