Is there a list of permissions in the finest grain for Apigee publicly available?

[#1]

For example, we are working on defining custom roles for use across our organization (i.e. so new ones can be created via automation so that roles can be scoped to specific proxies). What I'm hoping to find is something like:

/environments

GET: View list of envs

PUT: Update env

DELETE: Removes env

/environments/{env} ...

/environments/*/apipattern ...

/environments/*/applications ...

/environments/*/applications/{proxy-name} ...

etc.

I tried using the documentation at: http://docs.apigee.com/api-services/content/business-user-permissions (and the others) but it doesn't have the granularity that I'm looking for since it only describes each of those roles themselves.

What I'm unsure of is when there are permissions like: /deployments and /environments/*/applications/*/revisions/*/deployments

Since both can be used for viewing deployments, it's difficult to tell what the difference actually is without testing them manually. Thus, why I was hoping that there is some form of documentation that lists all permissions and what they do.

[adas]

@David C. Burke The RBAC (role based access control) in Apigee is built on the concept of resources. A resource is defined by giving the URI. A user should belong to a role in order to access a resource.

By default a user belonging to any role at global or organization level has access to any resource that is not defined, at global or organization level respectively.

The first thing a sysadmin would want to do is create/define resources such as ‘/securityprofile’, ‘/organizations’, ‘/resources’ , ‘/servers’ , ‘/userroles’, ‘/users’ and so on, in order to protect these resources.

Similarly, an org admin should first define resources like ‘/environments’, ‘/applications’, ‘/users’, ‘/userroles’, ‘/resources’, ‘/developers’, ‘/apps’, ‘/pods’ and so on in order to protect these resources.

Once a resource gets deleted, the resource becomes unprotected and any user at global or organization level can access the resource at global and organization level respectively.

For example a sample orgadmin permission would look like this:

GET https://api.enterprise.apigee.com/v1/o/{org}/userroles/orgadmin/permissions

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResourcePermissions>
    <ResourcePermission path="/">
        <Organization>apig</Organization>
        <Permissions>
            <Permission>get</Permission>
            <Permission>put</Permission>
            <Permission>delete</Permission>
        </Permissions>
    </ResourcePermission>
    <ResourcePermission path="/environments">
        <Organization>apig</Organization>
        <Permissions>
            <Permission>get</Permission>
        </Permissions>
    </ResourcePermission>
    <ResourcePermission path="/environments/*">
        <Organization>apig</Organization>
        <Permissions>
            <Permission>get</Permission>
        </Permissions>
    </ResourcePermission>
    <ResourcePermission path="/environments/*/virtualhosts">
        <Organization>apig</Organization>
        <Permissions>
            <Permission>get</Permission>
        </Permissions>
    </ResourcePermission>
    <ResourcePermission path="/environments/*/virtualhosts/*">
        <Organization>apig</Organization>
        <Permissions>
            <Permission>get</Permission>
        </Permissions>
    </ResourcePermission>
</ResourcePermissions>

I am not sure we allow creation of resources and then controlling the permissions of those resources, but I will check to see if there's any documentation available on the same. We may not have published anything on our public API docs site, since this is not applicable for the cloud where we control what permissions and what granularity you can achieve. If i find the list of resources that we have built in, I will try and publish that here.

[#3]

"The first thing a sysadmin would want to do is create/define resources such as ‘/securityprofile’, ‘/organizations’, ‘/resources’ , ‘/servers’ , ‘/userroles’, ‘/users’ and so on, in order to protect these resources."

What exactly do you mean by 'create/define resources ... in order to protect these resources' when you say this? Do you mean if on a specific role, say Role-Dev if I didn't want them to be able to manage userroles then I'd create something similar to the following under <ResourcePermissions> entity? Does that protect it by not giving users assigned to Role-Dev the get, put, or delete permissions?

<ResourcePermission path="/userroles">
    <Organization>my-org</Organization>
</ResourcePermission>

[sarthak]

@arghya das can you please further clarify this? Who is creating these roles like /userroles etc. and how? How are we creating these resources?

[kurtkanaskie]

From the Docs page About permission setting: "To see the resources and paths that you can set permissions on, look through the management API reference at the different resource URLs."

In other words the APIs reflect the resources and paths that can be used for custom roles.

Still it would be nice to see a concise list of resources and paths.

[#6]

Yeah, this is what we ended up doing. At the time of writing the question there were pieces of documentation missing for roles that are 'required' for a user to even function within the UI (different page navigations, etc.) Looks like this page has been updated significantly and our manual testing and findings are pretty spot on.

However, we also learned of some strange quirks imposed by the UI. Ex: On one page, if the user has edit permissions for the resources, the edit button is disabled, but if the user goes to inspector and enables the button, then they can use the edit button because they do indeed have the associated permissions. The button just didn't enable for them in HTML

But I'd still love to see a concise, but detailed list of resources that aren't based on the management API reference. Even if the older resources that we have made a our own reference doc for have since been deprecated, it would be good to know.