Page History

...

• 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.