Edge built-in roles

Each Apigee Edge organization comes with a few built-in roles that you can assign to administrative users:

  • Organization Administrator - Super user. Has full CRUD access to resources in the organization. In an Edge for Private Cloud installation, the most powerful role is the System administrator role, which also has access to system-level functions that the Organization Administrator doesn't.
  • Read-only Organization Administrator - Has read-only access to resources in the organization.
  • Operations Administrator - Deploys and tests APIs; has read-only access to other resources.
  • Business User - Creates and manages API products, developers, developer apps, and companies; creates custom reports on API usage; has read-only access to other resources.
  • User - Creates API proxies and tests them in the test environment; has read-only access to other resources.

The built-in roles control the level of access in both the management UI and the management API.

To see the permissions set for each built-in role (as an Organization Administrator or a Read-only Organization Administrator), select Admin > Organization Roles > name_of_role in the management UI.

If your organization includes Apigee Sense, the admin console will also display roles for Sense. For more about Apigee Sense roles, see Apigee Sense built-in roles.

Example role permission

The following example in the management UI shows the permissions for the User role. Notice that it has different deployment permissions:

  • /deployments URI (GET)
  • /environments/*/applications/*/revisions/*/deployments (GET)
  • /environments/test/applications/*/revisions/*/deployments (GET, PUT, DELETE)

Users role permissions for deployment, showing PUT permissions on only deployments to the test environment.

So what does this mean? What can someone in the User role deploy?

  • First, the PUT permission is what allows deployment.
  • Second, the more granular (specific) permission takes precedence where there is a permissions overlap, as there is with multiple deployment permissions here. (Precedence in permissions that overlap is described more fully in Creating roles with the API).

In this example, the most granular permission is the "Deploy API to test environment permission" with a URI of /environments/test/applications/*/revisions/*/deployments. It's the /test/ part that makes it the most specific. It means someone in the User role can deploy any API proxy (/applications/*) with any revision (/revisions/*) to the test environment (/test/).

Someone in this role, on the other hand, would not be able to deploy to any other environment, because of the GET (read-only) permission on /environments/*/, where the wildcard (*) signifies any. (The GET permission on /deployments allows the user to get deployment details with the API).

About the Developer Administrator role

When a Developer Portal is provisioned, the Developer Administrator role is added to your organization, typically with the devadmin+{org_name}@apigee.com user assigned to it. This role is used solely for the purpose of configuring the connection between the Developer Portals and your Edge organization. See Communicating between the portal and Edge.

If you want to assign the Developer Administrator role to another user account, create the account in your organization and contact support to assign the role.

Alternatively, you can create a custom role with the same permissions as the Developer Administrator role using the script described in Assign the Developer Administrator role in the Apigee Edge Drupal 8 module documentation.

The connection between the portal and your Edge organization can be viewed in Drupal under Configuration > Dev Portal > Application Settings in the Drupal admin menu (you must be logged into Drupal as an administrator). If the connection is shown as failed, you must contact Apigee Support to change the connection information. See Creating a developer portal for more.