[rhq.metrics] Keycloak vs. external client requests

Juraci Paixão Kröhling jpkroehling at redhat.com
Fri Nov 21 16:19:01 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

TL;DR: is Google's "offline" token acceptable as a solution for an
external client to send data to the Metrics REST API?
https://developers.google.com/accounts/docs/OAuth2WebServer#offline

Long version:

During the presentation of the PoC for Keycloak integration, one of
the questions was about an external client sending requests to the
backend. As of now, there's no good solution for that.

I have started a discussion on keycloak-user mailing list, asking if
it would be interesting for the KC project to have some sort of
"key/secret" support for external clients, à la Amazon AWS. What
*seems* to be acceptable is the usage of "offline" tokens, as
implemented by Google:
https://developers.google.com/accounts/docs/OAuth2WebServer#offline

This would effectively mean that a client would need to perform these
steps to contact the backend:

- - read a refresh token from a permanent storage
- - request an access token to the KC server based on this refresh token
- - send the request to the backend using the access token

On the first run, these steps would also be required:

- - a client[*] would build an URL for the user to visit
- - user would authenticate against the KC server, and would see a code
as the outcome
- - this code would be entered on the client
- - client would do a first request, exchanging this code for the
refresh token

Once a refresh token is obtained, it can be reused by all nodes in a
farm/setup, so, it can be propagated to all nodes via the appropriate
methods (push from the server, puppet/chef, kickstart, ...)

My concern is that this approach would require either a good amount of
work on the external client's side to cache the access tokens or would
require 2x requests than a simple backend call (one to obtain the
access token, one to the backend itself).

So, is this "offline token" something that would be acceptable for RHQ
Metrics? Note that we could perhaps build a native CLI tool that would
do all of the above, as this is very generic. But the overhead would
still be there somewhere :-)

* this client could be anything. I imagine that we could provide this
as a bash script or java installer or something similar.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUb2X1AAoJECKM1e+fkPrX8/sH/0aWMsw1IIoKw8CLe3/VnKaO
eSGukl4/dIHWXcJCG0tEJRZtIaTI7Ho4UlBrGMSuIubE4gQCf43Jv4UKz+Htex7d
2QbX0wY2A5cb3gOBU+5mF57inlbV+clrjyoOSwIm8j3pNfcz0mUcJ5rmgWIhmQHk
kHDX4b204zm9B7YtNKcs+K5gfDBXZfyOC8IpgfogRqqoqUSpE2CMuPugknHmWwCa
sRFdjgJ4qOFRbUU25o6miSOepaZiMP6kZxUW3yehg4xoB5DLyM9vO118OP1spIJg
ysxzjsIOdJfle+SSDUZoUHR1DfvCZdsb2gGEanIjg/V+6Q75a8lp5hWBnHALvac=
=n35C
-----END PGP SIGNATURE-----


More information about the rhq-devel mailing list