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.
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.
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.
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.
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.
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 jay@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.
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.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.