Keycloak integration

Thomas Segismont tsegismo at redhat.com
Mon Jan 5 08:36:50 UTC 2015


Hi,

Comments inline.

Le 23/12/2014 12:51, Juraci Paixão Kröhling a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> There was a discussion on IRC today about the multi tenancy for
> rhq-metrics. Some thoughts were collected, some questions asked and I
> got some answers, but it would be interesting to review those :)
>
> Keycloak can take care of the authentication and authorization parts
> of a request when used together with JAAS. Note that, in Keycloak
> terms, a tenant is a realm. A realm contains roles (like
> "metrics-rw"), users (like "jdoe") and applications (like "agent").
> Realms are created based on a template, upon user registration. Right
> now, each user is a realm, but Keycloak is ready to support multiple
> users per realm.
>
> The flow of a request is something like this:
>
> - - Request comes in
> - - Keycloak intercepts it and tries to determine to which tenant the
> request belongs to
> - - Keycloak then authenticates the user against the realm (ie: user
> jdoe at "acme" realm).
> - - If the authentication is successful, it creates a Subject identity
> (JAAS)
> - - JAAS then determines if the user is in a role that allow access to a
> resource/method. So, a class/method can be annotated with
> @RolesAllowed("metrics-rw") and JAAS will make sure that the user has
> this role before the method is executed
> - - At this point, the application method is executed, and a JAAS
> Subject identity is available. It's the application's responsibility
> to use the subject's information (including the realm/tenant name)
> when dealing with data (ie: returning only data from "acme" to users
> belonging to "acme").


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.

>
> 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.

> The idea is that when the request reaches the business code, Keycloak
> has already authenticated the request (ie: this user exists, has
> provided valid credentials and belongs to the tenant that it claims to
> belong to) and the contained has authorized the access (ie: the user
> has a role that allows this method to be executed).
>
> There are also URLs that won't contain tenant information: those would
> then fall back to a "super-realm", meant to be used only by the super
> admins (ie: those who can manage the tenants).
>
> If the assumptions above are correct, I'll then proceed with changing
> the "resolved" to get the realm from the URL.
>
> - - Juca.
>

Could you think of a solution for the InfluxDB compatible endpoints? 
Their paths start with "/tenants/{tenant}/influx" and clients must 
authenticate with query parameters ("?u=root&p=root").

Regards,
Thomas


More information about the rhq-devel mailing list