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