On 18.04.2016 20:10, Heiko W.Rupp wrote:
On 18 Apr 2016, at 17:14, Juraci Paixão Kröhling wrote:
> Another aspect that comes with the removal of the dependency on
> Keycloak
> is surrounding tenancy. We don't have the same requirements as before,
> and in the case described above where Hawkular could be seen as a
> "database", the tenancy would/should be managed on the user-facing
> application.
Not sure I completely understand. When e.g. RHQ
uses Postgres, it always logs in as "rhqadmin/rhqadmin".
There is no forwarding of the logged in RHQ-user
to Postgres, but Postgres is always accessed by the
technical user.
I exemplified in another email. Something like this:
jdoe -> Client 1 -> admin1 -> hawkular
jsmith -> Client 1 -> admin1 -> hawkular
jsmith -> Client 2 -> admin2 -> hawkular
Previously, our model was to have "jdoe" talking directly to Hawkular,
and Hawkular Accounts would determine the tenant. Our other Hawkular
components would just need to @Inject a Persona and that persona would
be the tenant.
We have this technical user now, so, we don't necessarily have the
tenant information based on the trusted user data (signed JWT from KC +
data we store ourselves in Cassandra). Accounts cannot inject an
appropriate Persona anymore. We would then need to trust the client (RHQ
in your example) to handle tenancy information, restricting access to
data from tenant A from being seen by tenant B. Or treat tenant data as
just another piece of information, without actively trying to do access
control on our side.
- Juca.