Multiple Fields Authorization

[hfakar (Hüseyin Fatih Akar)]

On the authorization about document level security we use the query:
"match_phrase": {"component":"BİLGİ GÜVENLİĞİ MÜDÜRLÜĞÜ"}
How do I get the response for like multiple components? I tried:
"match_phrase": {"component":"BİLGİ GÜVENLİĞİ MÜDÜRLÜĞÜ" or "ORTAK ÇÖZÜMLER MÜDÜRLÜĞÜ"}

AND
"match_phrase": {"component":"BİLGİ GÜVENLİĞİ MÜDÜRLÜĞÜ"},
"match_phrase": {"component":"ORTAK ÇÖZÜMLER MÜDÜRLÜĞÜ"}

But no success. How do I make an or statement to get both components in the same dashboard?

[LeeDr (Lee Drengenberg)]

Hi Hüseyin,

Can you try something like this (but replace your strings of course);

{
    "bool": {
      "should": [
        {
          "match_phrase": {
            "metricset.name": "process"
          }
        },
        {
          "match_phrase": {
            "metricset.name": "filesystem"
          }
        }
      ],
      "minimum_should_match": 1
    }
  }

Regards,
Lee

[hfakar (Hüseyin Fatih Akar)]

Returns zero results. BTW are you sure this is the correct syntax for active directory realm?
Thank You.

[LeeDr (Lee Drengenberg)]

Your active directory authentication doesn't have anything to do with the document level security. This is just a query against elasticsearch. It's more of authorization once you're authenticated.

If you do your query in Discover tab like below, and then click the little ^ arrow to get to the "spy panel";

Then click the Request button;

Then you can see the exact query that Kibana ran;

"query": {
    "bool": {
      "must": [
        {
          "query_string": {
            "query": "metricset.name:process OR metricset.name:filesystem",
            "analyze_wildcard": true
          }
        },
        {
          "range": {
            "@timestamp": {
              "gte": 1466436294193,
              "lte": 1497972294193,
              "format": "epoch_millis"
            }
          }
        }
      ],
      "must_not": []
    }
  },

You should be able to remove the time "range" block and the empty "must_not" block and get to something like this;

"query": {
    "bool": {
      "must": [
        {
          "query_string": {
            "query": "metricset.name:process OR metricset.name:filesystem",
            "analyze_wildcard": true
          }
        }
      ]
    }
  },

May not need the "analyze_wildcard": true part either.

So this is a little different than my previous screenshot which used a bool should, with 2 separate match_phrase blocks and a minimum_should_match: 1
This one generated by Kibana Discover is a bool must with a single query containing the OR

In the Role Granted Documents Query you need the query block so you start at the first { after query:.

[hfakar (Hüseyin Fatih Akar)]

Hello there.

I tried this but no luck:

It returns nothing. Any idea?

[LeeDr (Lee Drengenberg)]

I'm not clear on exactly what you're trying. What happens in Discover? Can you do the OR query and does that return your expected results? Try each half of the OR separately and note the Hit count returned and the OR query Hit count should add up to both of those. Does that work?

[hfakar (Hüseyin Fatih Akar)]

In discover I can do the "OR" search. It works just as I wanted. Now I need to map that to a role in active directory realm. But I cant do it. The above mapping doesn't work for me. I wonder where am I doing wrong.

[TimV (Tim Vernum)]

I'm afraid you're not really giving us enough information to help solve your problem.

Try to start at the beginning:

• What exactly are you trying to achieve?
• What steps did you try?
• How you know it's not working?

Also:

I need to map that to a role in active directory realm.

The way you're describing isn't quite in alignment with how X-Pack security operates. Since you're trying to utilise some of the more complex security features of X-Pack, I think it's worth throwing in a few quick pointers so that you're better able to debug any issues that come up.

Users and Roles

• Roles exist outside of realms. You either define them in files, or through the API, but they don't belong to realms.
• Users exist in realms, and the list of roles they belong is determined by that realm.
• So a User can be in an Active Directory realm, and that user can be mapped to a Role that was defined through the API, but that doesn't mean that the role is part of that realm. You can have an Active Directory user and a PKI user mapped to exactly the same role, with exactly the same permissions.
• As far as I can tell, the problem you are trying to solve is all about roles, so it doesn't matter whether your user is in the Active Directory realm, or some other realm, the behaviour should be the same.

Document Level Security

• Document Level Security is implemented by standard Elasticsearch queries. Anything you can enter in discover or console should work as a query within a role.
• Document Level Security affects everything that the user does within Elasticsearch, so it's usually easier to test and debug by using simple queries against Elasticsearch (e.g. using Console) before trying to make it work in a Dashboard. Jumping directly from defining a role, to testing a Dashboard (which is what it sounds like you are doing) is often going to be tricky because it can be quite hard to tell if it's working, or how to debug it if it isn't working.
• I recommend you take these steps:

1. Write a query using console and/or discover that matches the documents you want to use for Document Level Security (DLS)
2. Create a new role that has a DLS query using the query you created in step 1.
3. Grant that role (and nothing else) to a user. For the sake of this testing it can be a user from any realm. The native realm is often the easiest for testing because you can manage the users through Kibana and you don't need to fiddle with role mapping.
4. Run some simple queries in console as the user you created step 3. Check that those queries give you the results you expect. I recommend just doing a match_all query - the results should match with the results you got from your testing in step 1.
5. Once that's working, then you can build more complex visualisations and dashboards that rely on the DLS restrictions of the role. Because you know that the DLS query is working (due to step 4), it means that any issues are most likely to be due to the way you've defined your visualisations rather than the role and you can start your debugging there.

[hfakar (Hüseyin Fatih Akar)]

Im shocked that you still understand me.

I want my xxx manager to see the xxx related documents only and he will be authenticated with AD. (DONE)

I want my yyy manager to see the yyy and zzz related documents and he will be authenticating with AD too. (Failied)

When I do search on discovery with superuser role I get what I want.

How do I know that it fails? When I login with yyy role there is no results to show me (0 hits). (and that role is built with the request query in discovery)
You can see it in the above picture.