Backend Roles vs SG Roles, I need some clarifications

I need some advice about Backend Roles vs SG Roles.

I am focusing on Proxy Authentication and after reading the manual my understanding is as follows:

  1. When using a Proxy based authentication type, the user and her roles are provided by the proxy in the x-proxy-user and x-proxy-roles HTTP request headers. Both are assumed to be verified by a trusted server.

  2. When using Proxy authentication the file sg_internal_users.yml is not needed, so I can forget about it. The user sent by the proxy is mapped with the SG Roles in the sg_roles_mapping.yml file

  3. The authorization backend type must be noop in this case: I do not have a LDAP server. As stated by the manual this means that the backend roles are not used at all. (Is it true ?)
    My question is: what the x-proxy-roles header is supposed to contain in this case ? - I am confused.

  4. If it must contain a list of SG Roles names I am wondering how can the proxy server add the right names to the list, they are defined in the SG file sg_roles.yml and of course are not accessible to the proxy server

  5. If it must contain a list of backend roles that SG will map to the corresponding SG Roles using the sg_roles_mapping.yml file it would make sense, but my statement n. 3 above must be wrong.
    May be I misunderstood the manual, of course.

Please help me

- In your case the roles in "x-proxy-roles" are your backend roles.
- You map them in sg_roles_mapping.yml to "seach guard roles" which are defined in sg_roles.yml
- Your authentication backend (authc) should be "noop" and you dont need any authorization backends (authz).
- yes, sg_internal_users.yml is not needed.
- if it is sufficient for you to only map ther user to "search guard" roles (in sg_roles_mapping.yml) then you need to care about backend roles

Can you point to the section in the docs "As stated by the manual this means that the backend roles are not used at all". This is not true.

Hope this helps

···

Am 31.05.2017 um 20:16 schrieb Luca Buraggi <luca.buraggi@gmail.com>:

I need some advice about Backend Roles vs SG Roles.

I am focusing on Proxy Authentication and after reading the manual my understanding is as follows:
  • When using a Proxy based authentication type, the user and her roles are provided by the proxy in the x-proxy-user and x-proxy-roles HTTP request headers. Both are assumed to be verified by a trusted server.
  • When using Proxy authentication the file sg_internal_users.yml is not needed, so I can forget about it. The user sent by the proxy is mapped with the SG Roles in the sg_roles_mapping.yml file
  • The authorization backend type must be noop in this case: I do not have a LDAP server. As stated by the manual this means that the backend roles are not used at all. (Is it true ?)
My question is: what the x-proxy-roles header is supposed to contain in this case ? - I am confused.

  • If it must contain a list of SG Roles names I am wondering how can the proxy server add the right names to the list, they are defined in the SG file sg_roles.yml and of course are not accessible to the proxy server
  • If it must contain a list of backend roles that SG will map to the corresponding SG Roles using the sg_roles_mapping.yml file it would make sense, but my statement n. 3 above must be wrong.
May be I misunderstood the manual, of course.

Please help me

--
You received this message because you are subscribed to the Google Groups "Search Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/d9cb67c2-1c82-4b70-98df-bbe480e941ff%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.

Thank you a lot for your clarification.

My understanding of the manual was wrong. These are the parts that confused me:

  1. In this manual page, in the Authorization section I read that choosing a noop authorization backend type causes the process of collecting additional roles from a backend system to be skipped altogether. And noop was the only possible choice for me
  2. In this page, when enabling the proxy authentication, the authorization backend type is set to noop. This confused me.
    Can I suggest to clarify in the manual that when using proxy auth the backend roles are taken from the http request even if the authorization backend type = noop ?

Thank you again.

···

Il giorno mercoledì 31 maggio 2017 22:40:26 UTC+2, Search Guard ha scritto:

  • In your case the roles in “x-proxy-roles” are your backend roles.

  • You map them in sg_roles_mapping.yml to “seach guard roles” which are defined in sg_roles.yml

  • Your authentication backend (authc) should be “noop” and you dont need any authorization backends (authz).

  • yes, sg_internal_users.yml is not needed.

  • if it is sufficient for you to only map ther user to “search guard” roles (in sg_roles_mapping.yml) then you need to care about backend roles

Can you point to the section in the docs “As stated by the manual this means that the backend roles are not used at all”. This is not true.

Hope this helps

Am 31.05.2017 um 20:16 schrieb Luca Buraggi luca.b...@gmail.com:

I need some advice about Backend Roles vs SG Roles.

I am focusing on Proxy Authentication and after reading the manual my understanding is as follows:

    • When using a Proxy based authentication type, the user and her roles are provided by the proxy in the x-proxy-user and x-proxy-roles  HTTP request headers. Both are assumed to be verified by a trusted server.      
    • When using Proxy authentication the file sg_internal_users.yml is not needed, so I can forget about it. The user sent by the proxy is mapped with the SG Roles in the sg_roles_mapping.yml file
    • The authorization backend type must be noop in this case: I do not have a LDAP server. As stated by the manual this means that the backend roles are not used at all. (Is it true ?)

My question is: what the x-proxy-roles header is supposed to contain in this case ? - I am confused.

    • If it must contain a list of SG Roles  names I am wondering how can the proxy server add the right names to the list,  they are defined in the SG file sg_roles.yml and of course are not accessible to the proxy server
    • If it must contain a list of backend roles that SG will map to the corresponding SG Roles using the sg_roles_mapping.yml file it would make sense, but my statement n. 3 above must be wrong.

May be I misunderstood the manual, of course.

Please help me


You received this message because you are subscribed to the Google Groups “Search Guard” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/d9cb67c2-1c82-4b70-98df-bbe480e941ff%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hi Luca - we will update the docs and clarify where the backend roles come from in this case. Thanks very much for pointing this out!

···

On Thursday, June 1, 2017 at 10:31:43 AM UTC+2, Luca Buraggi wrote:

Thank you a lot for your clarification.

My understanding of the manual was wrong. These are the parts that confused me:

  1. In this manual page, in the Authorization section I read that choosing a noop authorization backend type causes the process of collecting additional roles from a backend system to be skipped altogether. And noop was the only possible choice for me
  2. In this page, when enabling the proxy authentication, the authorization backend type is set to noop. This confused me.
    Can I suggest to clarify in the manual that when using proxy auth the backend roles are taken from the http request even if the authorization backend type = noop ?

Thank you again.

Il giorno mercoledì 31 maggio 2017 22:40:26 UTC+2, Search Guard ha scritto:

  • In your case the roles in “x-proxy-roles” are your backend roles.

  • You map them in sg_roles_mapping.yml to “seach guard roles” which are defined in sg_roles.yml

  • Your authentication backend (authc) should be “noop” and you dont need any authorization backends (authz).

  • yes, sg_internal_users.yml is not needed.

  • if it is sufficient for you to only map ther user to “search guard” roles (in sg_roles_mapping.yml) then you need to care about backend roles

Can you point to the section in the docs “As stated by the manual this means that the backend roles are not used at all”. This is not true.

Hope this helps

Am 31.05.2017 um 20:16 schrieb Luca Buraggi luca.b...@gmail.com:

I need some advice about Backend Roles vs SG Roles.

I am focusing on Proxy Authentication and after reading the manual my understanding is as follows:

    • When using a Proxy based authentication type, the user and her roles are provided by the proxy in the x-proxy-user and x-proxy-roles  HTTP request headers. Both are assumed to be verified by a trusted server.      
    • When using Proxy authentication the file sg_internal_users.yml is not needed, so I can forget about it. The user sent by the proxy is mapped with the SG Roles in the sg_roles_mapping.yml file
    • The authorization backend type must be noop in this case: I do not have a LDAP server. As stated by the manual this means that the backend roles are not used at all. (Is it true ?)

My question is: what the x-proxy-roles header is supposed to contain in this case ? - I am confused.

    • If it must contain a list of SG Roles  names I am wondering how can the proxy server add the right names to the list,  they are defined in the SG file sg_roles.yml and of course are not accessible to the proxy server
    • If it must contain a list of backend roles that SG will map to the corresponding SG Roles using the sg_roles_mapping.yml file it would make sense, but my statement n. 3 above must be wrong.

May be I misunderstood the manual, of course.

Please help me


You received this message because you are subscribed to the Google Groups “Search Guard” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.

To post to this group, send email to search...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/d9cb67c2-1c82-4b70-98df-bbe480e941ff%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.