Policy Label

Overview

This article examines the concept of policy labels and gives a few examples of how they might be useful.

If you have ever used nFactor authentication, most likely, you have been exposed to policy labels. However, they can be used in more places. Some examples are together with responder, rewrite, and content switch policies. 

What are policy labels?

A policy label can be seen as a container where one or more policies are bound. The policy label is invoked when a policy expression is evaluated as true.

Why use policy labels?

Having the policies with the most hits as early as possible in the evaluation chain is always important. 

When you have many policies that require evaluation, it might become hard to understand the flow and see the result. It might even be risky to add additional policies if required, as you might add them incorrectly.

There is also a tiny bit of latency added when evaluating policy expressions, if you have a few policies to evaluate it doesn't matter that much, but when you have a lot of policy expressions, it might start to matter. When you start grouping policies that belong together in policy labels, you might skip evaluating many policies. If the rules are made properly, this will lower the overall resources used for policy evaluation.

Another good reason to use policy labels is if you have several policies that should be bound to several services. This will limit the number of bindings you are required to make, and it will also be easier to update all services when required, as you will only need to update the bindings within the policy label, affecting all places where it is used.

Examples

Example 1:

In this example, policy labels are used together with rewrite policies to create a simple method of scrubbing HTTP response headers from unwanted information. There are many HTTP headers that the server might set that leak a lot of information about how the server is set up. Some HTTP headers are optional and not required by the client for the applications to work properly and can be removed from the response sent.

If you use a browser and use the developer tools for the browser, you can inspect which HTTP headers are being received by a client. We have picked a few header examples that a client should normally not be able to see. Example headers to be scrubbed:

• Server
• X-Powered-By
• X-Aspnet-Version
• X-Aspnetmvc-Version

  First, create the rewrite actions that will do the HTTP header scrubbing:

add rewrite action scrubb-Server-rwact delete_http_header Server
add rewrite action scrubb-X-Powered-By-rwact delete_http_header X-Powered-By
add rewrite action scrubb-X-Aspnet-Version-rwact delete_http_header X-Aspnet-Version
add rewrite action scrubb-X-Aspnetmvc-Version-rwact delete_http_header X-Aspnetmvc-Version

add rewrite policy scrubb-Server-rwpol "HTTP.RES.HEADER(\"Server\").EXISTS" scrubb-Server-rwact
add rewrite policy scrubb-X-Aspnet-Version-rwpol "HTTP.RES.HEADER(\"X-Aspnet-Version\").EXISTS" scrubb-X-Aspnet-Version-rwact
add rewrite policy scrubb-X-Aspnetmvc-Version-rwpol "HTTP.RES.HEADER(\"X-Aspnetmvc-Version\").EXISTS" scrubb-X-Aspnetmvc-Version-rwact
add rewrite policy scrubb-X-Powered-By-rwpol "HTTP.RES.HEADER(\"X-Powered-By\").EXISTS" scrubb-X-Powered-By-rwact

Now, create the rewrite policy that will select which traffic should pass the policy label:

add rewrite policy scrubb-HTTP-headers-rwpol true NOREWRITE

Create the policy label, in this example we want the “Transform Name” to be http_res:

add rewrite policylabel scrubb-HTTP-headers-label http_res

Bind the scrubbing policies to the policy label:

bind rewrite policylabel scrubb-HTTP-headers-label scrubb-Server-rwpol 100 NEXT
bind rewrite policylabel scrubb-HTTP-headers-label scrubb-X-Powered-By-rwpol 110 NEXT
bind rewrite policylabel scrubb-HTTP-headers-label scrubb-X-Aspnet-Version-rwpol 120 NEXT
bind rewrite policylabel scrubb-HTTP-headers-label scrubb-X-Aspnetmvc-Version-rwpol 130 NEXT

Let's create a content switch where the policy label can be bound:

add cs vserver scrubb-HTTP-headers-csvs HTTP 10.1.1.1 80 -cltTimeout 180 -persistenceType NONE

Lastly, lets bind the selection policy and use it to invoke the policy label:

bind cs vserver scrubb-HTTP-headers-csvs -policyName scrubb-HTTP-headers-rwpol -priority 100 -gotoPriorityExpression NEXT -type RESPONSE -invoke policylabel scrubb-HTTP-headers-label

To reuse the same policy label for several HTTP services, you add the last policy bind with the invocation for each of the virtual servers where it is required.

If you later need to modify which HTTP headers are being scrubbed, you modify the policy label, and it will be applied to all your HTTP services simultaneously.

Example 2:

In this example, policy labels will be used to group content switch policies instead of binding all policies directly on the content switch. 

In this example, two applications are consolidated under the same content switch virtual server. 

The plex application requires traffic to some URLs to be directed to a specific load-balanced virtual server, which will handle the traffic that requires authentication and all other traffic to be sent to the normal load-balanced virtual server.

The web application is a web hosting service that only allows traffic destined for specific sites to be forwarded. They are all hosted on the same load-balanced virtual server.

First, we create the Content Switch virtual server:

add cs vserver webservices-csvs HTTP 10.1.1.100 80 -cltTimeout 180 -persistenceType NONE

add cs action plex-csact -targetLBVserver plex-lbvs
add cs action plexauth-csact -targetLBVserver plexauth-lbvs
add cs policy plex-csvs -rule "HTTP.REQ.HOSTNAME.SERVER.EQ(\"plex.example.local\")"
add cs policy plex-all-csvs -rule HTTP.REQ.IS_VALID -action plex-csact
add cs policy plex-admin-csvs -rule "HTTP.REQ.URL.STARTSWITH(\"/admin/\")" -action plexauth-csact
add cs policy plex-upload-csvs -rule "HTTP.REQ.URL.STARTSWITH(\"/upload/\")" -action plexauth-csact

Create and bind policies to the plex policy label:

add cs policylabel plex-plabel HTTP
bind cs policylabel plex-plabel plex-upload-csvs 100
bind cs policylabel plex-plabel plex-admin-csvs 110
bind cs policylabel plex-plabel plex-all-csvs 120

Creation of the content switch actions and policies for the web application:

add cs action web-csact -targetLBVserver web-lbvs
add cs policy web-cspol -rule "HTTP.REQ.HOSTNAME.SERVER.EQ(\"web.example.local\")"
add cs policy web-site1-cspol -rule "HTTP.REQ.URL.STARTSWITH(\"/site1/\")" -action web-csact
add cs policy web-site2-cspol -rule "HTTP.REQ.URL.STARTSWITH(\"/site2/\")" -action web-csact
add cs policy web-site3-cspol -rule "HTTP.REQ.URL.STARTSWITH(\"/site3/\")" -action web-csact

add cs policylabel web-plabel HTTP
bind cs policylabel web-plabel web-site1-cspol 100
bind cs policylabel web-plabel web-site2-cspol 110
bind cs policylabel web-plabel web-site3-cspol 120

Bind policies and invoke the policy labels on the content switch virtual server:

bind cs vserver webservices-csvs -policyName plex-csvs -priority 100 -gotoPriorityExpression USE_INVOCATION_RESULT -invoke policylabel plex-plabel
bind cs vserver webservices-csvs -policyName web-cspol -priority 110 -gotoPriorityExpression USE_INVOCATION_RESULT -invoke policylabel web-plabel

Note that this is a simple example to show how policy labels can be used, it could be written in different ways without using so many policies.