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

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&gt; 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&gt; > Cc: keycloak-user <keycloak-user(a)lists.jboss.org&gt; > 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&gt; > 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 >