Role based Dashboard

[fvegdom]

At my company we have software products used by different customer. I would like to create dashboards that behave differently according to the role of the logged in user.

At the moment I have two types of dynamic behaviour in mind
1. I would like the searches to be based on the user's role. The role off course already retricts the access to indices searched for, (we have indexes for different customers) but the search is slow if I cannot restrict it further for the specific report.
2. If the role is not a customer role but a role representing one of our own employees, I would like to make visible inputs that allow that employee to select which customer's data to look at.

my first idea was to set tokens based on the logged in user, but I know that that is not possible from this
https://answers.splunk.com/answers/92495/role-based-dashboard-view.html?utm_source=typeahead&utm_med...

I could also live with haveing two different dashboards if I could maintain the code in one place, but that is not possible according to this
https://answers.splunk.com/answers/52902/shared-xml-between-dashboards.html

are these anwers still up to date? (the questions were asked in 2013, I could imagine more might be possible by now)

[DalJeanis · Accepted solution]

It HAS to be possible to determine the user's role, because the user's capability and access is based on their roles, and panels obviously can test the user's access.

If nothing else, you can use the following kludge:

Define a distinct "virtual" index -- for example idx_role_myrole -- for each role, with security accessible only to that role, and put one record in each, with the name of that role. In the panel, set your access tokens based on whether...

search index=idx_role_myrole | head 1 | stats count 

...returns 0 or >0.

Alternately, set your access based on whether...

search index=idx_role_* | stats values(rolename) as rolename 

returns the particular role or roles you want...

It's a bit fiddly, but if the system security works automatically for indexes, as advertised, then that method MUST work.

Exception - since role=admin can touch everything, it would not be specific. Access to multiple role_indexes would then indicate that the admin role was present.

For your purposes, though, you would just be trying to detect superusers and make capabilities available to them, so if the user isn't able to access idx_role_superuser then you route them to the other drilldown.

[fvegdom]

That is a very clever idea, I'll try that out as soon as I get a chance

[DalJeanis]

Yep. The role of the user MUST be available or the system cannot function. The ID of the user, not necessarily.

[koshyk]

I would view your problem as two parts
- Data security
- Display Flexibility

Data Security can be achieved ONLY by index restrictions. There are other tricks to disable eventypes etc, but a clever search person can override all these. So Indexes naming convention and restriction on the role is the correct way here.

Display Flexiblity is bit tricky. What I do is to create different apps for different customers and give permission only to these apps and role. So they won't even have "search" as their default, but their landing page is specific. You can automate this using shell script or other tools where a user can have default apps which allows what they can see. Naming convention for your objects are extremely important for these kind of automation.

eg. If you want to share a single savedSearch across multiple team, I would first put the searches naming as mycompany_ss_all_thisIsSharedForAllTeam , for specific group would mycomp_ss_myapp_thisIsSharedForMyApp
In this way at your version control level, you will have single set of code and at packaging level, you can send shared_app to all users, group specific to groups etc

[fvegdom]

Your Data security point is well-taken, and that measure is already in place. My problem is that the search is slow because the searches on the dashboard search for index="*-applicationname", whereas I would like them to search for index="customername-applicationname", this is not for security reasons, the customer would never get a result from another index in the current situation because he has no accesss to those indexes, it is just that (I think that, I could be wrong) the search is a lot slower because of this.

Do I understand you correctly that with you idea the class of user(i.e. the role you are dealing with) is (in effect) inferred through the application context? And that you could have a single dashboard that behaves differently according to the app it is being called from?

[koshyk]

within your app, create the dashboard + Search Bar with already existing index="customername-applicationame" token. So when customer searches, he dont need to put index value, but just search specific index.

OR within role search limits of the user/group, put the negative conditions.
By example :
for the RoleA, always add "AND index!=my_unwanted_index" to the main search conditions.

[fvegdom]

I am not sure I understand your suggestion (I see now that my earlier interpretation was wrong, it is not possible to put single dashboard into more than one app).

What do you mean by create the dashboard + search bar? Do you mean you set a hardcoded token in the dashboard and then use that token for the search? And then to customize it for different user groups, creating multiple copies of the dashboard, each in a different app, with a different customized hardcoded token, one for each role?
That is possible, but I am trying to avoid these multiple copies of the same dashboard for maintainability reasons, if I change something in the dashboard I don't want to have to go through all of it's copies to upgrade them.