From: "Juraci Paixão Kröhling" <jpkroehling(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 26 May, 2015 7:08:08 PM Subject: [keycloak-dev] Persistent token -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, For Hawkular, we have an agent that runs on behalf of an user on a separate machine (a server), sending metrics to our backend, secured by Keycloak. While we could perform all the OAuth steps in our agent code, a goal for us is to make it as easy as possible for third-parties to write "agents". So, having a basic-auth-like scenario is the ideal scenario for us. I think I have discussed this scenario earlier with Marek and/or Stian via IRC but I don't think a conclusion was made back then. Basically, what we would need is either a "persistent token" or a key/secret mechanism. For now, we are making the agent use the basic-auth, but that implies in the agent knowing the user's password (which is not ideal). As I understand that there were some talks about this before, I would like to understand what's the current (planned) solution for this scenario. Depending on how it goes, I can start with a PoC and send it as a PR for Keycloak. - - Juca. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 27 May, 2015 10:40:19 AM Subject: Re: [keycloak-dev] Persistent token -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/27/2015 09:12 AM, Stian Thorgersen wrote: > To support "agents" or other non-humans we intend to add two things > to Keycloak: > > * Client accounts - these are basically a account that's linked to > a specific client * Client auth mechanisms - cert and/or jwt/jws > auth mechanisms for clients > > There's is standard flows in OpenID Connect for clients to > authenticate as themselves to retrieve tokens. We don't have this > yet though. If there are plans on how to achieve that, I can help on this, as that's something we'd need on Hawkular. > Do you want an agent to authenticate as itself, or on behalf of a > user? In either case for the time being you should use direct grant > to obtain a refresh token and store that. I would recommend you > create a small lib that makes it very easy for an agent to do that. > Something like (pseudo code, with no thoughts about usability): On behalf of an user, so that we know under which account the data should be stored. For the direct grant/token retrieval: let's split the issue in three parts. We have our own agent, then we might have third-party tools and finally we have custom collectors, written by sysadmins. For our own agent, we can spend some time in "doing the right thing", including optimization of HTTP calls, secure storage of tokens and so on. So, even though it would be more complex than ideal, our agent is still under our control. For third-party tools, we could provide libraries that would handle this part. We'd prefer not to, as this is maintenance cost that we might not be able to afford right now, specially we have to provide APIs for "all" major languages. But for the sysadmins, we'd really need the simplest possible solution that works from the command line. The target here is to tell sysadmins: "here's a sample curl call that you could make", and let them do it. Having them worry about getting a token, parsing JSON and so on is something we are trying to avoid. - - Juca. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev