8:14 a.m.
Bringing this discussion to the list. Summary so far:
===
If all those requirements got dropped, specially "multiple
organizations" and "multi tenancy", then there's really no point in
having Accounts. Without the UI/self-registration/SSO, I doubt we need
to depend on Keycloak. I added SSO to this list because if there will be
no user interaction on Hawkular, there's no "single sign on" required
there.
It's still not clear to me, though, if we need to care about
authorization. Are we getting calls only from "trusted" clients? Also,
should we use the same user base as MiQ, or should we have a "system
account" only? Having a system account might make more sense here, and
we won't need to integrate with their user database.
With this system account, we would act like a database: any user with
valid credentials would be allowed to read/write data. We would trust
the client if the client said "store this data for this tenant".
Instead of tokens, we could have just system accounts. Revoking a token
would mean just removing this system account.
===
On 15 Apr 2016, at 14:38, John Mazzitelli wrote:
What about agents/feeds? They aren't talking to CFME ; they are
talking directly to the Hawkular Server (or Hawkular-Metrics if in
METRICS-ONLY mode, such as in Open Shift). Is there not going to be
any Basic Auth headers anymore? If there will still need to be
authentication, then it must be the JAAS credentials and not the
Accounts tokens, I suppose.
If we have system accounts, then agents would use a system account, like
they would use a token. Admins are free to create one system account per
agent (key/secret), or use one shared account to all agents
(jdoe/password). For all "we" (Hawkular backend) care, it's all done by
JAAS. In fact, if all goes well, there will be no need to change
anything for the agents.
And I'm considering that the auth is done by Basic auth. If we *need* to
have other authentication mechanisms, we need to deviate from JAAS.
On 15.04.2016 14:43, Heiko W.Rupp wrote:
Yes, that *may* require a change. Or not if we e.g. have
- accounts-keycloak
- accounts-jaas
where the latter does the mapping as a jaas provider/plugin.
But yes we need to secure the agent/server comm. And we
need to apply SSL for the product (isn't that part of http/2 anyway).
So far, I don't see the need in having Keycloak, or Accounts. Securing
the agent/server communication is not relevant to the discussion, as
it's independent from the authentication mechanism being used.
- Juca.