-----BEGIN PGP SIGNED MESSAGE-----
On 05/27/2015 09:12 AM, Stian Thorgersen wrote:
To support "agents" or other non-humans we intend to add
* 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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----