Mapping Users to Roles

Depending on the authentication or user management mechanism used, the role that a user should have is specified and then mapped to a group set in Streams.properties.

Property	Description	Default Value
access.administrator.groups	The role that is mapped to the administrator group. Allowed to perform the following: Connect to or disconnect from the CEP Engine. Create, rename, remove folders and subfolders, upload applications or data sources, and manage users or groups that should be granted or denied access. Import and export application bundles. Rename, view topic or data source usage, move, copy, download, remove, and publish/republish applications to folders to which the user has permission. Rename, view application usage, move, copy, download, and remove data sources. Administer the server which includes: Refresh, start, and stop data producers. View engine metrics and retrieved messages. Add, modify, refresh, and delete parameters. Define file logging level or view, pause, resume logging, copy, and clear all logs View Kafka properties. Reload configuration. Create, modify, and delete clear topic data tasks.	admin
access.default.roles	The default roles applied to all users of the server. For example, if access.default.roles=DESIGNER,ADMINISTRATOR and a user with a VIEWER role logs on to the server, then the user will simultaneously have a VIEWER, DESIGNER, and ADMINISTRATOR roles. However, if no default roles are wanted, then leave the property blank. NOTE: The roles that can be assigned in this property can only be ADMINISTRATOR, VIEWER, ANONYMOUS, and/or DESIGNER. This property is case sensitive.	VIEWER
access.designer.groups	The role that is mapped to the designer group. Allowed to perform the following: Import and export application bundles. Create, rename, remove folders and subfolders, upload applications or data sources, and manage users or groups that should be granted or denied access. Create, rename, view topic or data source usage, move, copy, download, remove, and publish/republish applications to folders to which the user has permission. Create, rename, view application usage, move, copy, download, and remove data sources.	designer
access.viewer.groups	The role that is assigned to the viewer group. Allowed to view the engine status.	viewer

NOTE: Group sets can be added for a role, by default separated by a comma.

Normally, you should use role mapping to control user access. This way you can manage access in the same place that you manage your users without having to reconfigure the server.

In some scenarios, it may be impossible to set up appropriate roles for Panopticon in your external system, or you may want to make one-off exceptions for specific users. As a workaround for these cases, you can also explicitly list individual users and their access in the server configuration with the access.administrator.users, access.designer.users, and access.viewer.users properties.

Example role mapping settings:

access:
administrator.groups: pano-admins, managers
administrator.user: cto@company.org
designer.groups: pano-editors, pano-reviewers
viewer.groups: pano-users
default.roles: VIEWER

In an organization where only selected users should have access to Panopticon, you have two options:

The authentication approach (preferred)
Configure the authentication layer so that only authorized users are let in. For example, with LDAP, use an OU in your user-dn-patterns that only have Panopticon users as members, or with OAuth, assign only these users to the application.
The content access control approach (fallback)
Change the permission of the Panopticon content root folder so that the group names associated with the viewer and designer roles have access and remove the permissions for Everyone.

NOTE: Users that are administrators always have full access to all folders.

Intellectual Property Rights Notice | Technical Support