6:14 p.m.
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