cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Damle <>
Subject RE: [ACS5.0] IAM feature postponed from 4.4 to 5.0?
Date Wed, 14 May 2014 17:52:16 GMT
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

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.


-----Original Message-----
From: Daan Hoogland [] 
Sent: Wednesday, May 14, 2014 12:12 AM
To: Min Chen
Cc: Hugo Trippaers;
Subject: [ACS5.0] IAM feature postponed from 4.4 to 5.0?


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

View raw message