Page History

...

With this hard-coded baked logic specific to each account type, the implementation will be very hard to extend to handle true IAM usecases with customized roles introduced, since we need to define what the meaning of these parameters for those customized roles. With real IAM, the listing should follow a standard pattern and work with the list API parameters irrespective of who is the caller - the IAM policies attached to the caller should drive the results. In IAM, we have proposed the following standard semantics for these 4 parameters:

• listAll flag is always taking precedence to provide a superset of content to be filtered by other query parameters. listAll is defaulted to FALSE if not passed.

listAll = true  ---- the super set should contain all the resources that caller can READ.  (Before IAM grant introduced, READ resources will be all the authorized resources that can be seen)

listAll = false  ---- the super set should contain all the resources that caller can USE.     (Before IAM grant introduced, USE resources will be self owned resources

• isRecursive should only take effect when only domainid (but no account) is passed, it will further filter contents returned from listAll evaluation related to the provided domain. isRecursive is defaulted to false if not passed no matter whether listAll is passed or not.

isRecursive = true ---- filter the content from listAll evaluation to resources within that domain tree.

isRecursive = false ---- filter the content from listAll evaluation to resources only of that domain.

• When (domainid, account) is passed, we will just treat it another filter of content from listAll evaluation to resources owned by the given account. This is just another filter criteria, NOT some kind of impersonation. What this means is if listAll=false and account passed in is different from caller, then nothing should be returned. But current cloudstack implementation may behave differently, we need to document this change.
• We will communicate this same semantics for current fixed account type (NORMAL, ROOT ADMIN, DOMAIN ADMIN) and customized groups/roles extended from IAM. There will be no special/different hard-coded interpretation of these parameters based on different account type anymore.

Create APIs

• The owner of the entities being created is implicitly derived from other entities used in the creation. This will break granting, even if user A grants a resource to user B, the entity created by user B is still owned by user A.

...