I think there are merits to both of the approaches you suggest. For our particular use case, we were hoping to pass AD/LDAP username only which Shield then uses to perform an AD/LDAP look-up and restricts access accordingly. Shield could use a bind username/password to get the list of groups for a specified user so the only thing we need to pass in is the "acting as" or proxy username. The assumption should be the user has already been authenticated.
We could certainly work with a solution that requires us to pass in the authorization information consisting of a list of the AD/LDAP groups. That wouldn't be overly difficult for us. I would be concerned with someone being able to spoof a request by providing a list of groups. By passing in only the username (acting as), then we can ensure that appropriate restrictions/filters will always be applied. We'll eventually migrate to a Kerberos implementation at some point across the entire stack. Is there any intent to enable Kerberos support in Shield? If there is, what sort of time frame are we looking at? -- Michael On Fri, May 1, 2015 at 2:28 PM, Jay Modi <j...@elastic.co> wrote: > Thanks Michael. Are you interested in Shield performing the authorization > with AD/LDAP for a given proxy user (assumed as being authenticated by your > application) or would/can your application also pass the authorization > information and then Shield restricts access accordingly? > > > On Wednesday, April 29, 2015 at 10:34:54 PM UTC-4, Michael Young wrote: >> >> If you would like to get more specific use case details, I'm more than >> willing to exchange emails or engage in phone calls. >> >> Michael >> >> On Wednesday, April 29, 2015 at 10:34:25 PM UTC-4, Michael Young wrote: >>> >>> I thought that might be the case. >>> >>> The problem with Shield for my use case is authentication and >>> authorization are closely tied together. Generally speaking, we want to >>> limit access to indexes via LDAP/AD groups which are assigned to Shield >>> roles. We want to be able to use a "system/daemon" account to query >>> Elasticserach, but pass in a "proxy" or "impersonation" user which can be >>> used to looked up to see what effective groups they have and from which >>> indexes they can get results. Without the proxy user ability, we are >>> forced to login the user via their username and password. The problem is >>> that users will not directly access Easticsearch and we don't have access >>> to their password. >>> >>> Our users will be authenticated via a separate application/user >>> interface which will be using single sign on tokens. The application >>> doesn't have access to the user's password to pass to Elasticsearch. So >>> there isn't an easy way to say "I have user1234 running a query and I need >>> you to filter index results appropriately for this authenticated user". >>> >>> We want to manage index permissions using LDAP/AD groups and roles using >>> Shield. We don't want to have to do that in the application. The current >>> work around seems to be some sort of api overlay to elasticsearch which >>> will first check to see if the user exists using an admin account. If the >>> user account doesn't exist (first time logging in), then create the user >>> account using a hash of the users group permissions from LDAP/AD. It's not >>> ideal, but it'll probably get the job done until Shield is >>> extended/enhanced. >>> >>> On Wednesday, April 29, 2015 at 5:03:51 PM UTC-4, Jay Modi wrote: >>>> >>>> Hi Michael, >>>> >>>> We don't currently have a way to do this with Shield. Can you tell us a >>>> little more about your scenario? Your users are logging into your >>>> application and then accessing data in Elasticsearch, which is protected by >>>> Shield? >>>> >>>> This type of information is helpful for us as we plan features for >>>> future releases of Shield. >>>> >>>> -Jay >>>> >>>> On Wednesday, April 29, 2015 at 3:06:57 PM UTC-4, Michael Young wrote: >>>>> >>>>> I have Elasticsearch 1.5.2 and Shield 1.2.0 configured and working >>>>> against Active Directory. This seems to work pretty well. However, I was >>>>> wondering if there was a way to pass in a "proxy user" from an application >>>>> to get the appropriate index filtering via access controls without having >>>>> to pass in the username AND password from the application. >>>>> >>>>> Is there a way to do this with Shield? >>>>> >>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elasticsearch/Hmn1KeC9Qco/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > elasticsearch+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/c7cb2cd6-3ce0-4bd4-9e21-b67fc05b2b46%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/c7cb2cd6-3ce0-4bd4-9e21-b67fc05b2b46%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Please update your bookmarks! We moved to https://discuss.elastic.co/ --- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CA%2B6%3DytWV7Xc0W6%3DByreKKkc1NNRC-7MjF%2B7jB_LoVA1b_5PT9A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
