management api user/ rolesmapping

[Me He]

Hi,

I am evaluating search guard on my local machine with bundle elasticsearch-5.1.1-10-8BCFA2D1-34F6-4A0F-BEA8-9F3ACA113B38.

when accessing:
https://localhost:9200/_searchguard/api/user/worf I get

{"worf" : {"hash" : "$2a$12$A41IxPXV1/Dx46C6i1ufGubv.p3qYX7xVcY46q33sylYbIqQVwTMu" }}

and with https://localhost:9200/_searchguard/api/rolesmapping/sg_role_starfleet":

{  "sg_role_starfleet" : {"backendroles" : ["starfleet","captains","defectors","cn=ldaprole,ou=groups,dc=example,dc=com" ],"hosts" : [  "*.starfleetintranet.com"],"users" : ["worf"]}}

The first api call show no roles for user worf, while the second claims he has sg_role_starfleet , is that a bug or by intention, or is it possible that I have somehow misconfigured my system.


We are not yet sure which approach for rights management to choose.
We want to avoid building a frontend for user and rights management and chose something where changes can be managed by other tools.
One idea would be to use ldap. Is it possible to access the roles of a given user via searchguard management api when using ldap backend for authorization?

The alternative idea is to handle everything with client certificates. If we do that, is it enough to define which field shall be used as user name or must this user name then be configured in the internal user database? Same question for roles and rights. We would want to map the Organizational Unit Name to a role to avoid reconfiguring of searchguard for each change in userbase. Is that possible?
This leads to the next question: must one restart searchguard/elasticsearch when replacing/changing truststore.jks?


best,
Meike

[SG]

please share your sg_*.yml config files

> Am 07.03.2017 um 10:44 schrieb Me He <googl...@kampfschnuffel.de>:
>
> Hi,
>
> I am evaluating search guard on my local machine with bundle elasticsearch-5.1.1-10-8BCFA2D1-34F6-4A0F-BEA8-9F3ACA113B38.
>
> when accessing:
> https://localhost:9200/_searchguard/api/user/worf I get
>
> {"worf" : {"hash" : "$2a$12$A41IxPXV1/Dx46C6i1ufGubv.p3qYX7xVcY46q33sylYbIqQVwTMu" }}
>
> and with https://localhost:9200/_searchguard/api/rolesmapping/sg_role_starfleet":
>
> { "sg_role_starfleet" : {"backendroles" : ["starfleet","captains","defectors","cn=ldaprole,ou=groups,dc=example,dc=com" ],"hosts" : [ "*.starfleetintranet.com"],"users" : ["worf"]}}
>
> The first api call show no roles for user worf, while the second claims he has sg_role_starfleet , is that a bug or by intention, or is it possible that I have somehow misconfigured my system.

Regarding the roles: There is a difference between a "backend role" (roles assigned to users by the authz backend) and a search guard role (sg role) which are defined in roles_mapping.yml

>
>
> We are not yet sure which approach for rights management to choose.
> We want to avoid building a frontend for user and rights management and chose something where changes can be managed by other tools.
> One idea would be to use ldap. Is it possible to access the roles of a given user via searchguard management api when using ldap backend for authorization?

You cannot access or manage ldap roles/users via the management api.

>
> The alternative idea is to handle everything with client certificates. If we do that, is it enough to define which field shall be used as user name or must this user name then be configured in the internal user database?

this is configurable

> Same question for roles and rights.

roles and rights cannot be stored in a ssl client certificate so you need to use sg_roles_mapping.yml here or ldap

> We would want to map the Organizational Unit Name to a role to avoid reconfiguring of searchguard for each change in userbase. Is that possible?

not yet, but we are an open source and happy to accept a PR for that or, if you pay for a search guard license, we can talk about implementing this feature.

> This leads to the next question: must one restart searchguard/elasticsearch when replacing/changing truststore.jks?

yes but there is no need to replace or change truststore.jks because it should only contain the root certificate (and that hopefully only change if its compromised)

>
>
> best,
> Meike
>
> --
> 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/7984767f-7469-42c3-b09c-aebe074175d9%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.