[Hawkular-dev] define: tenant

[Thomas Heute]

Tough subject and we can hardly predict what users will really need.

I hope we can keep it simple for now. We may have to revisit later.

Can we say that:
	Step 1: resources belong to a user and only him has access
	Step 2: resources can be shared with a group or a specific user by the 
owner (who can grant "write access" to the group or specific users)

IMO this is already quite flexible, simple from a user perspective but 
already complex enough to handle initially. (A user who have read access 
should still be able to create alerts for this resource...) We'll have 
to think about what happens to orphans resources (owner gets deleted) 
and likely other corner cases and optimizations (like the switcher you 
mentioned or like in Google drive, sharing with me doesn't mean it will 
mess with my documents unless I want to copy it over.)

I think it maps with what you described.

Thomas


On 01/29/2015 06:22 PM, Juraci Paixão Kröhling wrote:
> -----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-----
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>