Add Permissions to Role Wizard

The Add Permissions to Role Wizard guides you through the process of defining permissions for specific entities to be added to a custom role.
Add Permissions to Role Wizard
guides you through the process of defining permissions for specific entities to be added to a custom role.
This wizard appears when you add permissions to a role when it is created or edited.
It is important to approach your permissions with a clear goal in mind. There are many possible object permutations using this wizard. This can result in fairly complex permission groups being created. See Understanding Role Permissions for examples on how your permissions from this wizard are translated into permission groups that appear in the Manage Roles dialog and for useful hints and tips.
Step 1: Permission Options
This step of the wizard lets you choose the options for the permissions.
Complete this step as follows:
  1. Choose the entity types to which the permission applies:
    • All entity types:
      Permission will apply to all entity types in the system.
    • The selected entity type
      : Permission will apply only to the entity type that you select from the drop-down list (for example, "Assertions").
      Be sure to read "Hints and Tips for Role Permissions" under "Understanding Role Permissions" for information about various entity types that may not be immediately obvious.
  2. Specify the scope of the entity type to include:
    • All objects of the specified type:
      All objects of the specified entity type will be included (for example, if "Assertions" was chosen, then all assertions in the system are included). With this option, Step 2 of the wizard is disabled and clicking
      ] proceeds to Step 3.
      Choosing the "All objects..." scope will permit the selected operations on the entity regardless of the state of the entity (for example, regardless of the zone or folder that the object may be in).
    • Objects matching a set of conditions:
      Create a set of conditions in Step 2 to choose the objects to include. Depending on the entity type selected, the available scope options will change.
    • A set of specific objects:
      Choose the individual objects yourself in Step 2.
  3. Select at least one permitted operation:
    • Create
    • Read
    • Update
    • Delete
For a description of each operation, see Understanding Role Permissions.
It is highly recommended to always include the "Read" permission in conjunction with the other permissions.
Step 2: Object Selection
This step is used to specify the conditions for choosing the objects or to choose specific objects directly, depending on what was selected in Step 1.
Step 2 is skipped if "All objects of the specified type" was chosen for the "Restrict scope to" option.
Specifying by Conditions
The conditions are arranged in a series of tabs. Configure each tab as necessary to construct a rule that precisely targets the objects you are seeking.
If your chosen entity type can be further classified into specific types, this tab will be displayed to let you choose the type.
The [
] tab is most commonly used for audit records, where permissions can be set individually for each of the three audit record types.
Only "Message" audit records can exist in security zones. This could have an impact on the functionality on the [
] tab.
This tab lets you specify the objects by name, ID, or other attributes specific to your chosen entity type to be included in the permission group (the attributes available depend on the entity type). At the top is a list of criteria that have been defined. You may remove any entry by selecting it and clicking [
The "Criteria specification" section at the bottom is where you construct your criteria list:
  1. Choose the
    that you wish to search by.
  2. Specify the
    starts with
    means any attribute beginning with the specified value is matched;
    requires an exact match of the value.
  3. Enter the
    to match against.
  4. Click [
    ] to add the criteria set to the table at the top.
    Selecting objects by attributes is designed for advanced users or for use under the direction of Support. The following tips are not immediately obvious:
    • When selecting by assertion name, use the
      full class name
      for the assertion. For example, to grant Read access to all assertions in the Policy Manager using a name attribute, select "Assertions" for the entity type and then add the attribute:
      name = com.l7tech.policy.assertion.composite.AllAssertion
      . CA recommends specifying by manual selection wherever possible to reduce the possibility of error. (For example, using the above example you would choose "Assertions" as the entity type and "A set of specific objects" as the scope. Then in Step 2, click "select all" to include all the assertions.)
    • The entity type "Policies" can be further refined by setting operations for each specific type of policies: Global Policy Fragment, Included Policy Fragment, and Internal Use Policy.
      (1) Use the comparison operation "starts with"and then enter the value "Global", "Included", etc., to avoid having to type out the entire label. (2) The values are case sensitive, so "Global" works, but "global" does not. (3) To reference the standard service policy, use "Private Service Policy".
    • When selecting objects using the Attribute "type", each row in the permissions table corresponds to an "OR" logic, while each scope (comma separated) item corresponds to an "AND" logic. Be careful to not create a list of comma-separated items that are impossible to meet. For more information, see Understanding Role Permissions.
This tab lets you narrow down the access to objects within specific folders. All the folders to which you currently have read access are displayed. Select the folder(s) that should be part of the permission group. Folders at the root are denoted by "/". The root folder itself is denoted by "(root)" as the path. You may select folders alone or in conjunction with security zones.
Only entities that can reside in folders are affected by this condition; these include: folders, services, service aliases, policies, and policy aliases.The [
] tab is visible only if you are dealing with all entities or an entity type that can exist in folders.
(1) Be aware that this tab is only used to target objects
the selected folder. It is not meant to apply the permitted operation
to the selected folder itself
. To do this, select the "Grant access to all necessary folder" check box. (2) If there are many items in a table, you can type a few characters in the "Filter on..." box to filter the by the condition.
You can further refine folder access with these options:
  • Apply to objects in all subfolders:
    Select this check box to include all objects residing in subfolders of the designated folder. Clear this check box to include only the objects residing in the designated folder.
  • Grant read access to all necessary folders:
    Select this check box to automatically grant access read access to the selected folder and all ancestor folders of the designated folder, if the user does not have access already. If "Apply to objects in all subfolders" is also selected, read access to all subfolders below the designated folder is also granted. Clear this check box to not have the system grant this implicit access—you are then responsible for ensuring that users can access the folder tree.
    Consider this folder hierarchy:
    root > Folder A > Folder B > Folder C
    . You create a permission group for "Folder C" and Sue is added to the resulting role. When the "Grant..." option is selected, Sue will be able to access the objects within Folder C regardless of her current access to the parent folders. But if the "Grant..." option is
    selected, then you must ensure that Sue has access to the root folder as well as to Folders A, B, and C, otherwise she will not be able to access Folder C regardless of the permission group.
This tab lets you specify the security zone(s) as a condition. Only objects belonging to the zone(s) selected here will be included in the permission.
Keep in mind the following:
  • The selection "<no security zone>" allows the permission group to access all entities that are
    currently assigned to a security zone. If this selection is not chosen, then entities that do not have a security zone cannot be accessed by this permission group.
  • The [
    ] tab is unavailable for objects that cannot be placed in a zone.
Specifying by Manual Selection
A list of the objects belonging to the specified entity type is shown. Select the check box next to each object to include in the permission.
To quickly locate an object in the list, enter the first few characters of its name in the "Filter on name" box.
Keep in mind the following:
  • Only the objects to which you have Read access are displayed. Because of this, it is recommended that only administrators (who have full permissions) create new permissions. This ensures that all objects are available for selection.
  • When selecting objects of type "Cluster Property", all the predefined cluster properties (that is, the properties visible in the drop-down list) will always be visible, regardless of any permissions. However, custom cluster properties (that is, properties that are set by typing in their names) may or may not be visible, depending on the your permissions.
  • When selecting objects of type "Trusted ESM User", first choose the Trusted ESM from the drop-down list. The users associated with that Trusted ESM are then displayed for your selection.
  • When selecting objects of type "UDDI Proxied Service Infos", the wizard will by default also grant additional access to the UDDI services referenced by each selected UDDI proxied service info. This is necessary because UDDI entities cannot be viewed unless the user can also read the relevant service for any selected UDDI Proxied Service.
    This only grants access to the service itself; it does not grant folder ancestry.
    Clear this check box to not grant this additional access. This is not recommended and should be selected only under the guidance of Support.
    UDDI support is deprecated in
    Layer7 API Gateway
  • The same as above applies for objects of type "UDDI Service Controls". The wizard will by default also grant access to the UDDI services referenced by each UDDI service control.
Step 3: Summary
This step summarizes the selections from the first two steps.
Review the summary carefully to ensure that this particular set of permissions is correct and then click [
] to close the wizard. If corrections are necessary, click [
] to return to the appropriate step. To view full Scope details for a permission group, select it and then click [