ES Blog: User Impersonation with X-Pack

[jetnet]

Hi All,

I read recently a very good article regarding integration of the ES with 3rd party auth, and I'd like to discuss with the community the following point:
the author has created an internal ES "fake" account (user1) for the "real" user's account "user1":

curl -u elastic:changeme -XPOST "http://localhost:9200/_xpack/security/user/user1" -H 'Content-Type: application/json' -d'
{
 "password" : "B&J$v,&%2SV*g9Xv", 
 "roles" : ["kibana_user", "shakespeare_bank_read"], 
 "full_name" : "My Test User 1"
}'

and granted the technical role nginx permission to impersonate that user:

curl -u elastic:changeme -XPOST "http://localhost:9200/_xpack/security/role/nginx" -H 'Content-Type: application/json' -d'
{ 
 "run_as": ["user1"]
}'

That means, if we're going to use an LDAP (AD) server of an enterprise with, let's say, 200.000 users, we'd have to create an internal ES user for every "real" account? And, if wildcards are not allowed, the second query above, would contain a huge run_as list with these 200k accounts? (to say nothing of maintaining/synchronizing the external and internal user names).

So, do I get it right, that this kind of architecture

would make sense for systems with a "manageable" amount of users?
Thanks!

[skearns (Steve Kearns)]

Hi there - Robbie did a great job with that blog - glad you liked it! I see at least two specific questions, and I think we have reasonable answers for both.

First, when assigning run_as privileges to a user, you can use wildcards. The docs don't seem to make that clear, and we can improve that.

Second, you can use run-as with the LDAP realm, as long as you've configured a bind user, which is a service user that can access the LDAP server to look up the user and properties. We document this here: https://www.elastic.co/guide/en/x-pack/current/ldap-realm.html#ldap-user-search

Hope that helps!
Steve

[jetnet]

hi Steve,

yes, the article is very interesting, as it gave me a hope, that it could be possible to integrate an external auth gateway with ES cluster without having to develop a custom realm.

thank you for the pointing to the non-native realms, how could I only forget about it?!
Regarding the LDAP realm - I still don't have a clear picture, how it could work:
the LDAP technical user (bind_dn/bind_password) will be used to look up user- and group-information. But for the authentication of a particular user in ES:

Once found, the user will be authenticated by attempting to bind to the LDAP server using the found DN and the provided password

And we don't have the "provided password", as the user has been already authenticated on the previous stage (oauth_proxy or some other SSO gateway) - only user-name is available.

It'd great if you could clarify that point as well!
Thanks a lot!