Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
Some questions: - Is there a concept of generic permission (any action, any resource etc.)? There shouldn't be a need to define hundreds of explicit permissions for admin account. - I think it would be good to have a notion of parent policy. This will avoid duplication of permissions. - Can you explain the permission evaluation order? What if one permission is allow and another is deny for a given resource, which is given priority and where the evaluation ends? Also what is logic to select permissions from different policies for a given request (start VM for account id 11 (belonging to domain id 1))? For e.g. if the permissions are defined like 1|start|VirtualMachine|NULL|ALL|NULL|Allow|NULL|2013-10-10 14:13:34 2|any|VirtualMachine|domain id = 1|Domain|NULL|Deny|NULL|2013-10-10 14:13:34 3|start|VirtualMachine|account id = 11|Account|NULL|Deny|NULL|2013-10-10 14:13:34 4|start,stop|VirtualMachine|account id = 12|Account|NULL|Allow|NULL|2013-10-10 14:13:34 5|any|any|NULL|ALL|NULL|Allow|NULL|2013-10-10 14:13:34 Thanks, Koushik On 22-Jan-2014, at 3:27 AM, Prachi Damle prachi.da...@citrix.commailto: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+Identity+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. Thanks, Prachi Min
Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
On 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+Identity+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. Prachi, I think that's a good idea, it would be nice to look at the AWS IAM service and map the API one2one. It would ease pain down the road if we want to serve a AWS compatible IAM. -sebastien Thanks, Prachi Min
RE: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
some questions I have: 1. Do we need groups and policies? Cant we derive group information from policy applied? ie) any user can become domain admin if he is given the right policies. 2. Can we restrict the permission to Resource Type's CRUD? permissions at api level seems to be like too much of control and information to save. - Thanks, Rajani From: Prachi Damle [prachi.da...@citrix.com] Sent: Wednesday, January 22, 2014 3:27 AM To: dev@cloudstack.apache.org Subject: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920) 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+Identity+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. Thanks, Prachi Min
Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
Hi Koushik, See my answers in line. Thanks. -min On 1/22/14 12:30 AM, Koushik Das koushik@citrix.com wrote: Some questions: - Is there a concept of generic permission (any action, any resource etc.)? There shouldn't be a need to define hundreds of explicit permissions for admin account. [Min] Out of box we will automatically create default policies for existing cloud admin, domain admin and normal user, to map to current account type. Root admin policy has defined generic permission you mentioned here. - I think it would be good to have a notion of parent policy. This will avoid duplication of permissions. [Min] CreateAclPolicyCmd api has parent policy id in the parameter, when you create a policy, you can specify a parent policy id. Internally we will copy parent policy permissions to the new policy. We don't want to create link to parent policy, since this will couple them together to avoid user from editing permission in only one policy not the other. - Can you explain the permission evaluation order? What if one permission is allow and another is deny for a given resource, which is given priority and where the evaluation ends? Also what is logic to select permissions from different policies for a given request (start VM for account id 11 (belonging to domain id 1))? For e.g. if the permissions are defined like 1|start|VirtualMachine|NULL|ALL|NULL|Allow|NULL|2013-10-10 14:13:34 2|any|VirtualMachine|domain id = 1|Domain|NULL|Deny|NULL|2013-10-10 14:13:34 3|start|VirtualMachine|account id = 11|Account|NULL|Deny|NULL|2013-10-10 14:13:34 4|start,stop|VirtualMachine|account id = 12|Account|NULL|Allow|NULL|2013-10-10 14:13:34 5|any|any|NULL|ALL|NULL|Allow|NULL|2013-10-10 14:13:34 [Min] For phase 1, our scope is to support only explicit allow permission, explicit deny will be added in next phase. The evaluation logic will be the same as AWS IAM evaluation engine. See http://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_Evalua tionLogic.html for details. Thanks, Koushik On 22-Jan-2014, at 3:27 AM, Prachi Damle prachi.da...@citrix.commailto: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+Identity +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. Thanks, Prachi Min
Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
Hi Rajani, See my answers in line. Thanks On 1/22/14 6:29 AM, Rajani Karuturi rajani.karut...@citrix.com wrote: some questions I have: 1. Do we need groups and policies? Cant we derive group information from policy applied? ie) any user can become domain admin if he is given the right policies. [Min] Yes, Group and Policy are standard IAM concepts used to perform access control which community all understand, it is better for us to follow the common standard avoid confusion for adoption. With group and policy, administrator can easily manipulate access controls in his/her organization. If there is no group, to assign permissions to a bunch of principals (in our case, accounts), admin has to assign group of policies to each principal one by one, which is tedious and error-prone. 2. Can we restrict the permission to Resource Type's CRUD? permissions at api level seems to be like too much of control and information to save. [Min] We thought of this before. But this involves a big effort for us to category each of our 300 API to classify which CRUD operation is involved in the api and on which resource type. That is not an easy refactor effort. In phase 2, we may consider figuring out a way to categorize APIs to that level. - Thanks, Rajani From: Prachi Damle [prachi.da...@citrix.com] Sent: Wednesday, January 22, 2014 3:27 AM To: dev@cloudstack.apache.org Subject: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920) 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+Identity +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. Thanks, Prachi Min
RE: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
-Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Wednesday, January 22, 2014 10:16 AM To: dev@cloudstack.apache.org Subject: Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920) Hi Rajani, See my answers in line. Thanks On 1/22/14 6:29 AM, Rajani Karuturi rajani.karut...@citrix.com wrote: some questions I have: 1. Do we need groups and policies? Cant we derive group information from policy applied? ie) any user can become domain admin if he is given the right policies. [Min] Yes, Group and Policy are standard IAM concepts used to perform access control which community all understand, it is better for us to follow the common standard avoid confusion for adoption. With group and policy, administrator can easily manipulate access controls in his/her organization. If there is no group, to assign permissions to a bunch of principals (in our case, accounts), admin has to assign group of policies to each principal one by one, which is tedious and error-prone. 2. Can we restrict the permission to Resource Type's CRUD? permissions at api level seems to be like too much of control and information to save. [Min] We thought of this before. But this involves a big effort for us to category each of our 300 API to classify which CRUD operation is involved in the api and on which resource type. That is not an easy refactor effort. In phase 2, we may consider figuring out a way to categorize APIs to that level. [Prachi] Also two more reasons to go with API names than a broader category: - It is better to follow AWS IAM design as much as possible for AWS fidelity, just as Sebastien has already pointed out. AWS IAM works with API names instead of categorization - We need to store permissions per API per group/policy anyway analogous to current commands.properties. And maintaining it in two different sets (api permissions + permissions for entity access per broader category) can make it tricky when we need to create custom policies. - Thanks, Rajani From: Prachi Damle [prachi.da...@citrix.com] Sent: Wednesday, January 22, 2014 3:27 AM To: dev@cloudstack.apache.org Subject: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920) 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+Ident ity +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. Thanks, Prachi Min
RE: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
-Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Wednesday, January 22, 2014 12:41 AM To: dev@cloudstack.apache.org Subject: Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920) On 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+Identity+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. Prachi, I think that's a good idea, it would be nice to look at the AWS IAM service and map the API one2one. It would ease pain down the road if we want to serve a AWS compatible IAM. -sebastien Thanks Sebastien, yes true, we are trying to model this as close as possible to AWS IAM (Using the API name based access granting, group-policy-permission model) Although we need to accommodate differences to be backwards compatible with the current CloudStack access control. E.g all access is linked with the account and not per user basis or the domain tree hierarchy Thanks, Prachi Min
Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
On Tue, Jan 21, 2014 at 10:57 PM, Prachi Damle prachi.da...@citrix.comwrote: 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+Identity+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
Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
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.comwrote: 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
Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
Also not clear on how the dedicateXyZ problem is being solved in Phase1 (or not). Can I (end user) create a VPC and allow user Bob to create VMs in my VPC? On 1/21/14 4:20 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: 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.comwrote: 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+Identi t 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
RE: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
Some answers inline. Prachi -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@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 terbol...@gmail.com wrote: On Tue, Jan 21, 2014 at 10:57 PM, Prachi Damle prachi.da...@citrix.comwrote: 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
