[Hawkular-dev] define: tenant

[Juraci Paixão Kröhling]

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

On 02/04/2015 05:00 PM, Heiko W.Rupp wrote:
> How would we model the user / org stuff? Well, that could probably 
> just become a part of inventory

I'd say that this mapping should be part of a new module, with an API
being provided to other modules.

The model would be something like this:
* Metric belongs to Owner.
* Organization belongs to Owner.
* Owner is an interface, implemented by User and Organization.
* User can be the owner of one or more organizations.

This way, organizations can be owned by other organizations. Not sure
if this will work, though. I'm starting to work on this right now on a
new module (hawkular-accounts).

> Question is though: if a user has his own pet server and works as 
> part of an org. Do we want to prevent "leaking" org data to the
> private project? Or is that purely up to the user?

If an user makes a REST call to retrieve all metrics that he has
access to, I'd expect that he'd receive both metrics for his pet
projects and metrics for organizations he's part of.

> Wouldn't the backend still need to know the context - and if only
> for performance reason when the user wants to only see his personal
> resources?

The backend *needs* to check if the current user has access to the
resource. Other than that, I'd say it's up to the individual
components (alerts, metrics, inventory, ...) what/how they want to
expose data to the consumers. For instance, metrics might want to have
the following REST endpoints:

/{owner}/metrics
  --> all metrics owned by "owner" (organization or user)

/metrics
  --> all metrics to which the current user has access to

/metric/{metricId}
  --> a specific metric, as long as the user has access to it

So, on the metrics backend and UI, they might decide to always require
an owner (like, with a context switcher on the UI), or to provide both
endpoints.

> Well, I guess a good deal of authorization needs to be done in some
> custom code anyway and would not be covered by stock-JAAS, so it
> may not be that bad.

Indeed. The more I think about this problem, the more I'm convinced
that we should be handling the authorization ourselves.

- - Juca.

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

iQEcBAEBAgAGBQJU0k85AAoJECKM1e+fkPrXMUEH/jRCxeAuERAP761WZQmPlUvH
GItzQRMPBW+M+CHEdzYJGErCARrJeWPSOjtMp/xKz+W8Iw7SBMH/KDlfDDILooFk
JEXKSdITJIGHNSE+SQ9A+33LfVYUM2CfS4oeWgOmOOmemKP1HTO7z479qljXUPDN
NLn0pSSynZhONMH3l5M1IEuCthCFHqrPzzWBpmhrmL8+rhBkrm5tQU4IjfFGERcP
VmFiFut7tJreq2Yr3kqPoidJiHs37ZFlQzfZmbwcdDjBtO+m/uz9g3pp49JhHAKY
eAAdb4mhNBu8hrYLm1fx0jwBzyG6R7nNQUO9O+aTi7ODd38BR4HJE76H6TjBQqE=
=oTDA
-----END PGP SIGNATURE-----