How do I create a multi-panel dashboard that uses tokens under an App for users with limited access?

[Raistly]

This question seems simple but I'm having trouble actually implementing it. I'm also having trouble finding a thread that already addresses this problem in full — feel free to link me to an existing thread if it's applicable here.

Issue Explained:
I'm a power user with access to all indexes (infosec), and I'm trying to create a dashboard under a newly created App called Service Desk. I plan to grant Service Desk employees access, but they will be confined to this app (and likely start on a homepage of this dashboard).

It is essentially an AD lockout dashboard with multiple panels. These panels and their underlying searches have access to multiple indexes (such as windows event logs, AD logs, WIFI logs, FW logs, etc).

I want these employees to be able to run searches on the dashboard through the use of tokens (such as the input of a username), but really, by limiting everything else. And, I definitely don't want them to have access to searching the underlying indexes.

I have the finished dashboard with all panels created already in another App. No matter what I try, it seems to get more and more complicated to move it to the Service Desk app, and I keep having permission issues.

I've tried copying the source code over to a new dashboard in the Service Desk App — some panels work, and some don't. Most permission errors say that these panels can’t access the included lookup tables because they don’t exist or aren’t available. I’ve tried granting everyone access to the lookups, and I’ve tried moving the lookups to the Service Desk app, but the issue persists.

I’ve also tried creating reports (or saved searches) for each of the searches / panels in the Service Desk App. Then I add those to the dashboard to be run with the owner's (my) permissions. Even though this was what I believed to be the recommended route, it doesn’t seem to work when trying to pass tokens from the inputs to the saved searches, and other forums have indicated this as well.

I can’t find a support article that pieces all of this together with a solution — any help would be appreciated.

[pramit46]

@Raistly,

There are a few things you can do.

1. You can control access to each object the user will be accessing.
2. You can have a hidden input in your dashboard which will capture the current logged in user by running this query:

|rest splunk_server=local /services/authentication/current-context/

This will also show you the roles the user has. Now, based on the role you can set/unset some tokens and also have the panel queries (which the user is supposed to run) be dependant on that tokens (you might have to play with the keywords: depends/rejects, or simply use the tokens in your queries based on your need. If you use them in the query then until the value is set, the whole search will not be run).

following is one old example where I used username as the determining factor. You may have to use roles.

<input id="someid1" type="dropdown" token="username" searchWhenChanged="true">
      <label>username</label>
      <fieldForLabel>username</fieldForLabel>
      <fieldForValue>username</fieldForValue>
      <search>
        <query>|rest splunk_server=local /services/authentication/current-context/| fields username</query>
        <earliest>-24h@h</earliest>
        <latest>now</latest>
      </search>
      <change>           
        <condition match="username==&quot;pramit&quot;">
          <set token="form.xx">true</set>
          <unset token="form.yy"></unset>
        </condition>
      </change>
    </input>
    <input type="text" token="xx" id="someid2">
          <label>active if set</label>
     </input>
     <input type="text" token="yy" id="someid3">
          <label>inactive if set</label>
     </input>

Now you can have your panel queries dependant on the values of xx & yy. Let me know if this helps.

[Raistly]

Thanks for the info, pramit46. I haven't gotten to get back to my instance to test yet but I will soon and I'll update here. Thanks again!

[niketn]

@Raistly refer to one of my older answer for restricting access by various mechanisms, including role of logged in user: https://answers.splunk.com/answers/588779/whats-the-best-way-to-limit-a-role-so-it-only-has.html

Following specific answer as one of the examples, disables inputs based on Role, however you can modify the same to hide unwanted elements (using depends in Simple XML as stated by Pramit) /disable (using Simple XML JS extension and SplunkJS to apply style as per access token): https://answers.splunk.com/answers/575377/can-i-restrict-permissions-for-the-text-box-drilld.html

[Raistly]

Thanks, niketnilay. I haven't gotten a chance to try it yet but I appreciate the info and will take a look as soon as I can.

[Raistly]

Thanks for your reply, maciep. I haven't gotten a chance to try that, but when I do I'll update here.

Are you saying that cloning the dashboard and working out the permissions errors is the best way to handle something like this? I'm still hoping for a link or a write up on a guide for this entire task.

[maciep]

Or I think you could move it along with all of the knowledge objects it relies on. I guess it depends on whether you ultimately want it in both apps? I can't tell if you built specifically for this use case or if it was already in use and you wanted to use it in this other capacity as well.

But personally, i'd probably just build it in the app where you want it to live. You could leave it private while you build it and/or use a test account to test the functionality.

Side note, typically out here answers are reserved for answers to the question. In the future, something like your reply would be better as a comment on your original post, not a new answer...a bit different than traditional forums.

[Raistly]

Thanks for the feedback and info, maciep. It was actually my first time posting and I hit the wrong button without realizing it. I'm sorry I still haven't gotten a chance to properly test this but will accept or post again when I do.

[maciep]

for objects like lookups, a user must have access to the app they're in to have access to the objects, regardless of whether they're global. So a user that only has access to the Service Desk app can only have access to objects in that app.

When you moved the lookups, did you move the file and reference (if you're using both)? Did you make sure they weren't private after the move?