10:08 p.m.
Hi,
This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
The idea is allow policies to push information to a policy enforcer (PEP)
in order to enrich the final decision if a resource can be accessed or not.
In XACML there is a well known concept called Obligation, which can be used
to pass information to a policy enforcer in order to take some action or
verify something before granting or denying access to a resource.
Suppose you have a JS policy and want to push obligations when evaluating a
permission:
if (someCondition) {
var permission = $evaluation.getPermission();
permission.addObligation('transfer.limit', '200');
}
On the resource server side, you will be able to obtain *transfer.limit*
and check whether a request satisfy the obligation.
Any comments ?
Regards.
Pedro Igor
3:28 p.m.
Pedro - if you are able to use a better term than “obligation”, then you will have success
in adoption.
XACML obligations are least understood and not very well used. I never liked them
unfortunately. :-(
Maybe “condition”,”requirement” or a better term?
Ensure that these are sent from PDP to PEP.
This is an important construct that has a potential to confuse users. In my view, this is
a hack in the enforcement model that xacml tries to solve. *my opinion only*
On Oct 26, 2017, at 3:08 PM, Pedro Igor Silva
<psilva(a)redhat.com> wrote:
Hi,
This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
The idea is allow policies to push information to a policy enforcer (PEP)
in order to enrich the final decision if a resource can be accessed or not.
In XACML there is a well known concept called Obligation, which can be used
to pass information to a policy enforcer in order to take some action or
verify something before granting or denying access to a resource.
Suppose you have a JS policy and want to push obligations when evaluating a
permission:
if (someCondition) {
var permission = $evaluation.getPermission();
permission.addObligation('transfer.limit', '200');
}
On the resource server side, you will be able to obtain *transfer.limit*
and check whether a request satisfy the obligation.
Any comments ?
Regards.
Pedro Igor
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:25 p.m.
Hey Anil, thanks for the feedback.
You are right, obligation is probably not the best term to use here.
I did something already using "claim". Where a *permission claim*
represents assertions of the result of the decision as well a demand or
request from the PDP to PEP.
Sounds better ?
I gave just one example, but we could also use permission claims to, for
instance, force the application to ask user to raise his security level
(using some stronger authentication mechanism/flow).
On Fri, Oct 27, 2017 at 11:28 AM, Anil Saldanha <asaldanha1947(a)gmail.com>
wrote:
Pedro - if you are able to use a better term than “obligation”, then
you
will have success in adoption.
XACML obligations are least understood and not very well used. I never
liked them unfortunately. :-(
Maybe “condition”,”requirement” or a better term?
Ensure that these are sent from PDP to PEP.
This is an important construct that has a potential to confuse users. In
my view, this is a hack in the enforcement model that xacml tries to solve.
*my opinion only*
> On Oct 26, 2017, at 3:08 PM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>
> Hi,
>
> This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
>
> The idea is allow policies to push information to a policy enforcer (PEP)
> in order to enrich the final decision if a resource can be accessed or
not.
>
> In XACML there is a well known concept called Obligation, which can be
used
> to pass information to a policy enforcer in order to take some action or
> verify something before granting or denying access to a resource.
>
> Suppose you have a JS policy and want to push obligations when
evaluating a
> permission:
>
> if (someCondition) {
> var permission = $evaluation.getPermission();
> permission.addObligation('transfer.limit', '200');
> }
>
> On the resource server side, you will be able to obtain *transfer.limit*
> and check whether a request satisfy the obligation.
>
> Any comments ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:55 p.m.
Hi all,
I would argue that "claim" is pretty much used by token claims. Personally, I
like "obligation" as a kind of opposite to "permission".
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer
Kallenbach, Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org]
On Behalf Of Pedro Igor Silva
Sent: Freitag, 27. Oktober 2017 16:26
To: Anil Saldanha <asaldanha1947(a)gmail.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Permission and Obligation
Hey Anil, thanks for the feedback.
You are right, obligation is probably not the best term to use here.
I did something already using "claim". Where a *permission claim* represents
assertions of the result of the decision as well a demand or request from the PDP to PEP.
Sounds better ?
I gave just one example, but we could also use permission claims to, for instance, force
the application to ask user to raise his security level (using some stronger
authentication mechanism/flow).
On Fri, Oct 27, 2017 at 11:28 AM, Anil Saldanha <asaldanha1947(a)gmail.com>
wrote:
Pedro - if you are able to use a better term than “obligation”, then
you will have success in adoption.
XACML obligations are least understood and not very well used. I never
liked them unfortunately. :-(
Maybe “condition”,”requirement” or a better term?
Ensure that these are sent from PDP to PEP.
This is an important construct that has a potential to confuse users.
In my view, this is a hack in the enforcement model that xacml tries to solve.
*my opinion only*
> On Oct 26, 2017, at 3:08 PM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
>
> Hi,
>
> This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
>
> The idea is allow policies to push information to a policy enforcer
> (PEP) in order to enrich the final decision if a resource can be
> accessed or
not.
>
> In XACML there is a well known concept called Obligation, which can
> be
used
> to pass information to a policy enforcer in order to take some
> action or verify something before granting or denying access to a resource.
>
> Suppose you have a JS policy and want to push obligations when
evaluating a
> permission:
>
> if (someCondition) {
> var permission = $evaluation.getPermission();
> permission.addObligation('transfer.limit', '200'); }
>
> On the resource server side, you will be able to obtain
> *transfer.limit* and check whether a request satisfy the obligation.
>
> Any comments ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:05 p.m.
Hi,
I think Anil has a point on the context behind obligation. Someone will
probably ask if we support advice in the future :)
The idea behind a permission claim is that it is also a claim, but related
with the a permission being granted. And its context is pretty much related
with a token: RPT.
A claim should always align with the permission, considering that it is
pushed by policies with additional information on how a resource *should*
be accessed. If PEP is going to respect these claims or not is another
thing :)
On Fri, Oct 27, 2017 at 1:55 PM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Hi all,
I would argue that "claim" is pretty much used by token claims.
Personally, I like "obligation" as a kind of opposite to
"permission".
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
Dr.-Ing. Rainer Kallenbach, Michael Hahn
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@
lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Freitag, 27. Oktober 2017 16:26
To: Anil Saldanha <asaldanha1947(a)gmail.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Permission and Obligation
Hey Anil, thanks for the feedback.
You are right, obligation is probably not the best term to use here.
I did something already using "claim". Where a *permission claim*
represents assertions of the result of the decision as well a demand or
request from the PDP to PEP.
Sounds better ?
I gave just one example, but we could also use permission claims to, for
instance, force the application to ask user to raise his security level
(using some stronger authentication mechanism/flow).
On Fri, Oct 27, 2017 at 11:28 AM, Anil Saldanha <asaldanha1947(a)gmail.com>
wrote:
> Pedro - if you are able to use a better term than “obligation”, then
> you will have success in adoption.
>
> XACML obligations are least understood and not very well used. I never
> liked them unfortunately. :-(
>
> Maybe “condition”,”requirement” or a better term?
>
> Ensure that these are sent from PDP to PEP.
>
> This is an important construct that has a potential to confuse users.
> In my view, this is a hack in the enforcement model that xacml tries to
solve.
> *my opinion only*
>
>
> > On Oct 26, 2017, at 3:08 PM, Pedro Igor Silva <psilva(a)redhat.com>
wrote:
> >
> > Hi,
> >
> > This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
> >
> > The idea is allow policies to push information to a policy enforcer
> > (PEP) in order to enrich the final decision if a resource can be
> > accessed or
> not.
> >
> > In XACML there is a well known concept called Obligation, which can
> > be
> used
> > to pass information to a policy enforcer in order to take some
> > action or verify something before granting or denying access to a
resource.
> >
> > Suppose you have a JS policy and want to push obligations when
> evaluating a
> > permission:
> >
> > if (someCondition) {
> > var permission = $evaluation.getPermission();
> > permission.addObligation('transfer.limit', '200'); }
> >
> > On the resource server side, you will be able to obtain
> > *transfer.limit* and check whether a request satisfy the obligation.
> >
> > Any comments ?
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2373
days inactive
2374
days old
4 comments
3 participants
participants (3)
-
Anil Saldanha -
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1)