On 21 Apr 2015, at 14:07, Lukas Krejci wrote: I think users and organizations can both be tenants. Either the org is the tenant, then the users "inherit" from the org, i.e. can see all data from the org (*) or the users are the tenants and then they only see their own stuff. *) Additional access control may apply.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/21/2015 02:07 PM, Lukas Krejci wrote: The "persona" model was made with *our* concept of tenant in mind. So, a tenant could be either a real person or an organization, depending on which persona is currently selected on the UI (or which header was sent via curl). So, you could safely take a persona as the tenant. If you also use the "Resource" concept in Account's side, you could also have a way to display resources from a sub-tenant to the parent (ie: from "Acme Financial" to "Acme, Inc"). I think the inventory needs only to know what's the current tenant, and leave the permissions part to the accounts API. If there's something you might need to accomplish a particular task, we could add this as a feature to the accounts part. - - Juca.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/21/2015 03:29 PM, Lukas Krejci wrote: - From accounts perspective, yes. See below. 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. 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. 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. 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. 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. - From the accounts perspective, this is achievable. 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 SIGNED MESSAGE----- Hash: SHA256 All, I would love to get one component first and help implement this integration, so that problems and missing features would be already fixed at the time the other components start doing the integration. If you are interested in having your component integrated, let me know and we can work something out. In case you are unsure about what needs to be done, there are a couple of documents that could be helpful: https://github.com/hawkular/hawkular-accounts -- Readme file http://www.hawkular.org/docs/dev/accounts.html Thanks! - - Juca. On 04/21/2015 11:54 AM, Juraci Paixão Kröhling wrote: