If you are using Keycloak, I don't understand why you would want to do basic auth. Eventually I'm going to write a JAAS plugin for simple username/password with Keycloak, but I have other stuff in my queue at the moment. For your application, you'd have to write something that obtained a admin token and verified username password and downloaded role mappings. On 11/7/2014 9:16 AM, Gary Brown wrote: > Hi > > I've just started looking at KeyCloak to use with the Overlord governance > projects. > > I have tried the examples, and see how we could leverage KeyCloak to > protect the UI apps and the backend REST services they use. However we > also need to provide the REST services as independent services using basic > auth - but would like the basic auth to be performed against the users > managed by KeyCloak. > > Is there any recommendations on how this can be achieved? > > Do we need to provide our own filter - is there any example code to do > this? > > Is it possible to do something via the KeyCloak subsystem configuration > approach, in case we wanted to secure the REST service without modifying > the war? > > Thanks in advance. > > Regards > Gary > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

With basic auth, you have zero control over the client and you're handing over credentials to that client. Simple and easy for "hello world" apps sure.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUZOM/AAoJEDnJtskdmzLMtdAH/1tdg0ExaN6muEyAqzKEH7J4 5dRhwMa5wgmb0NBNa4eu/zM4Cze7NGM4iiJgAgyqj/BsAcacNec8lo8Ri0d2H6sH khGifXhRlbfgYOSR4rnzbc6RuaCtE9YIhzrWWlXR26bXQTRiIwIYB35onVGQpC9b 39CrQripOlhW5fR4TZdKuK2k9TeKHQL5WN6/Vw41Yzor+MzhN38WZnyYg2csTn9O wRwHO1SF2f4MzGYOgbkP8UJWg5/WQQyeVbbjzPtl+OgMoxbexJzmDSGvr/D1WFFR IZJPL2C8JdyAo9XQy8WVSEjBfU6vek2haLlfFyAHj00d/om6VT3MdpFgqz4wL+I= =5kU0 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Any thoughts on that? My use case is similar to a regular "SaaS", in which I'd provide an API key and API secret (or a single token, or ...) to the users, which can then use those credentials on simple bash scripts. - - Juca. On 11/13/2014 05:58 PM, Juraci Paixão Kröhling wrote: > On 11/10/2014 02:38 PM, Bill Burke wrote: >> With basic auth, you have zero control over the client and >> you're handing over credentials to that client. Simple and easy >> for "hello world" apps sure. > > Would it make sense to add something like Google's "Application > Specific Passwords"? This way, it's not the main credentials which > are being shared and those can be revoked individually if > necessary. > > An application that is not OAuth capable for some reason could > then make use of this. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: keycloak-user(a)lists.jboss.org Sent: Tuesday, November 18, 2014 4:36:11 PM Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/18/2014 04:21 PM, Bill Burke wrote: > How is that any different than our access tokens? To obtain an access token, I'd still need to talk with the Auth server and then, based on the response (ie, synchronously), send a request with a bearer token to the service. This is not viable when the client sends several (thousands of) requests to the service.

That without mentioning the difficulties in parsing tokens via a shell script.

- - Juca. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-user(a)lists.jboss.org Sent: Wednesday, November 19, 2014 10:33:42 AM Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/19/2014 09:33 AM, Stian Thorgersen wrote: > ----- Original Message ----- >> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: >> keycloak-user(a)lists.jboss.org Sent: Tuesday, November 18, 2014 >> 4:36:11 PM Subject: Re: [keycloak-user] Recommendations for >> protecting REST service with bearer token and basic auth > > To obtain an access token, I'd still need to talk with the Auth > server and then, based on the response (ie, synchronously), send a > request with a bearer token to the service. This is not viable when > the client sends several (thousands of) requests to the service. > >> Why does the shell script have to talk to the auth server for >> every request? It should cache the token, not the users >> credentials. I have the strong feeling that I'm missing something very fundamental here, so, I'd be very glad if you could correct me if I'm wrong. I got more time thinking about this, and you are right, caching the tokens is pretty much the only solution that could make this work. But still, it's not very optimal. As I see it, if I have one "business" script, I need two extra scripts. First script: - - User runs the bash script for the first time - - Script generates an URL for the user to open in a browser - - User copies the code from the Keycloak server into the local file system - - Script exchanges this code for a refresh token and stores the refresh token in the local system. Second script: - - Runs every N minutes, where N < "the expiration in minutes of the tokens", updating the refresh and access tokens, and writing it somewhere in the local file system. Third script (my business): - - Reads the token from the local file system and calls the backend. The third script might still fail, if it tries to read the token while it's being written by the second script, but this is manageable. Now, how to handle a multi-host scenario? The user would hopefully not need to execute "first-script" at each host. For that, some sort of token-propagation among the hosts would need to exist. In other words, during peak time, when I spawn more worker hosts, the new hosts would only need to execute scripts 2 and 3. What I'm proposing is something like this: - - User access the "my account" page - - Copies a token/code/secret/key into somewhere in the system - - Bash script reads it and uses it for each backend request, knowing that it will fail only when the user actively revokes this key from his account. Thus, no need for the first script or second script, and no need for any token propagation. I can just spawn new hosts at any time, as the key could be stored in its kickstart file. > > That without mentioning the difficulties in parsing tokens via a > shell script. > >> Why does the shell script have to parse the token? Does it not >> just pass it on to the rest services it invokes. > My bad, not "parsing tokens" but "parsing JSON" (when getting the access token from a refresh token request). - - Juca.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/19/2014 01:01 PM, Stian Thorgersen wrote: > One exception though is that in this case you probably want an > offline token, which is something we don't support yet. Basically > an offline token would be a token that's not associated with a > specific user session, which would have a longer (possibly > unlimited) lifetime. The user would also need to be able to view > and revoke these tokens through the account management. That's exactly what I mean :-) Is there a plan for this feature already? If not, and if it's a desirable feature to have, I might be able to scratch a possible solution for it.

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; To: > keycloak-user(a)lists.jboss.org Sent: Wednesday, 19 November, 2014 > 4:01:36 PM Subject: Re: [keycloak-user] Recommendations for > protecting REST service with bearer token and basic auth > > You guys are basically describing certificate auth. Yes for the one use-case I described (where the app is the user). There's also the case where a user gives an application permanent (offline) access to their account. In Google they have a special scope you can request for this (https://developers.google.com/accounts/docs/OAuth2WebServer#offline).

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUbxP1AAoJEDnJtskdmzLM7IQH/RFJ5Cf0reec9CgMjxO1D1tt lgS20P6d17Ki0UocoNidp59YdP5TRKycYbCMchbfTZu4In+9gEBzsdxK+4acprPF sp6WCa1Comc8vFCX8Or9gxUEDRH+axWR4t/bIsBf23IvXQ1BUIVg0s21RxFoMhPP fGHoaAEGthez6Dhr7GSwr46FEO2xP94jHJ7nAs67DNeh0vvZmQ1iynBkF3NmfQzP dMCjny4i2D/UZCcSr72ud0DnoAi//vIQ86KObrqsiHV2eOhWYfHB9TozC/P1lKVM 5D8qByrnxtmgA/nYNuRFmKTYf2n6MZTU5AlSFJZr4svU6isl2zwkpczhwDRshjc= =x/UK -----END PGP SIGNATURE-----

----- Original Message ----- > From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; > To: keycloak-user(a)lists.jboss.org > Sent: Friday, 21 November, 2014 11:29:09 AM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/19/2014 05:16 PM, Stian Thorgersen wrote: >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; To: >>> keycloak-user(a)lists.jboss.org Sent: Wednesday, 19 November, 2014 >>> 4:01:36 PM Subject: Re: [keycloak-user] Recommendations for >>> protecting REST service with bearer token and basic auth >>> >>> You guys are basically describing certificate auth. >> >> Yes for the one use-case I described (where the app is the user). >> There's also the case where a user gives an application permanent >> (offline) access to their account. In Google they have a special >> scope you can request for this >> (https://developers.google.com/accounts/docs/OAuth2WebServer#offline). >> >> > If there are no objections, I'll start scratching an implementation of > this offline mode, as something on this direction will be needed for > the project I'm helping with. Sure, that would be great. There's a fair amount of work here though: 1. Account management needs to view clients with access and allow revoking individual clients 2. Need some built-in special role for apps to request offline tokens 3. Need to support scope param to actually request the above role 4. Need to support client sessions that are not connected to a user session - and also clean-up of these 5. Probably need an expiration for offline tokens, which needs to be configurable through the admin console > > Ideally, the project would benefit from using service accounts instead > of acting on behalf of an specific user, but as there will be only one > account per user/realm, this would do for now :-) > > - - Juca. > > _______________________________________________ > 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

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-user(a)lists.jboss.org > Sent: Friday, 21 November, 2014 2:47:39 PM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > Why do you need to do something that complicated? You could have > per-app/oauth-client token policies. The token policy could have a > refresh token expiration policy of never. Then everything just hooks > into existing screens and architecture. That'd be good as well, but it would still expire when user session expires. You need to have an option to let a client create tokens that are not linked to the user session. Also, for oauth clients the grant page should say that the app is requesting offline access. Having an offline toggle and per-app expiration would work at least initially, but I think in the future we'll have to support scope query param.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/21/2014 05:09 PM, Bill Burke wrote: > I don't think we ever want to separate the token from the user > session. So, this means that all hosts using an offline refresh token created for the user "jdoe1" will have to be replaced if said employee is fired? This would be the advantage (and main purpose, IMO) of having service accounts.

From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: keycloak-user(a)lists.jboss.org Sent: Friday, 21 November, 2014 6:15:24 PM Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/21/2014 05:55 PM, Bill Burke wrote: > Why does a "service account" have to be anything special? Why > can't it be a regular user? I don't know much about the internals and the implementation of the user model in KC, but from where I'm standing, it can very well be. So, to recap, this is how the flow for an external client (bash script) would be: - - user creates an oauth client with refresh token policy set to never expire - - bash reads the keycloak.json and refresh token from somewhere - - bash uses the refresh token to obtain an access token from KC server - - bash uses the access token to make the request to the backend On the first run: - - bash (or another CLI) builds an URL - - user opens this URL, logs in and gets a code from KC server - - user adds this code to the bash/CLI - - bash/CLI exchanges this code for a refresh token, persisting it afterwards It seems that the only change required then is to move the token policy to the apps/oauth clients. If so, I'll then start scratching a proposal for this change. And perhaps a shell/native (Linux) client that would handle the boiler plate above. - - Juca. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

There's still some unresolved issues here: * Never expire isn't good - it should be a longer expiration time * Grant page should ask the user to give the application offline access * User needs some way to revoke the access to the application in the future * Should tokens be unlinked to a user session, or should it be associated with a special user session (just setting a long expiration time for refresh tokens has no effect if user session expires) I'm also not sure what your use-case is, is this a bash script that acts on behalf of the user? or is it a server backend script? If it's the first the flow you're suggesting works, but if it's the other it's not the correct flow.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUcvZmAAoJEDnJtskdmzLM+o8H/jTAlNhnsSJTt842ThpRNcql mTDzfGRMXMcyFJBK8kYWRFY3NY/B2n42ux8S6q/ZvxKLKye5CtbrP7rKwQuoIFZ5 BK+KQisPgYGw3CSwjB0TRW/5BawKXIoLgMRmV/fNGx8D/BeTOordyfrhBKULdKpk +fPAsh1JdXDMV9EieQQGuX9HLhp5makG0FRVnMmw+NA967vgcPEHLBz0/NQO23I1 6HlobrH/07Z64bjcdYanxlGidJ2LIYh47lYnXHPhUSjoaK9uz5ZNZ8WQ3GW0Xg36 A/kEtexkMITmNamExnJw2E1xAMvX9lso5UjTmxH9AgMPZGFZ4Znybc7ecm+V7mE= =6yHk -----END PGP SIGNATURE-----

There's still some unresolved issues here: * Never expire isn't good - it should be a longer expiration time * Grant page should ask the user to give the application offline access * User needs some way to revoke the access to the application in the future * Should tokens be unlinked to a user session, or should it be associated with a special user session (just setting a long expiration time for refresh tokens has no effect if user session expires)

I'm also not sure what your use-case is, is this a bash script that acts on behalf of the user? or is it a server backend script? If it's the first the flow you're suggesting works, but if it's the other it's not the correct flow. ----- Original Message ----- > From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; > To: keycloak-user(a)lists.jboss.org > Sent: Friday, 21 November, 2014 6:15:24 PM > Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/21/2014 05:55 PM, Bill Burke wrote: >> Why does a "service account" have to be anything special? Why >> can't it be a regular user? > > I don't know much about the internals and the implementation of the > user model in KC, but from where I'm standing, it can very well be. > > So, to recap, this is how the flow for an external client (bash > script) would be: > > - - user creates an oauth client with refresh token policy set to never > expire > - - bash reads the keycloak.json and refresh token from somewhere > - - bash uses the refresh token to obtain an access token from KC server > - - bash uses the access token to make the request to the backend > > On the first run: > - - bash (or another CLI) builds an URL > - - user opens this URL, logs in and gets a code from KC server > - - user adds this code to the bash/CLI > - - bash/CLI exchanges this code for a refresh token, persisting it > afterwards > > It seems that the only change required then is to move the token > policy to the apps/oauth clients. If so, I'll then start scratching a > proposal for this change. And perhaps a shell/native (Linux) client > that would handle the boiler plate above. > > - - Juca. > > _______________________________________________ > 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

First thing, is this script a CLI that a user invokes, a background process that runs on behalf of the user, or a server? If it's a CLI I'd say it should ask user for username/password and use direct grant to obtain token. The refresh token could be saved in a tmp file, or in users home directory. Next time the CLI wants to invoke this it'll need to make sure the token isn't expired, if it is refresh before invoking the service. If it's a background process you'll need a setup script that asks users for username/password or as you suggest use a browser to login. After that it's the same as above. One exception though is that in this case you probably want an offline token, which is something we don't support yet. Basically an offline token would be a token that's not associated with a specific user session, which would have a longer (possibly unlimited) lifetime. The user would also need to be able to view and revoke these tokens through the account management. If it's a server it should use a certificate to authenticate the server itself. Also, it should use a "service account" rather than a regular user account. Again, this is something we don't have atm. We only have regular user accounts and passwords.