416.467.9100 | Dundas Data Visualization | Login
Welcome Guest
This is the support page for the legacy Dundas Dashboard application. For assistance with the current Dundas BI application please click here.
Dashboard v5.0

This site makes extensive use of JavaScript.

Please enable JavaScript in your web browser and reload the page before proceeding.

Using Custom Attributes

Hide navigation
Modified on Fri, 23 May 2014 03:16 PM Categorized as Administration, Security, Virtual Tables
Click to return to: Documentation


Dundas Dashboard lets you use custom attributes as a flexible means of setting up your data to return only the results that the current Dundas Dashboard user is allowed to see (⪚ for security or privacy reasons).

Tip: The functionality described in this article is sometimes referred to as “row-level security” or “user-dependent filtering”.


By default, when Dundas Dashboard queries for data through a data connector, it does so using the Windows credentials of the Windows user account that is running IIS. But often, this user may not have sufficient privileges to access your databases, which results in permission errors when performing operations such as previewing a data structure using the data connector.

Connect As

The above problem can be resolved by using the Connect As option at the data connector stage, which allows you to hardcode the Windows credentials (⪚ your own) to use in place of the IIS account. However, a disadvantage of using Connect As settings is that the same data is returned regardless of which user is currently logged in to Dundas Dashboard. For security reasons, you may want to configure your system so that only data that a user is permitted to see is returned.

Windows Impersonation

The Windows Impersonation option is one way to address the limitations of using Connect As settings. If this option is enabled, queries for data will be executed using the Windows credentials of the person who is using Dundas Dashboard on the client computer. This allows your database administrator to set things up on the database side so that queries return only the data applicable to the current Windows user. For example, if you are using SQL Server, you can define a view that incorporates the SYSTEM_USER function in order to return Windows user-specific results. In general, Windows Impersonation is an option when your Dundas Dashboard instance is configured to log in users automatically via Windows Authentication.

Custom Attributes

Alternatively, Dashboard administrators can assign custom attributes to a user account or a security group. A custom attribute is simply a name-value string pair that lets you associate an arbitrary piece of information with a user or security group. This information can then be used in queries or stored procedures to filter the data according to the user who is currently logged in. The difference between using custom attributes and the Windows Impersonation option is that custom attributes work regardless of the authentication mode in Dundas Dashboard (i.e. custom attributes work whether you are using local authentication, Windows authentication, or mixed authentication).

Tip: When both a user and one or more of their groups define the same custom attribute, the values are comma-seperated when used for user-based parameters. For example, if the admin user has the attribute "SecurityLevel" set to "3,4", and the Everyone group has "SecurityLevel" set to "1", a user-based parameter will provide the query "3,4,1" for the admin user.


The following end-to-end example shows how to use custom attributes to create a dashboard that lets users see different results depending on their “security level”.

Set up the data connector

Set up a data connector to retrieve data from a table with the following fields:

  • ProductID - A product identifier.
  • ProductName - The product name.
  • SecurityLevel - A user must have this security level or higher in order to see the corresponding product.

Data connector preview.

Data connector preview.

Set up the virtual table

Create a new virtual table as follows:

  1. From the Virtual Table Setup wizard:
    • Choose the Manual Virtual Table option which lets you write your own SQL query.
      Note: It is also possible to use the Standard Virtual table option and use the Manual Override toolbar option.
    • Choose the data connector that was created earlier to base the virtual table upon.
  2. In the Preview tab, enter the initial SQL query: select * from [dbo].[Product]
  3. Click Parse and Preview Content to verify all records show up in the preview.
    Virtual table Preview tab.

Create a user-based parameter

Next, create a user-based parameter (which can be inserted into the query later for filtering purposes):

  1. In the Preview tab, click Add Manual Parameter.
  2. In the Manual Parameter Setup wizard, select User-based filter, then click Next.
    User-based manual parameter option.
  3. In the Choose Parameter Type step:
    • Set the Parameter name to UserSecurityParam.
    • Select the Custom attribute option, then type in the name of the attribute as: SecurityLevel.
      Select custom attribute option.
    • Click Finish. The wizard closes and the manual parameter appears in the User Statement Parameters grid.
      User parameter is created.

Modify the manual query

Now you can insert the user-based parameter into the manual SQL query:

  1. In the User Statement Parameters grid, click the “plus sign” button for the UserSecurityParam row. A corresponding parameter token is inserted into the query where the cursor is positioned.
    Insert parameter token into query.
  2. Modify the query by using the parameter token in a where clause to filter the data.

select * from dbo.Product where {DW:UserSecurityParam} >= SecurityLevel

You can now save and check in the virtual table.

Create a dataset

Create a dataset out of the manual virtual table as follows:

  1. In the Design Explorer, right-click over the virtual table created earlier.
  2. From the menu, choose Create Dataset.
    Create Dataset from menu.
  3. Rename the dataset to “Product Data”.
  4. Edit the dataset, then click Check In from the toolbar.

Create a dashboard

Create a new dashboard as follows:

  1. Create a new dashboard from the Design Explorer.
  2. From the toolbox, drag the Product Data dataset to the dashboard canvas. The dataset appears as a data grid control.
  3. In the Data Grid Binding Setup wizard, choose the ProductID and ProductName columns to be visible.
    Data grid binding setup.
  4. Save and check in the dashboard.

Give each user a security level

Next, go to the Administration sidebar and edit a user account:

  1. In the Editing Account screen, go to the Custom Attributes tab.
  2. Click New Attribute.
  3. In the New Attribute dialog, set the name to SecurityLevel and set the value to 3.
    Create a new custom attribute.
  4. Click OK. The new custom attribute appears in the grid.
    Custom attribute appears in grid.

Tip: You can set custom attributes on a group of users in a similar way.

Note: Changes to an account's custom attributes take effect on the account's next login.

Note: A custom attribute can only have a single value. But you can use a comma-separated string to represent multiple values, such as multiple security levels. In this case, your manual SQL query must be able to handle the possibility of having comma-separated attribute values by using a SQL function to first split or tokenize the attribute value.

View the dashboard

Log out of Dundas Dashboard and log back in as the user account for which the SecurityLevel custom attribute has been set.

View the dashboard to see the list of products displayed according to your security level (e.g. level 3):

Dashboard shows only the products you are allowed to see.

Dashboard shows only the products you are allowed to see.

You can experiment further with this example by changing the value of the custom attribute from the Editing Account screen and then viewing the resulting dashboard again.

OLAP and Custom Attributes

If you are connecting to SQL Server Analysis Services (SSAS), you can pass a custom attribute value into the SSAS connecting string by using the CustomData advanced property of a SSAS data connector. Your SSAS administrator can then set things up so that different data can be returned by Analysis Services depending on the custom attribute value (extracted from the connection string).

For more details, see the example in SQL Server Analysis Services - Advanced Properties.

Setting custom attributes programmatically

If you are integrating the Dundas Dashboard Viewer into your own ASP.NET application, you can get or set custom attributes programmatically using code as shown below:

// Set the custom attribute
Collection<string> customAttributeValuesSet = new Collection<string>();
customAttributeValuesSet.Add(customAttrValue); // pass the attribute value, like a USER_ID
IntegrationHelper.SetSessionCustomAttribute(loginStatus.SessionId, "CUSTOM_ATTR_NAME", customAttributeValuesSet);

See also: IntegrationHelper Methods

Related topics

Click to return to: Documentation

About Dundas | Contact Us Follow us on Twitter! | Privacy Statement | Report Site Issues

Copyright © 2009-2014 Dundas Data Visualization, Inc.