[keycloak-dev] Permission and Obligation

Schuster Sebastian (INST/ESY1) Sebastian.Schuster at bosch-si.com
Fri Oct 27 11:55:41 EDT 2017


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 at 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 at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Freitag, 27. Oktober 2017 16:26
To: Anil Saldanha <asaldanha1947 at gmail.com>
Cc: keycloak-dev <keycloak-dev at 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 at 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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
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