[keycloak-user] Authorization services without User Access token (Mqtt Broker / IoT)

[Pedro Igor Silva]

On Wed, Jul 12, 2017 at 1:23 PM, Brahim Ait elhaj <brahima at gmail.com> wrote:

>
>> If a device is actually an user, who are your clients ? The same devices ?
>>
>
> My client is the MQTT Server in this use case (as the *photoz-restful-api*
> in the *photoz* example).
> I want to protect access to MQTT topics (paths/resources) of this MQTT
> server.
>
> I was initially asking myself whereas devices should be « users » or «
> clients » but we could end with a lot of clients in the latter scenario ...
> also after playing with KC and reading through the mailing list
> questions/answers, i think that's a better approach to have devices be
> users and not clients.
>
> However, did you have something in mind when asking this question ?
>

I was wondering if the users you mentioned were actually service accounts
associated with clients representing your devices. But yeah, the decision
on whether devices should be users or not I think depend on the
capabilities you want to support on them.


>
>
>>
>>
>>>
>>> For several reasons/constraints that i won't explain here, i can't have
>>> my
>>> devices connect first to Keycloak to obtain a token (using their X.509
>>> certificates as KC supports it) and then connect to the MQTT Broker
>>> passing
>>> this token. They connect directly to the MQTT Broker, each device
>>> presenting its X.509 certificate to the Broker. After connection, the
>>> Broker doesn't know client private key.
>>
>>
>> Now I'm curious :)
>>
>
> Ok, the main reason is that the one thing that can be guaranteed about
> devices is that they have a certificate to authenticate themselves. They're
> not necessarily http or even mqtt capable. They can be able to communicate
> only via a low power wide area network (Lora / Sigfox ... ie. not connected
> to internet directly)
>
> So we know how to deal with a user (be it a human or a device) that can
> authenticate and get an access token.
> My concern here is how to deal with a user (device) that can not.
>

Ok, so that changes things a bit ...


>
>> However, I think we could support your use case with UMA 2.0 changes we
>> are planning. In the new version of the specs, the client don't actually
>> need an access token in order to obtain RPTs from AS. There is a specific
>> OAuth2 Grant Type, which you can use just like any other grant type. The
>> tricky here is that instead of using an OAuth2 Access Token to gain access
>> to our APIs, you basically authenticate the client using whatever client
>> authentication method we support. For instance, id/secret, jwt or even
>> using a bearer token (as it stands today). In addition to that, you are
>> allowed to send tokens with claims associated with a requesting party
>> (e.g.: your devices). That would allow you to send your devices
>> certificates.
>>
>> In a nutshell, in a single request to the server you would provide your
>> client credentials + device certificate. And we would need to support
>> extracting requesting party information (the user) from certificates.
>>
>
> Yes, it seems really interesting and corresponding to what i'd like to
> achieve. Since you talk about UMA, i understand this is the « Authorization
> API » that is involved here.
>

That is one of the changes introduced by UMA 2.0. The Authorization API was
replaced by a UMA Grant Type [1]. We are going to deprecate the
Authorization API and leave it there for a while. But remove it in future
releases.

My statement above also applies to our Entitlement API, which we also want
to support scenarios where the identity is not really represented by an ID
or access token.

[1]
https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-08.html#seek-authorization


>
> Also, you said « *In the new version of the specs, the client don't
> actually need an access token in order to obtain RPTs from AS* », can you
> please point me to the specs that talk about this specific part (if
> possible) ? I quickly went through the v2.0 without being able to clearly
> identity this specific part ...
>

See link above.


>
> Do you have something (beta ...) that i can start playing with ? Is it
> already in the roadmap (maybe you have a specific ticket number in mind) ?
>

Nothing yet ... But this is my next task in Keycloak. At the moment I'm
stuck with tasks in other projects that I need to get it done. But the JIRA
is https://issues.jboss.org/browse/KEYCLOAK-3169.


>
> Depending on the estimated « landing » date, i can contribute in many
> ways. So, What's the next step :-)
>

Sure thing. Maybe you can start providing some more background to what you
need in that JIRA. Although the title is related with UMA 2.0 it will also
involve changes to Entitlement API.

The initial plan did not include what we are discussing here. But I think
we can consider your requirements during development once we agree on what
we really need to do.

Maybe another approach to your problem is make your MQTT Broker both a PDP
and PEP. I mean, you would use some REST API in Keycloak to evaluate
policies based on a set of one or more resources/topics + enforce access
based on the permissions returned by the server. We do have an endpoint
that you can use to evaluate policies (see
https://github.com/keycloak/keycloak/blob/master/integration/admin-client/src/main/java/org/keycloak/admin/client/resource/PoliciesResource.java#L70).
But it is basically accessing the API used by our Policy Evaluation Toll in
the admin console. Ideally, you should use Entitlement API, Authorization
API/UMA Grant Type.


>
>>
>>
>>>
>>> Best regards,
>>> Brahim
>>>
>>
>
>
>
>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>