User access managment

In most cases, the Web Dashboard Administrator is responsible for managing user access. Access management in Web Dashboard is accomplished using one of the three access management tools:

Axway PassPort is the recommended access manager for Sentinel. It is the Axway component that handles access management in the most efficient and extensive way offering features like component self registration, LDAP connectivity, Single-Sign On, and role based access control (RBAC).

Axway PassPort

Users are defined in Axway PassPort or in an external repository (for example, LDAP). Users will have specific roles and privileges. Access can be set up relying on the predefined roles Sentinel Administrator and Sentinel Viewer or on custom roles. Custom roles can have predefined privileges and/or custom privileges.

There are several levels of control when implementing access management in Web Dashboard:

  1. Level 1: Granting Predefined Privileges relies on three predefined privileges. These privileges decide the user's overall profile and provide a level of authorization that is necessary, but not sufficient on its own.
  2. Level 2: Granting Access to Actions on Resources defines access to resources (for example, reports and dashboards). Some resources allow conditions (for example, viewing a report with a certain name).
  3. Define access to groups of objects by creating Entity objects and associating them with reports and dashboards. Link users or user groups to entities to control the access of the users or user groups to objects in these entities. For this, create a public user or user group property with the name WDUserEntity (for users) or WDEntity (for user groups) and assign it as the value, the name of the entity.
  4. Control access to data by creating variables linked to users or user groups and referring their values in SQL queries (Data dictionaries), filters and more. Public properties defined at user or group level, trigger the creation of Personalized fields in Web Dashboard.

Level 1: Granting Predefined Privileges

In PassPort, there are three predefined privileges for Sentinel:

  1. Manage Web Dashboards, access, reports and database - confers the administrator profile.
  2. Create Web Dashboards and reports - identifies content developers (for example, developers who create reports and dashboards).
  3. View Web dashboards and reports - identifies end-users who display and work with reports and dashboards.
Note   These privileges are cumulative, meaning if you assign more than one of these privileges to a user, the higher privilege will prevail.

The Sentinel Administrator predefined role, has the Manage Web Dashboards, access, reports and database privilege

The Sentinel Viewer role has only the View Web dashboards and reports privilege.

If you assign a PassPort user one or more of these three privileges, this user will have access to Web Dashboard (privileges to log in to the application), but will not have access to any action, on any resource. This level of authorization is necessary, but not sufficient for the use of Web Dashboards.

Level 2: Granting Access to Actions on Resources

At this level, appropriate privileges have to be granted to each Sentinel user. This can be done by relying on the existing predefined privileges or roles, or by creating custom privileges and roles.

To list the predefined privileges for Web Dashboard:

In the PassPort UI, under section Access > Privileges, filter the privileges in PassPort by

  • Product=Sentinel
  • Type=Predefined
  • Resource=HTML

To create your own custom privileges and roles:

  1. Browse the available resources for Web Dashboard and the actions available on these resources. You can see the list of resources in the PassPort UI, under section Administration > Products.
  2. Select the item Sentinel and in the pop-up dialog, select the Resources tab. All items listed in this dialog are the Sentinel resources. The ones starting with HTML are specific to Web Dashboard.
  3. Select a resource to see its description, available actions and its properties.

For example, the resource HTMLReport allows execution of Web Dashboard reports. It has a single action VIEW, and a single property name. When a resource has a property it means that conditional privileges can be constructed for that resource. In the case of the HTMLReport resource you can create a custom privilege restricting the access to a specific report by adding a condition on the privilege, for example name=MySpecialReport.

In comparison, other resources are more generic, for example the HTMLDashboard resource. This resource has three actions: VIEW, VIEW_DESIGN and MANAGE. A custom privilege that grants access to this resource and the action MANAGE, allows you to create dashboards. However, it will also allow the creation of other objects that are necessary for creating dashboards, (for example report, external components, and text). In this case, if you add a condition on the resource property name it will have no effect.

Sentinel Administration

Users are defined in Sentinel and belong to a group. Groups own a profile; while a profile is a set of rights. Unlike in PassPort, all rights available in Sentinel Administration are predefined. The creation of custom rights is not possible.

Similar to PassPort, there are several layers of control when implementing access management in Web Dashboard:

  1. First level access relies on the following three rights:
    • Manage Web dashboards, access, reports and database - confers full rights on Web Dashboard and is most likely, used for administrators.
    • Create Web dashboards and reports - used for developers who create reports and dashboards.
    • View Web dashboards and reports - used for end users who execute reports and dashboards.
  2. Define read and write access on object instances by creating a Workspace object, configuring it appropriately and linking it to a user or a group. To link a workspace to user or a group, create a variable with the name WDUserWorkspace (for users) or WDWorkspace (for groups) and assign it as the value the name of the workspace.
  3. Define access to groups of objects by creating Entity objects and placing in them reports and dashboards. Link users or groups to an entity to control the access of the users to objects in the entity. For this, create a variable with the name WDUserEntity (for users) or WDEntity (for groups) and assign it as the value the name of the entity.
  4. Control access to data by creating variables linked to users or groups and referring their values in SQL queries (Data dictionaries), filters and more. Variables defined in Sentinel Administration trigger creation of Personalized fields in Web Dashboard. Read more about Personalized fields here.
Note   The following variable names are reserved for setting user preferences: Language, Timezone, Home and Theme.

Custom User Exit

Just as Sentinel Administration relies on a set of predefined rights, a custom user exit has the same list that is available in Sentinel Administration, including the different layers of authorization:

Use the rights defined in the class com.axway.sentinel.common.server.user.Rights to manage user's access to Sentinel, in the isUserRightStatus(String, String) of your implementation. Specifically to Web Dashboard, the following rights apply:

  • Rights.RIGHT_WD_SUPER_ADMIN_PROFILE
  • Rights.RIGHT_WD_ADMIN_PROFILE
  • Rights.RIGHT_WD_USER_PROFILE

Use the getUserVariable(String, String) method to pass the WDUserEntity and WDUserWorkspace parameters of a user or the getGroupVariable(String, String) method to pass the WDEntity and WDWorkspace properties for a group, this links a user or a group to a Web Dashboard entity or workspace.

To control access to data, create user or group variables that will be translated as Personalized fields in Web Dashboard. For this, your user exit implementation should implement the WebDashboardPersonalizedFieldsProvider interface.

Upgrade to Sentinel 4.2.0

This information is only applicable when you upgrade from 4.1.0 to 4.2.0 and the access manager used is Axway PassPort.

For Sentinel release 4.2.0, access management in Web Dashboard using PassPort has changed. Since no automated migration is possible, when you upgrade from 4.1.0 to 4.2.0, you use the previous way of managing access. It is recommended to use the new access management mechanism, as it ensures more coherency with the other Sentinel modules and it is more powerful. In order to switch from the old access management system to the new one, two manual actions must be completed:

  1. Remove the parameter webdashboard.access.management=webdashboard from Sentinel's server.properties file.
  2. Review the changes that need to be applied to your users in PassPort:
    • Users who rely on the default PassPort roles (Sentinel Administrator and Sentinel Viewer) will automatically have access to Web Dashboard. This requires no additional action.
    • Users who rely on custom roles can log in to Web Dashboard; however, they will need to have additional privileges assigned. See Level 2: Granting Access to Actions on Resources.

Important changes when you switch to the new access management:

  • In Sentinel 4.2.0, :Workspace" is not available. Instead, you have the "Menu" and the "Public menu". The Menu can be used to customize the application menu for all users. The "Public menu" is used to make reports and dashboards publicly available.
  • Since Workspace is not be available, use one of your previously defined workspaces as the template for the new Menu item.
    • To configure this, in the server.properties set the parameter webdashboard.templateworkspace=Foo (replace Foo with the name of your workspace).
    • This is an optional setting. If it is not configured, Web Dashboard will use the former superadmin workspace as the template for the menu.

Working with entities

Sentinel Web Dashboard entities are hierarchical objects that use a simple tree-structure. They are used to control access to different objects for different users. By default, Web Dashboard has two predefined entities:

  • Default - default Entity is the pre-defined root of the hierarchy.
  • Public - optional Entity, used to manage publicly available objects.
Note   You can create a number of custom entities within Web Dashboard. Also, you can associate a Sentinel user with a Web Dashboard Entity by using public properties in PassPort, user and user group variables in Sentinel Administration, or in your custom authorization implementation.

Each Entity object has a simple hierarchical tree-like structure:

  • A name - uniquely identifies the Entity object among others.
  • A description - describes the Entity object, used throughout the user interface.
  • A parent - each Entity object, except the default Entity, must have a parent Entity.

By default, every Web Dashboard object (except World objects) is associated with the default Entity. For example, when you create a report, dashboard, or user, it must be associated with an entity, whether it is the default or an entity you create.

By default, the following set of rules apply when working with entities:

  • Users have full access to objects associated with the same Entity as themselves, or with the child Entities of their own Entity.
  • Users have read-only access to objects associated with parent Entities of their own Entity.
  • Users do not have access to objects that are associated with Entities in a separate Entity branch from their own.

There is an alternative set of rules reserved for backwards compatibility reasons with releases prior to Sentinel 4.2.0. To activate these rules, deselect the Use uniform access management for entities option in Web Dashboard (Main menu > Administration > System Preferences > Server ).

This set of alternative rules is different depending on the type of activity you want to perform. For example, if you are performing developer work, creating Reports, Dashboards, and so on, the following set of rules apply:

  • Users have full access to objects associated with the same Entity as themselves, or with the child Entities of their own Entity.
  • Users have read-only access to objects associated with parent Entities of their own Entity.
  • Users do not have access to objects associated with Entities in a separate Entity branch from their own.

If you are executing an already defined Report (for example, you act as a viewer), the following set of rules apply:

  • Users have full access to objects associated with the same Entity as themselves, or with the parent Entities of their own Entity.
  • Users do not have access to objects associated with child Entities of their own Entity, or with Entities in a separate Entity branch from their own.

Example

The following Entity tree-structure is defined in Web Dashboard, where John is associated with the Human Resources Entity:

  • Default Entity
    • Public Entity
    • Accounting Entity
    • Human Resources Entity (John's Entity)
      • New Hires Entity
      • Old Employees Entity

By default, John has the following access rights on the different objects, regardless of the type of activity he performs (for example, creates or visualizes reports):

  • Full access to the reports associated with the Human Resources Entity, as well as with the New Hires Entity and the Old Employees Entity.
  • Read-only access to the reports associated with the Default Entity.
  • No access to the reports placed in the Accounting Entity.

If the alternative set of rules are activated and if John is a Report designer, meaning he creates reports, he has:

  • Full access to the definition of Reports associated with the Human Resources Entity, as well as with the New Hires Entity and the Old Employees Entity.
  • Read-only access to the definition of Reports associated with the Default Entity.
  • No access to the definition of the Reports placed in the Accounting Entity.

If the alternative set of rules are activated and if John is a Report consumer, meaning he visualizes reports, he has:

  • Full access to the definition of reports associated with the Human Resources Entity and the Default Entity.
  • No access to Reports placed in the Accounting Entity, New Hires Entity and Old Employees Entity.

Workspaces and user access

Important: Starting with Sentinel 4.2.0, when access management is done with PassPort, workspaces are kept for backwards compatibility only. If you have upgraded from a previous Sentinel version and use Axway PassPort for access management, refer to the section Upgrade to Sentinel 4.2.0

Workspace objects are used to configure the Web Dashboard menu, and to grant access to users to specific objects. Each user is associated with one workspace, while one workspace is typically associated with many users.

By default, there are three pre-defined workspaces available: superadmin, admin and public.

  • The superadmin workspace features an extensive menu and is suitable for full administrator profiles.
  • The admin workspace enables a subset of the menu items and is suitable for the content developer profile.
  • The public workspace is used to make objects like reports and dashboards publicly accessible (for example, without authentication).

See Publicly accessible Web Dashboard objects.

By default, each user defined in Sentinel is associated with one of the two default workspaces (superadmin or admin), depending on the assigned privileges or rights.

Create a workspace

  1. On the Web Dashboard main menu, select User management > Workspace. A list of existing workspaces displays.
  2. Click the Add button icon green plus sign. A new document opens and the Description tab displays.
  3. On the Description tab, enter values for the following:
    FieldDescription
    NameEnter the name of the workspace. This value must be unique among all workspaces. This value will be the one you have to assign to the PassPort public property or the Sentinel Administration variables to link a user or a group with this workspace.
    DescriptionEnter a human readable description of the workspace. This value will be displayed in the GUI whenever there will be a reference to this workspace. This field can be internationalized.
  4. Select the Sessions tab. A list of folders displays. These folders represent the available menu options in the workspace.
  5. Select one of the folders. The Add button icon green plus sign displays next to the open folder.
  6. Click the Add button icon green plus sign to add that session to the group. For example:

    User Management Administration Session drop down screen
  7. A dialog box displays several lists of objects you can make available for the selected folder. They are labeled Dashboards, Reports, and Sessions and contain the items you can add to your workspace.
  8. The items in the Dashboards and Reports lists are the dashboards and report objects that exist in the system. You can make them available from the folder you selected.
  9. The items in the Sessions list represent new instances of objects. When you include these session items, you make it possible for the user to create new objects.
  10. Select one or more items from one of the lists and select OK.
  11. The selected items display in the list of folders under the folder you selected. Once you select an item and click OK, it is no longer available to be placed in any other folders.
  12. For each of the items you just added, you can specify access rights from a drop down. Choose all rights, read-only rights or none.
  13. Click Save.

Assign entities and workspaces using Sentinel Administration or custom user exit

You can use Sentinel Administration or your user exit implementation to link users to a certain Entity or Workspace using user and group variables. You must define user variables of type String, and name them as follows:

  • WDEntity - to specify a Web Dashboard Entity for a group of users; this variable must be defined on a group
  • WDWorkspace - to specify a Web Dashboard Workspace for a group of users; this variable must be defined on a group
  • WDUserEntity - to specify a Web Dashboard Entity for a specific user; this variable must be defined for a specific user
  • WDUserWorkspace - to specify a Web Dashboard Workspace for a specific user; this variable must be defined for a specific user

The value of the variable must contain the name of the Entity or Workspace in Web Dashboard.

These variables are not mandatory. If not specified, the user will be associated with the root or default Entity and it will be associated with the full administrator or the content administrator workspace.

If you define variables on a group and also on one of the group's members, the variables defined on the member will take precedence over the variables defined on the group.

Assign entities and workspaces using PassPort

You can use PassPort to link Users and User Groups to Entities and Workspaces defined in Web Dashboard using the User Properties or the User Group Properties. You must define the properties with values pointing to the Entity or Workspace name.

When you define properties in PassPort, follow the same naming convention as in the Sentinel Administration:

  • WDEntity - to specify an Entity for a user group.
  • WDWorkspace - to specify a Workspace for a user group.
  • WDUserEntity - to specify an entity for a specific user.
  • WDUserWorkspace - to specify a Workspace for a specific user.

If you define properties at the user level and at the user group level, the properties at the user level take precedence.

Once defined, select the corresponding check box in the PassPort GUI to classify the properties as public. This enables Sentinel to retrieve this information from PassPort.

Expose properties without making them public

It is recommended that you use public properties.

To expose the properties to Sentinel without making them public:

  1. Set up a special Role and associate it with all your User Groups. This role is necessary to allow the Sentinel component to retrieve the defined properties from PassPort.
  2. Make sure the Role contains the four special privileges, as shown in the following table. These privileges must be created manually.
  3. Use a different naming convention when you create properties at the User Group or User level. See the Right operand column in the following table.
  4. When you create these four privileges, perform the following for each:
  • Use the names in the following below.
  • Associate each with the Component Sentinel and the Resource Variable.
  • Select the check box near the action VIEW".
  • Add an IF condition in the Content Editor tab. Use the is operator and specify the left and right operands, as shown in the following table. For example, for the privilege, Web Dashboard Group Entity Enabler, use WDEntity as the left operand and select the property defined on your User Group for specifying an entity name as the right operand.

Suggested privilege name Left operand
(Resource property)
Right operand
(Group or user property)
Web Dashboard Group Entity Enabler WDEntity Group level property for specifying Entity name. For example, GroupEntity.
Web Dashboard Group Workspace Enable WDWorkspace

Group level property for specifying Workspace name.

For example, GroupWorkspace.

Web Dashboard User Entity Enabler WDUserEntity

User level property for specifying Entity name.

For example, UserEntity.

Web Dashboard User Workspace Enabler WDUserWorkspace

User level property for specifying Workspace name.

For example, UserWorkspace.

Related Links