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:

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:

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.

 

 

 

 

 

 

(c) 2013-2025 Altair Engineering Inc. All Rights Reserved.

Intellectual Property Rights Notice | Technical Support