Building on the series of blogs for Application Templates, we have seen how simple it is to use the framework and deploy applications in production and manage them. Last blog discussed the superior single screen view we provide (/blogs/2011/10/20/complete-application-view-from-single-screen/).

As we notice many benefits and features of this framework, you will be wondering about the system level access and security for the applications deployed through templates. In simple terms we call this Role Based Access Control on NetScaler and all the built-in roles do apply to Application Templates as well.

  • Read-only: Read-only role provides access to all show commands except show runningconfig, show ns.conf, and the show commands for the NetScaler command group. Thus with this level of access you can only view the Application deployed.

 

  • Operator: Operator role provides access equivalent to read-only privileges and additionally access to commands to enable and disable services and servers or place them in ACCESSDOWN mode. Thus with this role as well you will be able to view the Application deployed and take smaller actions.

 

  • Network: Network role provides read as well as write level privileges, except to the set and unset SSL commands, sh ns.conf, sh runningconfig, and sh gslb runningconfig commands. From Application Template view this user can perform all the read and write operations.

 

  • Superuser: The role which provides full access to the system and Application Templates without any restrictions.

 

This is certainly good for system and App level access management but there is more you can do for Application Templates. From core thought process and designed framework, Application Templates were always kept closer to Application admins than your system or network admins. Once you start deploying more and more applications the requirement to control admin rights at application level will become crucial and Application Template module provides great support for this task.

For any deployed application, you can right click and select “Manage Permissions”.

This opens up the window where you see all the system level and application level groups and users.

This interface provides ability to quickly take actions like:

  • Creating User
  • Removing User
  • Modifying User

 

The best aspect is that it lets you drag-n-drop users from one bucket to other one.

As you see we got the “OWAAdmin” and “SharePointAdmin” users to the application bucket and have setup the “Deny” privileges for OWAAdmin on this application. Once the application level access is set to deny, this user will not be able to even view the application. Thus it is a simple interface which lets you control which user should have access rights to application. In scenarios where you have multiple applications deployed and you have different administrators for each, this kind of functionality will be highly useful.

In the core of system, this application level control framework uses our command policies for access control. The flexibility in setting up command policies is amazing which makes them special for such use cases.