[Hawkular-dev] Looking for a first project to integrate accounts

[Juraci Paixão Kröhling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/21/2015 03:29 PM, Lukas Krejci wrote:
>> Is sharing of information possible between personas? It is not
>> possible in inventory between tenants currently so this is the
>> part where I struggle a bit.

- From accounts perspective, yes. See below.

>> You can imagine the inventory's tenants as "access points" to
>> disjoint subgraphs in the inventory. You only can access any data
>> if you know your tenant. Also, and possibly more importantly, no
>> entity in inventory is required to have a "globally" unique
>> identifier. The only thing unique is the path to the entity,
>> starting at the tenant, then down the environment, etc.
> 
>> So if a user is a tenant they will not be able to even reference
>> data from other tenants.

There's a scenario that was discussed on demos and, I believe, on
previous threads. Those discussions impacted the modeling of the
tenants concept on the accounts side and one of the use cases is:

- - Acme, Inc is an organization
- - "Marketing" is an organization whose parent is "Acme, Inc"
- - "Finance" is an organization whose parent is "Acme, Inc"
- - "Finance" cannot see resources from "Marketing" or vice-versa
- - "Operations" is an organization whose parent is "Acme, Inc"
- - "Operations" should be able to monitor its own resources plus
resources from finance and operations, all in one (or more) dashboards.

>> I guess the my main struggle is that the inventory is modelled
>> after a "physical" layout of the monitoring data - data belongs
>> to some tenant and can be further classified/narrowed down by the
>> environment, etc.

As far as I can see, it can be kept this way. The data can be stored
in any way you prefer, while the access control part has different
storage and different ways of resolving who has access to what. Note
that there's a "resource" concept on Accounts which stores the owner
information, and that's independent from the one in, say, inventory.

>> In accounts, users/orgs/personas are very fluid concepts that can
>> inherit from each other, etc. while the classification of the
>> data they access is not that fluid.

Note that "user/orgs" abstracts to "persona". So, inventory would only
care about "persona" and would ask accounts if the current persona has
access to this resource. It should not matter to inventory if the
current persona (user or org) is different than the owner of the
resource, although inventory can keep track of this information for
other reasons, if needed.

>> Inventory's tenant is a crucial part to be able to address any
>> entity.

You mean, the tenant being part of the identifier? If so, that's
irrelevant for accounts. As long as you can provide me with a stable
identifier for the resource, I'm able to tell if you if the current
persona (user/org) has access to the resource.

>> So "knowing a current tenant" to check for permissions is quite
>> ok, but I am not sure I can "just know the current tenant" to be
>> able to address the data. I.e. 2 users are supposed to access
>> data from agent "A" in environment "staging" for "Acme, Inc.",
>> while a third user is supposed to access data from agent "A" in
>> environment "staging" for "Redhat, Inc."

Forgetting a bit about the "staging" part, this is how I see it:

- - User "jdoe" creates the organization "Acme, Inc", he is therefore
"Super User" of it.
- - User "jsmith" is added to "Acme, Inc" as "Super User"
- - Agent "a" is a resource that belongs to "Acme, Inc"

In that situation, user "jdoe" makes a request to the backend, which
Accounts translates to as being the persona "Acme, Inc". So, inventory
knows that it's related to the persona/tenant "Acme, Inc".

If you absolutely need to know who is the actual user for the request,
you can request it to the accounts API. In the usual case, however,
knowing the current "persona" should be enough.

>> I suppose that our model should allow for more organizations (in
>> a SaaS sense, not accounts sense) to have the environment called
>> "staging" and that their agents should be independent.

- From the accounts perspective, this is achievable.

>> Remember that inventory doesn't have a unique ID of the
>> "staging" environments for the particular organizations.
>> Currently this is resolved by having a set of tenants that are
>> required to have unique names and that you can use to start
>> composing your path to the agents, i.e. "Acme/staging/A" or
>> "Redhat/staging/A".

As far as I see it, "Acme" is an organization, "staging" is an
organization owned by "Acme" and "A" is a resource in "staging". From
Account's perspective, the owner is "staging" (from the Acme
organization), so, users who are "Administrators" on this organization
have access to this resource.

But do you mean that you don't have a unique ID for a specific
resource for a specific tenant? This is something I would need. Note
that it's not needed to be an UUID, I just need a value that you are
able to consistently provide to the accounts API when checking for the
permission. On the above example, it could very well be "Acme/staging/A"
.

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

iQEcBAEBCAAGBQJVNljbAAoJECKM1e+fkPrXQpEH/AjYbHyLFfs7IBrpEwwAfZwZ
IFzgX5cdXktO9loEvtxnH7nkSag+iWCIH2EJWVg2ql8YXr81UdyGlDSUl2NP+EtL
PFy3l8b7FbYp6SPby7CvyXHtmhsRe1SEUTAOcU5dn3ufPbwkRliPrEhyKL3hqOIH
Fz4kENeRugJyn8X48GCRP5EI4KSXUzN9F2zRFNP2Ub37QFN9njxt5e0E3J+ZDUeD
HC0g8o2nLkai37gZJX9eWm5NPJT83w7ynNrZKDTS3rkq3of+gfTlEv2yqWc/brgp
HFII4jp1VDQeRX+B/AUugzn879sLF+psJaRMq4Mls1NntznDVpDoO5bNOHr0T5c=
=k82w
-----END PGP SIGNATURE-----