Our eDocs explain perfectly how to setup Authorization policies associated to AAA users and Groups. But in some occasions, you want to link the AD groups to a resources, instead of linking the resources to AD groups. The end result will be the same, but it does offer some additional flexibility if it comes down to management. You could call the below solution “Role Based Access” as we’ll be bundling groups into a “Role” which will be associated with a LB/CS vserver.

This is how the solution looks graphically:

To configure this we create create two Authorization Policy Labels for the Power User and the Regular Users under Security > AAA > Authorization > Policy Labels.

For each Policy Label you will have to insert a policy with a meaningful policy name, action “Allow” and expression. The key expression to use here is for example:

HTTP.REQ.USER.IS_MEMBER_OF("Group1")

More details on how to use the HTTP.REQ.USER policy expressions can be found in eDocs.  The resulting set of policy label expressions is pictured below:

Groups linked to authorization policy label

Groups linked to authorization policy label

Then we have to configure or modify an existing LB or CS vserver (Traffic Management > Load Balancing > Virtual Servers or Content Switching > Virtual Servers). Open the vserver, go to the “Policies” tab and select “Authorization”. We can now setup a default deny policy rule with “Insert Policy”. The rule we create will always match, thanks to the policy expression “true”. Default Deny policy for Authorization

And invoke an additional policy label as configured below.

The beauty of Invoking Policy Labels is that you can invoke policy labels from multiple virtual servers without having to re-create rulesets for each virtual server.  The purpose is to create an abstraction layer between your vserver objects and the policy processing. This behaviour applies to many types of policies with policy labels such as Rewriting, Compression, AppFlow, … and Authorization policies as used here.