Few of the areas of current APIs which are not compatible with a correct IAM model: A]For List APIs: 1) Current implementation of the list APIs is tied tightly with the default roles (root admin,domainadmin, regular user). 2) The List APIs do not follow the listing parameters in a standard way across board. Depending on which role is invoking the call, the logic assumes some default behavior in the given context and provides results even if some listing parameters are missing . Example: Any caller should be able to see other account's resources that he is authorized to see, only if the API is called using 'listall = true' But in case of current CS, even if listall is not provided, the Admins will be able to see this resources for some other account while for a regular user the call behaves differently.
With 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. B]For Create APIs: 1)The owner of the entities being created is implicitly derived from other entities used in the creation. Example: AssociateIpAddress from a Network, always sets the Network owner as the owner of the IpAddress acquired newly This implicit derivation will break IAM granting across accounts. Since if Account A grants her network to Account B, the IpAddress Account B acquires will still be owned by account A. So the grant does not really work. C] Impersonation: Few CS APIs accept account-domain parameters and do impersonation based on these parameters. But this is not followed across all APIs. So to support impersonation via IAM, we need to change APIs and have a standard impersonation mechanism. In order to make them compatible with IAM, we need changes to the API semantics which will break backwards compatibility for existing deployments. So we need a API version change to accommodate IAM support. Thanks, Prachi -----Original Message----- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, May 14, 2014 12:12 AM To: Min Chen Cc: Hugo Trippaers; dev@cloudstack.apache.org Subject: [ACS5.0] IAM feature postponed from 4.4 to 5.0? Min, I think everybody knows I am all for less features per release. I don't think you are making a bad call, per se. I do think we should consider if we can come up with a total picture of what 5.x would require af the api, though. Can you add to the discussion what it is that is keeping you from implementing. And what requirements you have for the 5.0 api so we can start devising the architectural guidelines for the new api. more and more calls for a 5.0 are coming up lately so let's move forward. (changing title) On Wed, May 14, 2014 at 1:53 AM, Min Chen <min.c...@citrix.com> wrote: > Hi All, > > In the past several weeks, QA has done some testing on IAM feature and > found several backward-compatibility issues. Even though Prachi and I > have tried our best to fix bugs to maintain backward compatibility, we > realized that in order to support true IAM model documented in our FS > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Iden > tity+and+Access+Management+%28IAM%29+Plugin, > we will have to make several API changes that will require us to > increment CloudStack major version. > Therefore we think that IAM feature is not ready for ACS 4.4 release, > and we would like to propose to disable it in 4.4 branch and re-enable > it later when community decides to go for 5.x. > > Thanks > -min -- Daan
