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

[Brahim Ait elhaj]

Hi and thanks a lot for your feedback.

My answers/questions below ...

On Wed, Jul 12, 2017 at 3:08 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> Some questions inline ...
>
> On Tue, Jul 11, 2017 at 9:10 PM, Brahim Ait elhaj <brahima at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> Lately i was playing with Keycloak (KC), evaluating it for an IoT project
>> and i have a question regarding the authorization services.
>>
>> One of my use case is : devices that connect to an MQTT Broker using X.509
>> client authentication.
>
>
>> Note : when i talk about device, you must understand KC user (device =
>> user).
>>
>
> Do clients connect to your MQTT on behalf of an human ?
>

Once device are provisioned in the platform (done once through an app),
they become autonomous and can start connecting/talking to the MQTT Server
at any moment ...


>
> 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 ?


>
>
>>
>> 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.


>
>
>>
>> My need is to have my MQTT Broker (ideally through KC) authorize/reject
>> MQTT client to publish/subscribe to specific topic.
>> MQTT Topic being some kind of uri/path, i already have an idea of how to
>> configure KC (client, resource, policy, permission ...) to
>> authorize/reject
>> these access.
>
>
>> However, as i understand it, the starting point for all the «
>> authorization
>> services » (Authorization API, Entitlement API ... ) is a « user Access
>> Token ».
>> In my case, i don't have a user access token ... so i'm kind of stuck to
>> use any of the K.C API (unless i missed something).
>>
>
> Considering your devices are actually users in your realm, you should be
> able to obtain access tokens from Keycloak. With this access token you can
> then use Entitlement API, for instance to obtain a RPT that you can finally
> send to your MQTT broker. But I think you have constraints that block this
> approach ...
>

> The point here is that our APIs need to identify the identity associated
> with a permission request somehow, hence the need for an access token when
> using any of our APIs to obtain the RPT.
>

Exactly, i technically can have some devices (http capable) connect to KC,
get a token et connect to the MQTT Broker ... but some devices cannot so i
need to support this use case.


>
> If I understood your use correctly, the only thing you have that
> identifies the user/device is a certificate. But we only support access
> tokens previously issued by Keycloak to your clients/users.
>

Right !


>
> 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.

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 ...

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) ?

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


>
>

>
>>
>> Hence, My question is how can i make my MQTT Broker (.ie : resource
>> server)
>> interact with KC to enforce/evaluate policy ? Is it possible without the
>> user access token ?
>
>
>> Hope i made myself clear and thanks in advance for any help ...
>>
>
> Btw, have you considered OAuth2 Device Flow ?
>

Yes, can make sense for some devices (http capable, internet connected ...)
but not for all devices ...


Thanks again for your feedbacks. Greatly appreciated !
Brahim


>
>
>>
>> Best regards,
>> Brahim
>>
>



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