[Hawkular-dev] Inventory authz workflows in Hawkular SaaS

Tue May 12 05:34:21 EDT 2015

Correct. If the name is not appropriate, I'm accepting suggestions :-)

> * 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

I assume you mean a tenant on the inventory side.

> 5) The above means that both the org and the user that created it
> have SU on the new tenant

Same as above. But correct, if you mean "tenant" on the inventory side.

> * Adding org2 under org1:

On the F2F, we agreed on removing this capability from the UI on a
first step, to avoid unnecessary complexity. I'd suggest to also not
support such scenario *now* on inventory. Let's see where it leads us
and refactor appropriately once we have this actual need, instead of
spending a lot of time implementing a feature that would benefit only
a limited number of cases.

> * 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)

If I understand this flow correctly, you mean that an existing user
account is added to an existing organization, which is owned by a
third user. If so, your assumption is then incorrect.

Case: jdoe creates an org called "Acme, Inc" and invites user jsmith
to the organization. During this invitation process, jdoe assigns the
role "Monitor" to jsmith.

> 5) This also means that the user might not be SU on any of the
> org's sub-orgs.

Invalid, as we are removing 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).

Sort of. This is done by the component, using Account's API.
Basically, you have to tell accounts what are your operations and
which roles are allowed for each operation. More details here:

https://github.com/hawkular/hawkular-accounts#operations-and-roles

Sample code:

http://git.io/vUzub

*How* you implement this is up to you, but I'd suggest to do it as a
ServletContextListener , so that we can control the order of the
initializers on Kettle via web.xml.

> * Listing tenants: 1) No-one has the "full picture"

I assume you mean: "list of all tenants". If so, you are right.

> 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? ;) ).

Correct.

> 3) Operations on the individual tenants depend on the roles the
> user has on the corresponding orgs.

Correct.

> 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?

Pretty much all of the above is already implemented in the current
accounts code. On the UI, it's very limited, as we need some UXD love.

I tried to document as much as I could at several levels: a bigger
picture can be read on both the readme files and on the website. The
specific "contracts" can be checked on the javadocs. And future
features/existing bugs are in JIRA :)

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

iQEcBAEBCAAGBQJVUckdAAoJECKM1e+fkPrXt8wH/0n+XOgvKltpRYXCNnjbvqFh
V/0CUmQYG4fSIYElMNth0m3ktPJI19Kxh6SZj1Pw7JKs6wD6ZvjuikeUy1ALpDS7
94zstCO7AmzAdrUgUw8/T3svP/lWmuOUR3xiCsOW+3pKHAgnX3YInFclKSZnNlF1
TI47zFlSSdJ6neuyt+nn41nNqVfwkeRD9/oMbK+R2b5f0w4IHYpZu9iKRAnbG0Ks
GwPCWj0ICkgTL0MZUd4vjC6RTJ2xjlvtgqS2cLtM6YHRwoivoZTYHvX+JGg5zwQI
r7wFEXIh0zZyiJ2Liccb7DJVNElFln9zyZqyfQro7couKNWhtOwzJ2zHdQBKS2g=
=KDmX
-----END PGP SIGNATURE-----