Permissioning a dynamic dropdown on a form

[bruceclarke]

All,

I'm curious if there is a way to permission a form input in Splunk. Right now I have some basic permissioning in place. It uses thi query to populate a dynamic dropdown:

| inputcsv userAccess.csv 
| join [rest /services/authentication/current-context/context 
| search username!="splunk-system-user"
| fields + username]
| eval hasPermissions=`hasPermissionsCheck(username)`
| where hasPermissions="Yes"
| table server_name
| sort server_name

The thing that I really want to do, however, is make sure that users can't manipulate the URL to type in a server that they don't have access to. I realize Splunk isn't the best at permissioning a single form input, but can anyone think of a way to do this?

Thanks!

[martin_mueller · Accepted solution]

With all the caveats said, you would need to copy your permissions check into the search itself.

Think of it like this: The dropdown does input validation at the frontend level, the search does input validation at the backend level. If a user circumvents the frontend by typing in an undesired URL the backend will still catch it.

[bruceclarke]

Yeah, that's kind of what I figured the answer might be. Thanks!

[martin_mueller]

Do they have a clone button on the view that lets them make their own private view? 😄

...and if there is no such button, the underlying machinery parts probably still are there. Long story short, UI-only access control is baaad.

[bruceclarke]

I know many of the ways in which they would be able to get around this. The cloning workaround is one such example. My question is simply this - is there a way to prevent a dropdown from selecting values that it doesn't return? It sounds like the answer is "no."

These are internal users - not malicious - but if the hack is simply changing a URL parameter to say "Two" instead of "One," well that's easy. If they have to learn Splunk syntax, our sourcetypes, and how to parse the data, that's another level entirely. It's not the end of the world if these users see this data, it's just nice if we have some barriers in place.

I know this is an arbitrary distinction. It's just one I was asked to investigate.

[martin_mueller]

Do they have the capability to search the data underneath that view?

[bruceclarke]

No - we've remove their access to the search app. They obviously have permissions to the data, but they can't write their own searches.

[martin_mueller]

What's the motivation/requirement that leads you to wanting a restriction in a dropdown on a form?

What's your overall permissions structure?

[bruceclarke]

@martin_mueller We have certain employees permissioned to everything, but there are client service members who want log information about specific clients that they have access to. So far we've given them permissions to a small subset of dashboards. Because we're using LDAP authentication, we can poll a database nightly to ensure the correct permissions are applied. We'd like to go one step further though, and prevent the user from manipulating the URL in any way.