[Hawkular-dev] Inventory authz workflows in Hawkular SaaS

[Lukas Krejci]

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