User Restriction Filters

Purpose

User Restriction Filters are something less than proper access control lists (ACLs) but are designed to accomplish a subset of goals that ACLs can accomplish. Unlike true ACLs, this mechanism does not stop a user accessing data that she should not be able to access. Instead, it hides that data by default in list views but allows a savvy user to access the data by its specific identifier.

The use case is for an OpenNMS system that manages resources across many knowledge domains that have specialized groups of operators who use OpenNMS. For instance, a triple-play provider may wish to show only voice resources to operators who support the voice offering; only video resources to video support operators; and only data resources to data support staff.

Configuration

Enabling the Feature

User Restriction Filters are globally disabled by default. To enable them, edit OPENNMS_HOME/etc/opennms.properties and set:

org.opennms.web.aclsEnabled=true

You must restart OpenNMS for this change to take effect.

Every user must belong to at least one group

If you enable this feature, make sure that every OpenNMS web user is a member of at least one group. If a user is not a member of any groups, she will receive an error message upon logging in to the web UI.

Configuring the Feature

In OpenNMS versions that support this feature, the web user group editor (Admin -> Configure Users, Groups, and Roles -> Configure Groups) has controls for assigning one or more surveillance categories (aka node categories) to the group. The users assigned to a given group will have their view filtered to include only resources from nodes that are members of the surveillance categories assigned to that group.

Caveats and Warnings

• As noted under Purpose, this feature is not an implementation of full ACL security for a web application. This feature is a data protection feature and not a view protection feature. Access to all menus and URLs (other than those only authorized by the admin and provisioning security roles) are not controlled by this security model. However, the data visible in each view is restricted by this feature. In other words, you will not be able to prevent users for accessing the Alarms browser but they will only be able to see alarms authorized by their Group based ACL membership.

• • The 1.10 implementation is identical from a configuration standpoint, but has been enhanced to provide what should be proper ACLs (e.g. a clever user cannot circumvent the protections simply by changing parameters in the URL) but as of August 2012 lacks exhaustive unit tests, so it's still unadvisable to rely on it in critical environments.

• If you enable this feature, make sure that every OpenNMS web user is a member of at least one group. If a user is not a member of any groups, she will receive an error message upon logging in to the web UI.