cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Damle <Prachi.Da...@citrix.com>
Subject RE: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
Date Wed, 22 Jan 2014 00:42:50 GMT
Some answers inline.

Prachi

-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com] 
Sent: Tuesday, January 21, 2014 4:20 PM
To: dev@cloudstack.apache.org
Subject: Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)

SAML 2.0 is not precluded with this design, it seems.
>>[Prachi] Yes this design does not include the SAML 2.0 support
I found the FS both confusing and illuminating. I think what confuses me is the interchange
of 'acl', 'iam' and 'policy'.
Especially since ACL is used in the networking context.

IMO, renaming the tables and APIs to not use ACL but IAM would clarify matters.
For example:
Tables: iam_policy, iam_policy_permission, iam_group
API: createIAMGroup createIAMPolicy createIAMPermission addIAMPermissionToAclPolicy attachPolicyToIAMGroup
addAccountToIAMGroup (or better, house the api under the client/iam/?command= sub-url)
Annotation: @IamPolicyCheck

>>[Prachi] I guess yes to avoid confusion, given that the term ACL is already used in
networking context, we can stick to using 'iam' and rename our APIs/annotations 


Also, there is no reference to what one would normally find in an IAM user
guide: Principal, Role, etc.
Am I right in assuming that Account is the Principal here? 
>>[Prachi] yes, CloudStack Account is analogous the IAM term Principal . As mentioned
all the permission controls are done at the CS Account level.

Are there roles, or even a default role?
>>[Prachi] There is no 'role' entity. We are using the IAM Group-Policy-Permission model.
The current default roles of CloudStack (user,admin,domainAdmin) will be translated into default
policies as mentioned in the FS 'Default Policy' section.  These will be loaded as metadata.


What is envisioned for Phase 2, 3Š
>>[Prachi] 
- Firstly some easier way of creating custome policies and permissions. The current FS does
not include any UI/tool to create custom policies - all is API based for first phase.  
- Also, based on earlier suggestion from the community, a JSON based policy structure will
bring in more flexibility.
- SAML 2.0,identity federation to be considered

Ideally, this is a separate service that can be enhanced by 3rd parties.
As an example, I want to provide my DBaaS service on an ACS-powered cloud.
I want to utilize the same Principals (and IAM infrastructure) rather than provide my own.


--
Chiradeep



On 1/21/14 2:01 PM, "Erik Weber" <terbolous@gmail.com> wrote:

>On Tue, Jan 21, 2014 at 10:57 PM, Prachi Damle
><Prachi.Damle@citrix.com>wrote:
>
>> Min and myself would like to propose an identity and access 
>> management plugin for CloudStack for the ACS 4.4 release.
>>
>> Here is the functional spec we have drafted for the first phase:
>>
>> 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Iden
>>tit
>>y+and+Access+Management+%28IAM%29+Plugin
>>
>> Currently CloudStack provides very limited IAM services and there are 
>> several drawbacks:
>>
>> - Offers few roles out of the box (user and admin) with prebaked 
>> access control. There is no way to create customized policies and permissions.
>> - Some resources have access control baked into them. E.g., shared 
>> networks, projects etc.
>> - We have to create special dedicateXXX APIs to grant permissions to 
>> resources.
>> - Also it does not provide the flexibility to integrate with other 
>> RBAC implementations say using AD/LDAP
>>
>> Goal for this feature would be to address these limitations and offer 
>>true  IAM services in a phased manner.
>> As a first phase, we need to separate out the current access control 
>>into  a separate component based on the standard IAM terminologies. 
>>Also we need  to create an access check mechanism to be used by the 
>>API layer to avoid  the checks scattered over the api/service layer. 
>>The read/listing APIs need  to be refactored accordingly to consider 
>>the policy based access granting.
>>
>> Please provide feedback/suggestions anyone has.
>>
>>
>
>Would love to see SAML 2.0 support, but any IAM solution is a good 
>start
>:-)
>
>--
>Erik Weber


Mime
View raw message