Some questions inline ...
On Tue, Jul 11, 2017 at 9:10 PM, Brahim Ait elhaj <brahima(a)gmail.com> wrote:
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
Note : when i talk about device, you must understand KC user (device
Do clients connect to your MQTT on behalf of an human ?
If a device is actually an user, who are your clients ? The same devices ?
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 :)
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
However, as i understand it, the starting point for all the «
services » (Authorization API, Entitlement API ... ) is a « user Access
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
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.
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.
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
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.
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 ?
keycloak-user mailing list