Last active
June 20, 2017 00:26
-
-
Save jhamon/9e436395b385daf1e0eccb154129de0d to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# We're going to introduce a resource-type for the acl-service: bind-permission | |
# The urn for these bind-permission resources looks like: urn:bind-permission:{resource-type}/{resource-namespace} | |
# --> This allows the user to creating a role binding to a role containing an entry that might | |
# look like: urn:{resource-type}:/{resource-namespace} | |
# We plan to update the acl-service proof of concept to ensure the caller of our api has access control entries | |
# ("permission of permission") granting them permission to bind roles of a given type and resource. The acl-service | |
# will find the userId in the bearer token accompanying the request to ensure they have the bind-permission | |
# needed to perform the requested actions in the acl-service. | |
# An example: urn:bind-permission:/bind-permission/app/* | |
# An ACE for this resource urn might be created when binding the CC Admin role. A CC admin would then be | |
# able to create a role binding to a role like org_manager, which authorizes binding permissions on app:/* | |
# The ability to delegate bind-permission comes from having bind-permission in both the resource-type and | |
# resource-path segments of the urn. This is because the resource path portion of the urn is used to determine what | |
# ACE entries may be created during a role-bind. | |
# System creates the superadmin role on startup and binds it to any user IDs bootstrapped through application.yml | |
# Users bound to superadmin can create/delete new roles through the api. | |
{ | |
"name": "superadmin", | |
"resourceActionTemplates": [ | |
{ | |
"resource": "urn:role:/*", | |
"actions": ["create", "read", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/*, | |
"actions": ["*"] | |
} | |
] | |
} | |
# A superadmin can create a CC Admin | |
# CloudController Admin can create/delete role bindings for other CC-roles | |
POST /roles | |
{ | |
"name": "cc_admin", | |
"resourceActionTemplates": [ | |
# Administration in allowing Admins to create role bindings for OrgManager or SpaceManager | |
{ | |
# Here we give an CC-Admin the ability to create a binding to a role (i.e. OrgManager) containing bind-permissions to app:/* | |
"resource": "urn:bind-permission:/bind-permission/app/*, | |
"actions": ["read", "create", "delete", "update", "run"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/bind-permission/space/*, | |
"actions": ["create", "read", "update", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/bind-permission/org-quota/*", | |
"actions": ["create", "read", "update", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/bind-permission/space-quota/*", | |
"actions": ["read"] | |
} | |
# Whatever non-administrative permissions a CC Admin has in CC | |
{ | |
"resource": "urn:app:/*", | |
"actions": ["read", "create", "delete", "update", "run"] | |
} | |
] | |
} | |
# Example CC Role - Org Manager | |
{ | |
"name": "org_manager", | |
"resourceActionTemplates": [ | |
# Administration in allowing Org Managers to create role bindings for "SpaceManagers" | |
{ | |
# Here we give an OrgManager the ability to create a binding allowing a user (the SpaceManager) to bind other users to app:/org-guid/* | |
"resource": "urn:bind-permission:/bind-permission/app/{org-guid}/*", | |
"actions": ["read", "create", "delete", "update", "run"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/bind-permission/space/{org-guid}/*", | |
"actions": ["create", "read", "update", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/bind-permission/org-quota/{org-guid}/*", | |
"actions": ["create", "read", "update", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/bind-permission/space-quota/{org-guid}/*", | |
"actions": ["read"] | |
}, | |
# Administration in allowing Org Managers to create role bindings for "SpaceDevelopers" | |
{ | |
"resource": "urn:bind-permission:/app/{org-guid}/*", | |
"actions": ["read", "create", "delete", "update", "run"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/space/{org-guid}/*", | |
"actions": ["create", "read", "update", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/org-quota/{org-guid}/*", | |
"actions": ["create", "read", "update", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/space-quota/{org-guid}/*", | |
"actions": ["read"] | |
}, | |
# Whatever non-administrative permissions a Org Manager has in CC | |
{ | |
"resource": "urn:app:/{org-guid}/*", | |
"actions": ["read"] | |
} | |
] | |
} | |
# Example CC Role - SpaceManager | |
{ | |
"name": "space_manager", | |
"resourceActionTemplates": [ | |
# Administration in allowing Space Managers to create role bindings for "SpaceDevelopers" | |
{ | |
"resource": "urn:bind-permission:/app/{org-guid}/{space-guid}/*", | |
"actions": ["read", "create", "delete", "update", "run"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/space/{org-guid}/{space-guid}/*", | |
"actions": ["create", "read", "update", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/org-quota/{org-guid}/{space-guid}/*", | |
"actions": ["create", "read", "update", "delete"] | |
}, | |
{ | |
"resource": "urn:bind-permission:/space-quota/{org-guid}/{space-guid}/*", | |
"actions": ["read"] | |
}, | |
# Whatever non-administrative permissions a Space Manager has in CC | |
{ | |
"resource": "urn:app:/{org-guid}/{space-guid}/*", | |
"actions": ["read"] | |
} | |
] | |
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are basically looking at securing two end-points /roles and /role-bindings
For roles, the following authorization decisions need to be made
Could be kept simple for MVP. But vet this with customers based on their custom role requirement.
For binding a Role to a User and a Resource Context , the following authorization decisions need to be made