Understanding Security Zones

Security zones is a feature on the that allows the Administrator to partition portions of the  to be managed by other administrators. A security zone is a collection of related entities (for example: services, policies, folders, trusted certificates).
Security zones is a feature on the
Layer7 API Gateway
that allows the Administrator to partition portions of the
Layer7 API Gateway
 to be managed by other administrators. A security zone is a collection of related entities (for example: services, policies, folders, trusted certificates).
Security zones extend the built-in roles to help you more precisely control who has access to what on the
Layer7 API Gateway
. Keep in mind that the
Layer7 API Gateway
 uses the "permissive" model of security access. This basically means if a user has one role that does not provide access to a certain feature but has another that role does, then access is granted.
When a security zone is created, two new roles are automatically added:
  • View X Zone
  • Manage X Zone
where "X" is the name of the security zone. You can use these roles in conjunction with the existing roles to control access.
You define a zone named "Widget A" and then add some assertions and folders into that zone. The roles "View Widget A Zone" and "Manage Widget A Zone" become available.
  • Bob has the "Operator" role, which allows him to view any entity, regardless of security zone. Bob will be able to view the items in the Widget A zone, even without the security zone roles.
  • Sue has the custom role "View any Folder where Security Zone = Widget B". This allows Sue to view any folder which as been given the Security Zone of Widget B. This does not necessarily give Sue access to the contents of the folders however—only to the folders themselves.
  • Fred has a role that allows him to view assertions that were placed in the "Widget A" zone. This means Fred will be able to work with those assertions, even without having the "View Widget A Zone" role.
  • Sally is assigned the role "Manage Widget A Zone". She now has permission to create, view, update, and delete any of the entities added to the Widget A zone. It is not necessary to explicitly grant access to these entities using any other roles.
Security zones are especially useful in controlling access to specific assertions. By placing the appropriate assertions into specific zones, you can delegate management as follows:
  • Network administrators can edit policy fragments to check things like source IP addresses.
  • Security administrators can edit policy fragments dealing with TLS and message-level encryption.
  • Application administrators can write XSL transformations and other policy logic.
    (1) Read (view) access to a security zone will make the assertion visible in the assertion palette on the interface. However Create access (to the zone) is required to save a policy containing assertions in a security zone. (2) When security zones have been implemented, you must have a "Manage X Zone" role that includes the "All assertions must..." composite assertion as well as every assertion currently in the policy (or will be added to the policy) in order to create or edit that policy.
Most entities can be placed into a security zone. Notable exceptions include the following:
  • Users
  • Groups
  • Keystore
  • Cluster properties & cluster information
  • Service usage
  • Metrics bin
  • Roles
  • Audit records for Admin and System events
  • Password policy
  • Security zones
Note the following restrictions for security zones:
  • An entity can only be in one zone at a time.
  • A security zone cannot be placed within another security zone.
The following table summarizes the security zone tasks:
Add, edit, or remove a security zone
Manage Security Zones
Add or remove entities from a security zone
Assign Security Zones
View a list of all entities within an entity type
Manage Security Zones (Entities tab)
Learn about the security zone roles
Predefined Roles and Permissions
When Security Zone Details are Unavailable
Security zones are designed to restrict access to only similarly zoned entities for a user. However due to the Policy Manager's "cumulative" nature of security roles, a user may still have access to entities outside of their security zone if that user has other roles that permit this. When this occurs, the Policy Manager will display "Current zone (zone details are unavailable)" when you attempt to view security zone information.
When you publish a service, you are assigned to the "Manage <service>" role. Among its permissions is the ability to read all identity providers in the system, regardless of security zone. Bob has a role that permits access to "Zone A" entities and there is an LDAP Identity Provider "Alpha" that is in "Zone B". Bob publishes a service and now has the "Manage <service>" role.
Prior to publishing the service, Bob is not able to see the "Alpha" entity because it is in a different zone. After publishing the service, Bob can now view the "Alpha" identity provider, however when he checks its security zone, this is displayed:
This indicates to Bob that the identity provider is in a different security zone, but that he can view it because of permissions granted by other roles.
The "Current zone (zone details are unavailable)" message may also display in rare instances where you have access to the entities
the zone, but for whatever reason you do not have Read access to zone attributes themselves (for example, name of the zone).