Hello,
Hello,
I have 4000 SAML users and need to apply search restrictions dynamically from a lookup table.
Question: Does srchFilter support subsearches or lookups?
Example of what I want to achieve:
[role_dynamic]
srchFilter = [| inputlookup user_restrictions.csv | where username="$user$" | return $filter]
Currently, this doesn't work. Is there a native solution without custom Python scripts?
Thank you.
1. No, you can't do a "dynamic" search filter (like "use the current logged in user's username")
2. Do not use search filters with anything else than indexed fields using :: notation. Search filter with search-time fields is trivial to bypass. (left as excercise to the reader).
Hi @User_Spl
Unfortunately variables/substitutions cannot be used in the srcFilter property, in addition, restricting in the way you're proposing might introduce security risks as there are ways around breaking srcFilter when you are not relying on indexed fields.
For example, the user may be able to make their own private lookup with the same name which would take precedence and give them control.
🌟 Did this answer help you? If so, please consider:
Your feedback encourages the volunteers in this community to continue contributing
Thank you for your response.
USE CASE:
- Single index (e.g., "main") containing logs from all users
- Events are distinguished by a field: user_id (or owner, username, etc.)
- 4000 users authenticated via (SAML)
- Each user should only see their own events (where user_id matches their username)
GOAL:
Apply user-specific filtering WITHOUT creating 4000 individual roles.
IDEAL SOLUTION (if possible):
A single role with dynamic filtering:
[role_users]
srchFilter = user_id="$user$"
Where $user$ is automatically replaced by the authenticated username.
QUESTION:
Does Splunk support this pattern? Can srchFilter use the $user$ variable to dynamically filter based on the logged-in username?
If not, what is the recommended approach for this scenario without creating thousands of roles?
Thank you for your guidance.
Search filters often create more problems than they solve so I always recommend against them.
Keep in mind that the textual content of search filter(s) are automatically added to every search performed by user with role(s) that have a filter defined. That means the filter must make valid SPL when part of that search. In the example, each search will first (because it's a subsearch) read a lookup table and return the contents of the filter field. The results of a subsearch are always substituted for the subsearch itself before SPL parsing continues so the value of $filter must be valid SPL.
That may be hard to follow, but that's because it's complex behavior that doesn't work as sometimes expected.
Why are you using search filters instead of RBAC? What problem are you trying to solve? Perhaps we can help find a better solution.