I've been scratching my head for the most part of today to come up with the following workflows. While there already is an implementation of the inventory integrated with accounts, following the f2f discussions it needs to see some changes. Before implementing them though, I'd like to run the below workflows and assumptions through Juca in particular to correct any of the misconceptions about accounts that I still might have ;) Account resources: Each entity in inventory is represented as a "resource" in accounts. The word "resource" is something different here than what it is inside inventory. Operations: * update-tenant - checked on the actual tenant * delete-tenant - checked on the actual tenant * create-environment - checked on the tenant the environment should belong to * update-environment - checked on the actual environment * delete-environment - checked on the actual environment * create-feed - checked on the environment the feed should belong to * update-feed - checked on the actual feed entity * delete-feed - checked on the actual feed entity * ... etc. for all the rest of the inventory entity types * relate - checked on the source inventory entity of a relationship to be created Notice the absence of "read-*" privileges which are implied - each persona can only read its tenant and everything underneath it. Also notice the lack of "create-tenant" - that operation doesn't make sense actually because each persona IS a tenant. The tenant is created by the inventory on the fly if needed (and yes, tenantId is going to move to the headers or query params in the inventory REST the same way as it did in metrics ;) ). Now to the workflows: * New user registration: 1) user created in KC 3) a tenant is created with the same ID as the user with the user set as its owner 4) Step 3) implies the user has the "Super User" role on the tenant * New org registration: 1) User is registered normally 2) User creates a new organization 3) The user is set as owner of the org, having SU perms on it, the user is also a member of the org. This is all done implicitly by accounts. 4) New tenant with the same ID as org is created with org as its owner 5) The above means that both the org and the user that created it have SU on the new tenant * Adding org2 under org1: 1) Orgs registered normally 2) org2 added under org1 (using some accounts mechanism) 3) The above means that org1 is now the owner of org2 4) Roles are assigned on the tenant of org1 to the org2 5) The above means that org2 might NOT be SU on org1's tenant 6) Steps 4) and 5) might be repeated for any entity in the tenant of org1. 7) Note that this is entirely doable using accounts mechanisms. 8) Might require "translation" from the ID of an accounts resource to an URL of the "real" entity in the component's REST or in the UI. * Adding user to an org: 1) User is registered normally 2) Org is registered normally 3) User is added to the org (using some accounts mechanism) 4) This means the user has SU on the tenant of the org (because org is SU on the tenant) 5) This also means that the user might not be SU on any of the org's sub-orgs. * Assigning operations to roles: 1) This is entirely in accounts. Each component defines a set of operations that can be invoked. The operations then can be added to roles. This also puts constraints on the possible names of the operations (i.e. they should probably be prefixed by the component name). * Listing tenants: 1) No-one has the "full picture" 2) Listing tenants is equivalent to listing the user along with the orgs they're member of (singular "they" to be politically correct - don't you love English? ;) ). 3) Operations on the individual tenants depend on the roles the user has on the corresponding orgs. K, to not make this email even longer, I'll stop here. Does the above sound reasonable? What can be simplified or staged to later versions? What is/is not supported in the current accounts impl and UI? Cheers, Lukas