...
- As illustrated in the above access flow, the access checks get invoked when the resource Ids in the API Cmd are annotated.
- Thus we will have to edit all existing API Cmds and add the relevant @ACL annotation on the primary resource Ids the command operates on.
- For any other resources that the command works with, the current access checks placed in the service layer will invoke the SecurityChecker.
- These current access checks pass the AccessType whereever needed or mostly pass null. Our SecurityChecker will interpret null as a 'Read' access. In the 'acl_permission' schema, all List* APIs will be marked as 'Read' AccessType entries to facilitate this access check.
Creating Custom Group and Policy
Consider following example:
...
- createAclGroup('Service Desk', 'Service Desk group', $domainId of the admin)
- createAclPolicy('Read Only Access', 'read only access to domain resources', $domainId of the admin)
- createAclPermission('ListVirtualMachine', 'Allow', 'Domain', $domainId, 'VirtualMachine')
- createAclPermission('ListVolumes', 'Allow', 'Domain', $domainId, 'Volume')
- addAclPermissionToAclPolicy( UUID of the 'Read Only Access' policy, List<String> permissionIds of above permissions)
- attachAclPolicyToAclGroup (groupId, policyId)
- addAccountToAclGroup(groupId, List<String> accountIds)
What should be the method of ‘creating a custom Policy/Role’?
As seen above, creating a custom policy and attaching it to the group/account involves multiple API calls. Also user has to add a permission entry for every single API that should be allowed.
So if user wants to allow alla ctions, there will be 300 'createAclPermission' calls involved.
Which method should we pick? Pending PM decision.
- Should we add a UI piece to ease this operation? Should UI be CCP only?
- Should we facilitate this using a config file and a policy language definition? The user can upload the file and CS should read the input and generate the policy objects?
- Should we let the user make multiple API calls for phase 1?