Thanks for the details; I personally am more of a fan of the second approach as well.
Kerberos is on the Shield roadmap, but we don't have it pegged to a date on the roadmap and features on the roadmap will change priorities so I can't really give a time frame. On Tuesday, May 5, 2015 at 5:27:03 PM UTC-4, Michael Young wrote: > > 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 <javascript:>> > 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 >> elasticsearc...@googlegroups.com <javascript:>. >> 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/69d7f9ae-9e40-4551-bf17-edc6eefc11e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
