Le 29/01/2016 11:26, Juraci Paixão Kröhling a écrit :
On 29.01.2016 11:14, Heiko W.Rupp wrote:
> I am not too happy about that differentiation, as client code
> now needs to know if talking to a hawkular server or "metrics
> only".
> Just take the ruby client, that is used to talk to hawkular-metrics
> on openshift on one side and in the ManageIQ provide code to
> full Hawkular servers.
> Of course it is doable, but probably adds to confusion.
The main idea, on the backend side, is that a client might send
credentials belonging to Persona "abc" and sending a Hawkular-Tenant
with "def", causing a mismatch: using the persona and ignoring the
Hawkular-Tenant makes the backend perform something the client did *not*
ask it to do. Trusting the client opens a door for security issues.
I think the code was introduced when I asked on a review about the
correct behavior for the situation above. I think the components could
be forgiving if Hawkular-Tenant == Hawkular-Persona, throwing a 400
otherwise.
Before we continue the conversation, let me sum up the different cases:
# Standalone Metrics
-> Hawkular-Tenant header sets the tenant
-> No authentication, no authorization
# Openshift integration
-> Hawkular-Tenant header sets the tenant
-> Authentication filter: basic auth or openshift oauth
Basic auth: no authorization (if you're authenticated, you can query any
tenant)
Openshift oauth: tenant verified
# Hawkular integration
-> Authentication and authorization based on Accounts
-> Credentials + optional Hawkular-Persona header set the tenant
With this in mind, we can talk of the impact on clients, and we should
consider all clients: curl, Java client, Ruby client, Wildfly Agent,
vertx-hawkular-metrics, Heapster, ... etc
I have no proposal yet but I'll start to think about it.