[Hawkular-dev] define: tenant

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