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

Tue Aug 1 18:00:14 EDT 2017

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 at 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 at 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 at 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 at gmail.com>
> Cc: keycloak-user <keycloak-user at 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 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
> >>
> >>
> >>
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>