[keycloak-user] Additional attributes for an authorization request

[Pedro Igor Silva]

On Fri, Feb 3, 2017 at 6:26 PM, Scott Elliott <scottpelliott at gmail.com>
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 ...


>
> OOTB, I'm not sure.  It confused me for a while why the URI was in the
> resource configuration, when you couldn't pass a URI for Authorization, but
> I've since figured out that the URI is used in the OIDC adapter to select
> the resource, not in the server.  That's one of the items that was expected
> to be available in the Evaluation API.  I don't know if it really makes
> sense or not, assuming a general purpose resource mechanism.
>

That is correct. The adapters are using URI to map a path to a resource.
But you can also have resources without an URI and still map them with
paths in your application within the "policy-enforcer" in keycloak.json.
For instance, you may define that "Resource A" (name) is associated with
path "/some/path/to/access".

You are still able to obtain the resource (and related data) from policies.
It should be possible to obtain the URI too. From the evaluation object you
can obtain a resource permission and then the resource (and/or scopes)
being requested.

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 at redhat.com>
> 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.
>>
>> One thing to keep in mind is that we can't blindly trust authorization
>> requests from clients are they can be easily manipulated. What type of
>> client are you using ?
>>
>> Another question, what are you missing in the Evaluation API ? Is there
>> anything we can provide OOTB ?
>>
>> Regards.
>> Pedro Igor
>>
>> On Thu, Feb 2, 2017 at 2:18 PM, Scott Elliott <scottpelliott at gmail.com>
>> wrote:
>>
>> Would therebe any way to pass additional attributes (say, something from a
>> REST API call's headers or body) 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.
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>