...
- 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 'UseEntry' access. In the 'iam_permission' schema, all List* APIs will be marked as 'UseEntry' AccessType entries to facilitate this access check.
Example: Creating Custom Group and Policy
Consider following example:
...
- createIAMGroup('Service Desk', 'Service Desk group', $domainId of the admin)
- createIAMPolicy('Read Only Access', 'read only access to domain resources', $domainId of the admin)
- createIAMPermission('ListVirtualMachine', 'Allow', 'Domain', $domainId, 'VirtualMachine')
- createIAMPermission('ListVolumes', 'Allow', 'Domain', $domainId, 'Volume')
- addIAMPermissionToIAMPolicy( UUID of the 'Read Only Access' policy, List<String> permissionIds of above permissions)
- attachIAMPolicyToIAMGroup (groupId, policyId)
- addAccountToIAMGroup(groupId, List<String> accountIds)
What should be the method of ‘creating a custom Policy/Role’?NOTE:
For this release, creating a custom policy/group is supported through API only. For further releases, we can provide either a UI or a config file + policy language mechanism to facilitate the custom policy/group creation.