How to perform a row-level-security-filter-data-by-user based on dundas.context.currentSession.accountName??

#1

Hi,

I need to filter the data returned by a datacube without using a custom attribute, as my aim is to filter on the dundas.context.currentSession.accountName, I saw how to do such a filtering using a custom attribute, but nothing about building a security hierarchy based on the non-custom attributes.

My use-case is:
I have a Dashboard that shows a contract to be validated by the end-user, that has to be filtered by the end-user login, in order to show only his/hers contract when the end-user connects himself/herself using AD. The login of the end-user can be returned as a field in my query (because it’s stored for another purpose), but I haven’ t found a way to compare it to the dundas.context.currentSession.accountName.

I cannot use a custom attribute as it would mean to have the end-users declared one by one and have a value set manually for each end-user (there are about 50 000 users that can connect themselves using floating seats), I’m using an AD group for granting access directly to those users.

Is there a way to build a security hierarchy based upon a non-custom attribute? Or another way than the security hierarchy to perform this?

Thanks in advance,
Olivier

#2

Hi Olivier,

You can add a filter transform to the data cube and then filter the column containing the usernames to the username of the current logged in user in Dundas BI.

This will filter the data based on the current logged in user’s user name without using a custom attribute. I hope this helps.

Thanks,
Pankaj

1 Like
#3

Hello @romero.olivier,

You can try to add a placeholder into your cube which will take dynamically the user(dundas.context.currentSession.accountName) or different variations of this script.
https://www.dundas.com/support/learning/documentation/cleanse-consolidate-modify-data/using-manual-select-placeholders
For this you will need to have the data prepared, in you case as the user name/ID/group should be part of your query.

Hope this helps!

#4

Hi,

Thank you both for your answers.

Pankaj, I’m afraid that your solution doesn’t work, when setting it exactly as you have described, it sound like the value set by the token in the filter is the accountName of the user that is setting up the filter (in my case Admin), and only this one. When I tested your solution nothing has been returned.
In order to be sure, because Admin is not recorded in the table I perform the query on, I did a simple test, I have a normal user account that I use for testing, so I set the filter to use “Does not equal” the token “Current Account Name”, which should have returned all the rows except the one corresponding to the accountName of my normal user when I connect myself using this account. And nothing has been filtered at all.
I have double checked by adding a TextBox that shows the accountName of the user connected using this script:
“parameterTextBox1.control.value = dundas.context.currentSession.accountName;”
set on the “Ready” trigger of the Dashboard.
And the line having the corresponding login was still showing up with all the others.

Costin, concerning the PlaceHolder, I have no clue on how to set the value directly to dundas.context.currentSession.accountName in the DataCube. If you have the solution, please tell me. Because if the aim is to use the PlaceHolder in order to pass to it the dundas.context.currentSession.accountName from the visualizasion level, the security is not total and can be breached.

What I have done for now is to link the TextBox defined as explained above as filter for the field containing the login. And this works for filtering, but in my view this solution is not that secure as it’s done at the visualization level using a script and a filter containing the value used for security instead of being done at the data level directly which would offer the possibility to filter out the field used for the security before being at the visualization level…

Any solution for doing it really at the data level without having to setup whatever at the visualization level is welcome.

Olivier

1 Like
#5

Hello @romero.olivier,

In your case the placeholders will work exactly like a filter and the placeholder value for a user will be provided by a script.

One remark: the normal filter will provide all data into the dashboard and after this, the filter action will happen. The placeholder will filter the data at the cube level and the data available into the dashboard will be contain only the rows related with the specific user. I would say that the placeholder is more secure than a normal filter.

Regarding the security, I am not an expert but if someone knows how the platform it’s working can try to push the values directly (I do not know if the security can be breached) . This should be investigated. I am thinking to different possibilities, which are linked with the security requirements: how build the script, validation rules for the user, maybe a second layer for authentication (something like a token). In any case, in order to filter the dashboard it is required to send a parameter/value/token to the backend side.

Hello @Pankaj,

The solution provided by you is working for the AD authentication? From what I saw in the example, it is explained how it is working for the local users.

#6

Hey Costin,

The “Current Account Name” token will return the name property of the current logged in user.image

So if the data contains a column with names similar to the AD names then this should work. Else you can also user tokens like:
image

I hope this answers your question. Please let me know if you have any questions.

1 Like