[keycloak-dev] Custom Policy Enforcer
Pedro Igor Silva
psilva at redhat.com
Thu Nov 28 07:43:27 EST 2019
Thanks, Sushil. I'll check it out until the week ends.
On Thu, Nov 28, 2019 at 5:40 AM Sushil Singh <Sushil.Singh at thalesgroup.com>
wrote:
> Hi ,
>
> I have tried to create a custom-enforcer-quick-start
>
>
> https://github.com/sushil-singh-guavus/keycloak-quickstarts/tree/keycloak-11300-quickstarts
>
> https://github.com/sushil-singh-guavus/keycloak/tree/keycloak-11300
>
> @Pedro Igor Silva <psilva at redhat.com>, I have made some changes from
> https://github.com/pedroigor/keycloak/tree/KEYCLOAK-11300 as pathconfig
> was always coming null if resource is independent of URI requested , so I
> have done some fixes and written a naive quick-start using my keycloak
> build. I haven't yet written the test case for quick-start
>
> Can you please check it and give any valuable feedback . I am really
> Sorry for the delay as i was preoccupied with other tasks
>
> Thanks
>
> Sushil
>
>
> ------------------------------
> *From:* Sushil Singh <sushil.singh at guavus.com>
> *Sent:* 14 November 2019 12:20
> *To:* keycloak-dev <keycloak-dev at lists.jboss.org>; Stian Thorgersen <
> notifications at github.com>; Pedro Igor Silva <psilva at redhat.com>
> *Subject:* Fw: [keycloak-dev] Custom Policy Enforcer
>
> @Stian Thorgersen <sthorger at redhat.com>
>
> Here is the discussion we had 2 days ago when i was not on dev-mailing
> list.
>
> Pedro has suggested changes in
> https://github.com/pedroigor/keycloak/tree/KEYCLOAK-11300 where all the
> changes are in adapter-core , so all the java adapters can anyway get it (*not
> only spring/springboot)*
>
> Actually some changes are not working , so i am correcting them and will
> come out with a quickstart in next few days
>
> ------------------------------
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *Sent:* 13 November 2019 14:55
> *To:* Pedro Igor Silva <psilva at redhat.com>
> *Cc:* Sushil Singh <sushil.singh at guavus.com>; keycloak-dev <
> keycloak-dev at lists.jboss.org>
> *Subject:* Re: [keycloak-dev] Custom Policy Enforcer
>
> Missing a bit of context here and missing Sushil's responses as he's not
> on the ML.
>
> I'd like to see an example/quickstart for this as looking at the PR I
> think I get the gist of what the problem is, but not quite sure how it
> would be used. The PR also only focuses on Spring Security, but we'd need
> to have this capability in all JEE adapters, then there's also Node.js to
> consider as that should be consistent as well. We'd also need to test this.
>
> My biggest question is how unique is this use-case? If it's rather unique
> and not generic then I don't think it's worth adding it, especially not
> considering that we need all authz services extensions to support the same
> capabilities.
>
>
>
> On Tue, 12 Nov 2019 at 17:04, Pedro Igor Silva <psilva at redhat.com> wrote:
>
> Yes, exactly ... So you just leverage what we already have in order to
> expose "manual enforcement" by wrapping the call to the PE (which is the
> one that creates the AC anyways).
>
> On Mon, Nov 11, 2019 at 6:54 PM Sushil Singh <sushil.singh at guavus.com>
> wrote:
>
> > AuthorizationContext authzContext =
> > keycloakSecurityContext.getAuthorizationContext();
> >
> > AdapterAuthorizationContext clientContext =
> AdapterAuthorizationContext.class.cast(, );
> >
> > clientContext.authorize(Map);
> >
> >
> > I think this is the way , i will invoke it programatically.
> >
> > yeah i can write a simple quick-start , i will do it by tomorrow or day
> > after tomorrow and then we can discuss further
> > ------------------------------
> > *From:* Pedro Igor Silva <psilva at redhat.com>
> > *Sent:* 12 November 2019 02:42
> > *To:* Sushil Singh <sushil.singh at guavus.com>
> > *Cc:* keycloak-dev <keycloak-dev at lists.jboss.org>
> > *Subject:* Re: Custom Policy Enforcer
> >
> > 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
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
More information about the keycloak-dev
mailing list