[Hawkular-dev] define: tenant

[Juraci Paixão Kröhling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After the demo, I was looking for ways to improve the "realm selection
modal", but I keep hitting a problem with the definition of a
tenant/realm.

Taking Keycloak out of the context for a while, I'd like to get *our*
definition of tenant to be made. After that, I can check if we can use
Keycloak as part of the authorization for this scenario (KC will
probably still be part of the authentication, though).

One possible solution is to have "users" and "organizations", a la
Github. Users can be part of zero or more organizations and
organizations have one or more members. Data (git repos or resources)
belongs to either an user or an organization.

For this solution, here's how I see it working on different scenarios:

- - standalone/hobby user: isn't a member of any organization, but have
a few resources to manage. A sample curl call:

- -> http://user:password@hawkular/metrics
   all metrics for all resources owned by the user's main account

- -> http://user:password@hawkular/resource/{resourceId}/metrics
   all metrics for this specific resource, which should belong to the
main account

- - user who creates/manages one or more organizations: can either have
resources on the main account (like standalone) or have resources
belonging to an organization. Sample curl call:

- -> http://user:password@hawkular/metrics
   all metrics for all resources owned by the user's main account *or*
owned by organizations where this user is a member of.

- -> http://user:password@hawkular/resource/{resourceId}/metrics
   all metrics for this specific resource, if the resource belongs to
the user or to an organization where the user is a member of

For this scenario, I think the UI could be built with a "context
switcher". This way, the user would have access to a dashboard with
resources from his main account and could switch to a dashboard with
resources from an organization. The backend, though, would not have
such a notion of "context". Either the user has access to the resource
or not (via the main account or via an organization).

Putting Keycloak back in context: for this kind of scenario, we would
have only one Keycloak realm, so, all users would be in one big realm.
All of the authorization would be made on our backend(s). Upon
registration (via Keycloak), an user doesn't belongs to any
organization. In the future, we can consume some extra LDAP data from
Keycloak, to auto assign users to some organizations, if desirable.

The main disadvantage of this is that we have to also care about the
authorization, as we cannot rely on permission data coming from Keycloak.

The main advantage is that we get a behavior that is custom tailored
to our use case.

Thoughts?

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUymw8AAoJECKM1e+fkPrX9KQH/A2O1pcV+cO3mu7PPV5aWq/v
9Ke+xlm+2hutMVKned5RGld2JD47pqTqdj6WBsLqu04AcntUrc46Vt8gnHCGrst+
FlYPsvlhb/tkN3Ddg4UMfspn5uar7uaSg2namTtSz3A/DDjQkmxqBBCUqtLgFaAc
NDaV/XkDrPCBbbNOHN11GLBV8WpFM6g5JeiaPfHWROGTifQCJU52ZEgPj0pbtGL9
NqLjOF2ekrnhxVNH/PqP2akN0bzWK6Bo2i2SMgNILZEDVQyMlTA1w1hCEcn/35oG
wHCOsGFb2RUJyqGgWqyqoxqsKBgOErzfGUhwQ4VEpU15Cvoh3HyGrEtHQCqFWzI=
=IfUo
-----END PGP SIGNATURE-----