Understand Role Permissions

When you view a role in the Manage Roles dialog, the permissions for that role are displayed in the [Properties] tab. These permissions describe precisely what access is permitted to specific entities in the system when a user is assigned to that role.
When you view a role in the Manage Roles dialog, the permissions for that role are displayed in the [
Properties
] tab. These permissions describe precisely what access is permitted to specific entities in the system when a user is assigned to that role.
Note that the Add Permissions to Role Wizard may result in the construction of multiple permission entries.
Example:
You make the following selections in the wizard:
  • All objects
  • Read, Update
  • Include Folder A
  • Include Zones A & B
  • All entities with name starting with "A"
  • ID starts with 12
This will result in these permission groups:
RU on All Entities in folder "Folder A", in security zone "Zone A", Name starts with A, ID starts with 12
RU on All Entities in folder "Folder A", in security zone "Zone B", Name starts with A, ID starts with 12
You can deduce whether a permission will result in a single or multiple permission group by the logic involved in the permission:
  • If it is technically possible for an object to meet
    all
    the conditions, a single permission group is created ("AND" logic applies).
  • If it is
    not
    possible for an object to meet all the conditions, multiple permission groups are created ("OR" logic applies).
In our example, objects can only exist in a single zone (Zone A OR Zone B), so the permission is split into two groups. By comparison, it is possible for an object to have a name that starts with "A" and an ID that starts with "12", so they remain in the same permission group.
Here is an example of the Permissions table in the [
Properties
] tab:
Permissions_table.png
When there are many entries in the Permissions table, you can type a few characters in the "Filter on type" box to filter the list by Type.
The following is a description of each column:
Column
Description
Type
This is the entity type—for example, Folders, Policies, Private Key, etc. When Type = "<ALL>", it means the privileges are applied to all entity types.
Scope
This dictates the scope of the permission for the entity type: "<ALL>" means all entities of that entity type are included, otherwise the scope is given in a straightforward description. The scope may be any of the following:
  • The specific entity affected by the permission.
  • Any entities that meet the specified comparison shown (for example, "ID equals 1234" or "name starts with 'A'").
  • A security zone name when privileges are restricted to entities in a specific security zone.
  • A path and folder name when privileges are restricted to entities in a specific folder.
Keep in mind the following:
  • If there is not enough space to show the full scope in the table, you can click [Properties] to see the complete text in a dialog box.
  • Simpler scopes are shown in the table (possibly truncated), however more complex scopes involving multiple conditions are shown as "
    <complex scope>
    ". In this case you must use the Properties button to see the scope.
  • If the entity is located in the folder tree and privileges apply to its parents folders higher up in the tree, the text "ancestors of" is added before the text.
C
Role has permission to create entities of this type.
R
Role has permission to read (view) entities of this type in the Policy Manager interface.The entity will be visible in the GUI.
Tip: Read permission is required in order to Update or Delete an entity. It is also highly recommended if Create permission is granted. (This only applies when performing these actions via the Policy Manager; does not apply when using the WS Management API.)
U
Role has permission to update entities of this type.
D
Role has permission to delete entities of this type.
O
Role has another permission not listed above. This will be displayed in a tooltip.
Tip: Only system roles can have other permissions. Currently, the "other" permission only applies to: "log-viewer" and "audit-viewer-policy".
Note the following permission type information that may not be immediately obvious for some entities:
Note:
UDDI support is deprecated in
Layer7 API Gateway
.
  • Assertions:
    Read access allows users to see assertions in the palette and use the assertion in a policy; Update access allows the security zone to be changed.
  • Service Templates:
    Read access allows users to view the service template in the Publish Internal Service Wizard and to publish an internal service using the service template.
  • Audit Records:
    Read access allows users to view audit messages within the audit viewer. Note: The user must also have Read access to the source entity for the given audit message, if applicable.
  • UDDI Service Controls/UDDI Proxied Service Infos:
    Create access allows users to publish a service to or from a UDDI registry. Read access allows users to view the UDDI details of a service published to or from a UDDI registry. Update access allows users to update the UDDI details of a service published to or from a UDDI registry. Delete access allows users to remove a service's connection to or from a UDDI registry.
  • Service Metrics Bins:
    Read access allows users to view the Dashboard. This is the only permission available. For more information, see Gateway Dashboard.
Hints and Tips for Role Permissions
  • When creating your custom permissions, be aware that services, policies, and assertions are interdependent. If you grant access to one entity type, you should probably grant at least some level of access to the other entity types where dependencies exist; otherwise, unexpected results may occur.
    Examples:
    • Keep in mind that creating a service also creates a policy.
    • All policies are wrapped within an implicit "All assertions must evaluate to true" assertion (though this does not show in the Policy Manager). This means that a role that can create a service must also have permissions to create a policy and have (at the very least) Read access to the "All assertions..." composite assertion.
    • When you publish a SOAP service, the default policy created has a Route via HTTP(S) Assertion. So this means that a publish service role must have the ability to read this assertion.
    • Roles giving access to any of the internal services must also have permissions to read all the assertions that are included in the policies associated with these services.
    • A user must have Read permission for every assertion that they wish to use in a policy. This either means granting a blanket "all assertions" permission, or creating a role that specifically includes the necessary assertions.
  • A role with permissions to Read service templates should also include permissions to Create services and policies, and Read all assertions in the template. This is necessary in order to publish an internal service (which is the primary purpose of service templates).
  • A role with permissions to Read, Create, or Update private keys must also have Read/Update permission on the keystore as well.
  • A role that includes revocation checking policies must be able to Read at least one trusted certificate. This is because revocation checking policies are accessed from the Manage Certificates dialog.)
  • Encapsulated assertions require specific role permissions. These are described under "Making Encapsulated Assertions Available in a Role" in Encapsulated Assertions.
  • Debug trace policies require specific role permissions. These are described under "Understanding the Debug Trace Policy" in Debug a Policy.
  • When creating permissions for sample messages, note that sample message are only accessible via the XPath assertions or the encrypt/decrypt XML assertions (for a complete list, see Create, Edit, Delete Sample Messages). This means that for a role with any permissions for sample message also requires permission to Read and/or Update a policy and have Read permission to the listed assertions.
  • A role that includes firewall rules must be able to Read at least one listen port. This is because firewall rules are accessed from the Manage Listen Ports dialog.
    Note:
    Firewall rules only apply to appliance (including virtual appliance) Gateways.
  • A role that includes service usage records (viewable in the Dashboard, [Cluster Status] tab, under "Service Statistics") also requires permissions to these entities: Read Service Metrics Bins; Read Published Services; Read Cluster Node Info Records.
    Note:
    It is not possible to view service usage records for services that have been deleted, as these no longer appear in the Dashboard.
  • A role that includes audit records (at least Read permission for any of the audit types) must also have Read permissions for cluster node information.
  • When creating a role that includes access to a JMS Endpoint, the system will automatically grant access to the corresponding JMS Connection. Together, these two entities make up a JMS Destination (there is no single entity type called "JMS Destination").
    Note:
    This will result in multiple permission groups—one for the endpoint and one for every associated connection.
  • When including the Trusted ESM or Trusted ESM User entity types, only the Read and Delete permissions are available. This is because it is not possible to Create or Update these entities in the Policy Manager.
  • A role that includes Policy Aliases should also have permissions to the original service or policy.
  • A role that includes full permissions (Create, Read, Update, Delete) on all objects with name starting with "custom" also needs the following permissions to work:
    • full permissions for cluster properties with "name starting with 'interfaceTags'"
    • Read permission to at least one listen port
    This is relevant only for users who need to be able to modify Interfaces, either through the Policy Manager or the WS Management API.
  • A role that includes permissions for secure passwords requires Update permission in order to create a secure password.