This post documents good practices to limit access to your Web Client plugins to specific users.
Once installed Web Client plugins are visible to all users by default:
- Home shortcuts and global views are always visible
- vSphere object’s views added by the plugin are visible to users who have read access to those objects
- Plugin actions on vSphere objects are accessible to the same users
- Inventory nodes and custom objects added by the plugin are visible to all users.
The two main techniques to limit access are filtering extensions in plugin.xml and adding your own filtering code. Filtering extensions is the easiest by the mean of small xml snippets in plugin.xml for the extensions of your choice: views, actions, inventory nodes, shortcuts. Custom filtering code is necessary for more fine-grained control and also to restrict the data to be displayed.
1) Extension filtering in plugin.xml by user privilege
You can filter extensions to only appear for users that have specific privileges. You can base your filter on global privilege settings in the vSphere Web Client. For example, you can use a filter to make your extension available only to users that have global privileges to change settings. You can also filter your extension based on privileges related to specific types of vSphere objects. For example, you can use a filter to make your extension available only to users who have privileges to create or delete Datastore objects.
Filtering works by adding a <metadata> and <privilege> element inside your extension definition as follows:
<extension id=“...”>
<extendedPoint>...</extendedPoint>
...
<metadata>
<privilege>[comma_separated_list_of_privilege_names]</privilege>
</metadata>
</extension>
vSphere pre-defined privilege names are the ones defined in the vSphere Management SDK (see this reference for 5.5), they are not the user-friendly privilege names displayed in the Web Client under Administration > Access Control > Roles! For instance the privilege name to delete a Datastore is Datastore.Delete, not “Remove datastore”.
You can also use your custom privileges. See the vSphere API for information on creating privileges.
2) Extension filtering in plugin.xml by property values
For a more dynamic approach you can filter your extension depending on the value of a property of the selected object. You must use the property value filter in conjunction with the object type filter.
To restrict access to an extension for a particular object you need to define a custom property as in the following example where we use the property VmActionVisible to hide a menu action defined on VMs:
<extension id="...">
<extendedPoint>vise.actions.sets</extendedPoint>
<object>
<actions>
...
</actions>
</object>
<metadata>
<!-- objectType filter to apply this extension only to VM objects -—>
<objectType>VirtualMachine</objectType>
<!-- propertyConditions filter to check the value of the VmActionVisible property -—>
<propertyConditions>
<com.vmware.data.query.CompositeConstraint>
<nestedConstraints>
<com.vmware.data.query.PropertyConstraint>
<propertyName>VmActionVisible</propertyName>
<comparator>EQUALS</comparator>
<comparableValue>
<String>true</String>
</comparableValue>
</com.vmware.data.query.PropertyConstraint>
<com.vmware.data.query.PropertyConstraint>
</com.vmware.data.query.CompositeConstraint>
</propertyConditions>
</metadata>
</extension>
The value of VmActionVisible will be computed in your plugin’s PropertyProviderAdapter which is queried by the Web Client data service when the menu is displayed. Your adapter code is responsible for authorizing the current user to view or not the menu. See also (4) below.
Note: <propertyConditions> may contain several PropertyConstraint element combined with an AND or OR clause. In general it’s easier to use only one custom property and leave the complex logic in the adapter code.
3) Custom filtering in your Flex/HTML plugin code
The previous two sections were about preventing extensions from appearing to non authorized users. The next level is to limit what they can do within an extension itself.
For instance instead of making an action extension invisible you could let all users see it but block some users within the action implementation. In order to check privileges in your UI code (Flex or Javascript) you can make a java service call and have your plugin java service call the vSphere API in turns. If your logic doesn’t rely on privilege checks you are free to do other things of course.
Note: it is not possible to hide extensions programmatically in Flex or Javascript, you can only control the content or behavior of an extension which is defined in plugin.xml.
4) Custom filtering in your Java plugin code
Section (2) gives an example of dynamic filtering based on object properties. See the Data Service section of the Programming Guide and the various SDK samples to understand the implementation of PropertyProviderAdapters and DataProviderAdapters.
Another common use case is to restrict the data your adapters are returning based on specific user status. For instance if you are adding custom objects to the inventory (like in the Chassis samples) you can easily have your DataProviderAdapter perform addition logic to return data only for the right users. Everybody else will see 0 objects and won’t be able to open any view.
Here is the reference to the vSphere Management SDK section on Authentication and Authorization:
http://pubs.vmware.com/vsphere-55/topic/com.vmware.wssdk.pg.doc/PG_Authenticate_Authorize.8.1.html