Keycloak integration

Heiko W.Rupp hrupp at redhat.com
Thu Jan 8 11:40:32 UTC 2015


What Thomas said so far

> Am 05.01.2015 um 09:36 schrieb Thomas Segismont <tsegismo at redhat.com>:
> 
> Yes, we need a custom interceptor which inspects the Subject and makes sure that jdoe at "acme" cannot read metrics from other tenants, even if it has the "metrics-rw" role.

My understanding is that the roles are per-tenant. So (tenant=acme,role=metrics-rw) != (tenant=foo,role=metrics-rw) ?
How would that work / fail? 

If a request comes in at GET /tenants/foo/metrics/bla

then the tenant would be resolved to be foo and the user resolved to <user> inside of <foo>

Also keep in mind that in the longer run we need to have a way of granting some access rights
to GET /tenants/foo/metrics/bla from a user of tenant=acme.
This is for situations where metrics-instance user would be set up for an organization (o=acme.com)
and then then tenants for org units (ou=finance, ou=car-insurance, ou=house-insurance, ... )
Here the ops and especially 24/7 people would need to have insight into data of all the tenants
at least in case of alerts to see what is going wrong.

This could probably be dealt with a super-tenant, that can just read all data from all other tenants.



>> 
>> Questions has been raised regarding the step where Keycloak resolves
>> the tenant for the request: this part is delegated to the application
>> (rhq-metrics), so, it can be anything that makes sense for the
>> project. Right now, the PR checks a specific HTTP header, but it can
>> be changed to match part of the URL (/tenants/{tenant}/metrics/data).
> 
> IIRC, we went including the tenant id in the URI precisely to avoid sending it as an HTTP header.

Yes, as e.g. Grafana can not supply that header, but can easily be told to
use /tenants/acme.com/influx as base-url for all its requests.
( See e.g. http://pilhuhn.blogspot.de/2014/06/rhq-metrics-and-grafana.html )




More information about the rhq-devel mailing list