2:10 a.m.
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).
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.
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).
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 ...
Best regards,
Brahim
3:08 p.m.
Hi,
Some questions inline ...
On Tue, Jul 11, 2017 at 9:10 PM, Brahim Ait elhaj <brahima(a)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 ?
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
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.
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
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.
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 ?
Best regards,
Brahim
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
6:23 p.m.
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(a)redhat.com> wrote:
>
>>
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
Hi,
Some questions inline ...
On Tue, Jul 11, 2017 at 9:10 PM, Brahim Ait elhaj <brahima(a)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 :-)
7:19 p.m.
On Wed, Jul 12, 2017 at 1:23 PM, Brahim Ait elhaj <brahima(a)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-autho...
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...).
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
9:41 a.m.
Hi Pedro,
Since I saw you referring to
"https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-08.html#seek-authorization":
I think this is not latest version of UMA2. They changed the naming of the spec parts and
IMHO https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-04.html and
https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-0... form the
current spec. Just in case you did not notice the change of names...
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin | GERMANY |
www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
-----Original Message-----
From: keycloak-user-bounces(a)lists.jboss.org [mailto:keycloak-user-bounces@lists.jboss.org]
On Behalf Of Pedro Igor Silva
Sent: Mittwoch, 12. Juli 2017 19:19
To: Brahim Ait elhaj <brahima(a)gmail.com>
Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] Authorization services without User Access token (Mqtt Broker
/ IoT)
On Wed, Jul 12, 2017 at 1:23 PM, Brahim Ait elhaj <brahima(a)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-autho...
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...).
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
midnight
Hi Brahim,
Are you still considering Keycloak and our Authorization Services in your
architecture ?
Regards.
Pedro Igor
On Thu, Jul 13, 2017 at 4:41 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Hi Pedro,
Since I saw you referring to "https://docs.kantarainitiative.org/uma/ed/
uma-core-2.0-08.html#seek-authorization": I think this is not latest
version of UMA2. They changed the naming of the spec parts and IMHO
https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-04.html and
https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-
04.html form the current spec. Just in case you did not notice the change
of names...
Best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Sebastian Schuster
Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin |
GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster(a)bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
-----Original Message-----
From: keycloak-user-bounces(a)lists.jboss.org [mailto:keycloak-user-bounces@
lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Mittwoch, 12. Juli 2017 19:19
To: Brahim Ait elhaj <brahima(a)gmail.com>
Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] Authorization services without User Access
token (Mqtt Broker / IoT)
On Wed, Jul 12, 2017 at 1:23 PM, Brahim Ait elhaj <brahima(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:22 a.m.
Hi pedro,
Sorry for the delay to answer, but yes.
To familiarize myself with KC, it tried the approach you suggested in our
last discussion (MQTT Broker both a PDP and PEP) and it works. I'm still
considering the more «clean» approach but this gave an argument in favor of
adopting the tool (having a working solution) ... it tried several others
(WSO2 ...) and find KC more simple to understand and integrate.
We're currently deploying it in our qa environment to push our tests
further ...
On Wed, Aug 2, 2017 at 12:00 AM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
Hi Brahim,
Are you still considering Keycloak and our Authorization Services in your
architecture ?
Regards.
Pedro Igor
On Thu, Jul 13, 2017 at 4:41 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
> Hi Pedro,
>
> Since I saw you referring to "https://docs.kantarainitiativ
> e.org/uma/ed/uma-core-2.0-08.html#seek-authorization": I think this is
> not latest version of UMA2. They changed the naming of the spec parts and
> IMHO https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.
> 0-04.html and https://docs.kantarainitiative.org/uma/ed/oauth-uma-
> federated-authz-2.0-04.html form the current spec. Just in case you did
> not notice the change of names...
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
> Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin
> | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster(a)bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: keycloak-user-bounces(a)lists.jboss.org [mailto:
> keycloak-user-bounces(a)lists.jboss.org] On Behalf Of Pedro Igor Silva
> Sent: Mittwoch, 12. Juli 2017 19:19
> To: Brahim Ait elhaj <brahima(a)gmail.com>
> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
> Subject: Re: [keycloak-user] Authorization services without User Access
> token (Mqtt Broker / IoT)
>
> On Wed, Jul 12, 2017 at 1:23 PM, Brahim Ait elhaj <brahima(a)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(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> >>
> >>
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
2450
days inactive
2473
days old
6 comments
3 participants
participants (3)
-
Brahim Ait elhaj -
Pedro Igor Silva -
Schuster Sebastian (INST/ESY1)