SAML 2.0 is not precluded with this design, it seems. 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 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? Are there roles, or even a default role? What is envisioned for Phase 2, 3Š 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" <terbol...@gmail.com> wrote: >On Tue, Jan 21, 2014 at 10:57 PM, Prachi Damle ><prachi.da...@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+Identit >>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
