4:05 p.m.
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(a)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(a)redhat.com>
*Sent:* 12 November 2019 02:42
*To:* Sushil Singh <sushil.singh(a)guavus.com>
*Cc:* keycloak-dev <keycloak-dev(a)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#_e...
On Mon, Nov 11, 2019 at 5:56 PM Sushil Singh <sushil.singh(a)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(a)redhat.com>
*Sent:* 12 November 2019 01:58
*To:* Sushil Singh <sushil.singh(a)guavus.com>
*Cc:* keycloak-dev <keycloak-dev(a)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(a)guavus.com>
wrote:
@Pedro Igor Silva <psilva(a)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(a)redhat.com>
*Sent:* 11 November 2019 23:33
*To:* Sushil Singh <sushil.singh(a)guavus.com>; keycloak-dev <
keycloak-dev(a)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(a)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(a)guavus.com>
wrote:
@Pedro Igor Silva <psilva(a)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(a)redhat.com>
*Sent:* Monday, November 11, 2019 10:05:06 PM
*To:* keycloak-dev <keycloak-dev(a)lists.jboss.org>; Sushil Singh <
sushil.singh(a)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(a)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
10:25 a.m.
New subject: 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(a)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(a)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(a)redhat.com>
> *Sent:* 12 November 2019 02:42
> *To:* Sushil Singh <sushil.singh(a)guavus.com>
> *Cc:* keycloak-dev <keycloak-dev(a)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#_e...
>
> On Mon, Nov 11, 2019 at 5:56 PM Sushil Singh <sushil.singh(a)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(a)redhat.com>
> *Sent:* 12 November 2019 01:58
> *To:* Sushil Singh <sushil.singh(a)guavus.com>
> *Cc:* keycloak-dev <keycloak-dev(a)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(a)guavus.com>
> wrote:
>
> @Pedro Igor Silva <psilva(a)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(a)redhat.com>
> *Sent:* 11 November 2019 23:33
> *To:* Sushil Singh <sushil.singh(a)guavus.com>; keycloak-dev <
> keycloak-dev(a)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(a)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(a)guavus.com>
> wrote:
>
> @Pedro Igor Silva <psilva(a)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(a)redhat.com>
> *Sent:* Monday, November 11, 2019 10:05:06 PM
> *To:* keycloak-dev <keycloak-dev(a)lists.jboss.org>; Sushil Singh <
> sushil.singh(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:50 a.m.
New subject: Fw: Custom Policy Enforcer
@Stian Thorgersen<mailto:sthorger@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(a)redhat.com>
Sent: 13 November 2019 14:55
To: Pedro Igor Silva <psilva(a)redhat.com>
Cc: Sushil Singh <sushil.singh(a)guavus.com>; keycloak-dev
<keycloak-dev(a)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@redhat.com<mailto:psilva@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@guavus.com<mailto:sushil.singh@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@redhat.com<mailto:psilva@redhat.com>>
*Sent:* 12 November 2019 02:42
*To:* Sushil Singh <sushil.singh@guavus.com<mailto:sushil.singh@guavus.com>>
*Cc:* keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@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#_e...
On Mon, Nov 11, 2019 at 5:56 PM Sushil Singh
<sushil.singh@guavus.com<mailto:sushil.singh@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@redhat.com<mailto:psilva@redhat.com>>
*Sent:* 12 November 2019 01:58
*To:* Sushil Singh <sushil.singh@guavus.com<mailto:sushil.singh@guavus.com>>
*Cc:* keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@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@guavus.com<mailto:sushil.singh@guavus.com>>
wrote:
@Pedro Igor Silva <psilva@redhat.com<mailto:psilva@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@redhat.com<mailto:psilva@redhat.com>>
*Sent:* 11 November 2019 23:33
*To:* Sushil Singh <sushil.singh@guavus.com<mailto:sushil.singh@guavus.com>>;
keycloak-dev <
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@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@redhat.com<mailto:psilva@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@guavus.com<mailto:sushil.singh@guavus.com>>
wrote:
@Pedro Igor Silva <psilva@redhat.com<mailto:psilva@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@redhat.com<mailto:psilva@redhat.com>>
*Sent:* Monday, November 11, 2019 10:05:06 PM
*To:* keycloak-dev
<keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>; Sushil
Singh <
sushil.singh@guavus.com<mailto:sushil.singh@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@guavus.com<mailto:sushil.singh@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1625
days inactive
1627
days old
2 comments
3 participants
participants (3)
-
Pedro Igor Silva -
Stian Thorgersen -
Sushil Singh