[keycloak-dev] Permission and Obligation

[Pedro Igor Silva]

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 at 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 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@
> 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
>