@sscarduzio, you said in an email

you can configure the proxy to inject headers like “x-forwarded-user” and “x-forwarded-groups” so that ReadonlyREST can use that for authentication purposes.

What I thought you meant was that GRP would get populated with x-forwarded-groups in the same way that USR does for x-forwarded-user. But this seems not to be case. Indeed I can find no trace of x-forwarded-groups in the code.

Where you referring to a possible future capability?

Hmm, ok. I see ProxyAuthSyncRule and ProxyAuthRuleSettings would need to be extended for this. Not sure if I can work around this.

So looking at ProxyAuthSyncRule to work the way I need, it would have to handle something like

        - name: plant-operators
          proxy_auth: "*"
          groups: [operator]
          indices: ["plant-*"]
          filter: |
              "term": {"plant": "@{x-plant}"}

Even if I extended the rule to support x-forwarded-groups it would have very different behavior than it currently does – ie, the user is not needed. ProxyAuthRuleSettings would not even accept that.

Any ideas?

I suppose I could put the group in the x-forwarded-user and then also set something like x-user so I get the user in the audit…

Technically this works, but it shows the pseudo “group” name on the ui instead of the user.

        - name: PLANT-OPERATOR
            - x-forwarded-user:*
            - x-user:*
            - x-plant:*
          proxy_auth: operator
          indices: [kibana_sample_data_ecommerce]
          filter: |
              "term": {"customer_gender": "@{x-plant}"}

The user on the bottom left button shows “operator” (the value the proxy had to add to x-forwarded-user) instead of the real user name.

Try this:

        - name: PLANT-OPERATOR
            - x-forwarded-group:operator  # requiring a header value here, technically counts as authorization 
          proxy_auth: "*" # allow any value for x-forwarded-user, which will be recognised as username (will read on the bottom left button)
1 Like