[keycloak-user] Additional attributes for an authorization request

[Pedro Igor Silva]

Hey,

Yeah, we have added support for that
https://www.keycloak.org/docs/latest/authorization_services/index.html#_enforcer_claim_information_point
.

Also added support for resource attributes
https://www.keycloak.org/docs/latest/authorization_services/index.html#resource-attributes
.

Regards.
Pedro Igor


On Wed, May 23, 2018 at 11:16 AM, milan.molbio <milan.molbio at gmail.com>
wrote:

> Hi Pedro,
>
> any news about this? I think KC was at v2.5 at the time, and now we're at
> v4. Is it now possible to pass extra arguments to the evaluation context
> (and access them from a JavaScript policy)?
>
> regards,
> Milan
>
>
> On Fri, Feb 3, 2017 at 6:26 PM, Scott Elliott &lt;scottpelliott@&gt;
> wrote:
>
> > The example I've been given is evaluating whether or not a request has
> > permission to make a change to a value by a particular amount.  Sounds
> > like
> > an application function, but I don't necessarily want to have to change
> > the
> > application whenever some policy decision needs to be made or changed
> > (like
> > for now, it's based on one value, but in the future, it could be several
> > values).  Ideally, I guess, the ability to pass additional data (say,
> > JSON)
> > with the request that the Evaluation API could access, so it would be up
> > to
> > the caller and policy to decide what's needed to grant the request.
> >
>
> I see. There is a very fragile line betweem business rules and security
> policies. For instance, what you want could be achieved with Drools/JBoss
> BRMS and also by an externalized authorization system like what we are
> proposing.
>
> What you are asking makes a lot of sense as this is something common for
> protocols such as XACML. And will make our policies a lot more
> "contextualized" as you have control over the data that determine how your
> policies are evaluated. Like I said, you still have the option to use
> protocol mappers to push things into the token and use them in your
> policies. But "runtime" data like what you mentioned is not something you
> can do right now. But we'll get there ...
>
>
> In the future we want to support resource attributes. I think that would
> also help to cover more use cases. For instance, considering your use case
> where you need to authorize access based on an dynamic attribute. We may
> have a "amount" attribute on the resource and a general permission
> associated with this resource that tells that only the owner is allowed to
> access. When you receive permissions for the resource you could also get
> the attributes associated with it and then perform local checks in your
> application (probably using the AuthorizationContext). In this case, if you
> change the "amount" on the KC server you won't need to change your
> application. Just an idea.
>
>
> >
> > On Fri, Feb 3, 2017 at 12:26 PM Pedro Igor Silva &lt;psilva@&gt;
> > wrote:
> >
> >> Hi Scott,
> >>
> >> You can't pass additional attributes along with an authorization
> request.
> >> However, that is something we want to support on future versions.
> >>
> >> Right now, the information you get is basically what is in an access
> >> token. So whatever you push as a claim (e.g.: using mappers) it will be
> >> available to your policies.
> >>
> >> That is an important addition to our API in order to push more context
> to
> >> policies, as you are requesting.
> >>
> >>
> >>
> >> Regards.
> >> Pedro Igor
> >>
> >> On Thu, Feb 2, 2017 at 2:18 PM, Scott Elliott &lt;scottpelliott@&gt;
> >> wrote:
> >>
> >> Would there be any way to pass additional attributes to an authorization
> >> request, and access
> >> it
> >> in a Javascript or rules based policy? I see that what is available in
> >> the
> >> Evaluation API currently is pretty limited.
> >>
>
>
>
>
>
> --
> Sent from: http://keycloak-user.88327.x6.nabble.com/
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>