[keycloak-user] Additional attributes for an authorization request

[milan.molbio]

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 <scottpelliott@>
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 <psilva@>
> 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 <scottpelliott@>
>> 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/