Authentication LDAP is proxied through a Duo 2fa LDAP proxy.
Authorization LDAP is direct connect to the LDAP providers.
Is there an option so that when a user clicks the ‘Logout’ button in Kibana, SearchGuard will delete the cached credentials for that specific user? Setting the searchguard.cache.ttl_minutes setting lower or to zero is not an option due to the Duo 2fa proxy; as soon as the cache TTL expires it will prompt for 2fa authentication again. However, this side effect is actually really useful because by setting a 2-4 hour TTL it acts as a forced inactivity logout (from a 2fa perspective) and/or forced re-authentication on active sessions.
The problem that happens is two fold:
When a user clicks the ‘Logout’ button in Kibana, if they log in again before the cache TTL expires they can essentially bypass 2fa.
Setting a long TTL makes any changes in the LDAP provided roles take potentially a long time to take effect (short of purging the cache…which in this example forces a system wide 2fa re-authentication)
Wondering if there are any configuration options that I am missing that can help in this case, or if there is a better way to approach this?
at the moment this is not possible. The only way to clear the cache is using sgadmin or the REST API. However, we could add a REST call to clear the cache upon logout. Since the REST API is and Enterprise feature, this would not be available in the Community edition. Also, the kibanaserver user needs to have access to the REST API, which can be configure in elasticsearch.yml. What do you think?
···
On Saturday, December 1, 2018 at 8:41:56 PM UTC+1, Brian wrote:
ELK 6.4.2
SearchGuard 23.2
SearchGuard Kibana 16
Using LDAP for both authc and authz.
Authentication LDAP is proxied through a Duo 2fa LDAP proxy.
Authorization LDAP is direct connect to the LDAP providers.
Is there an option so that when a user clicks the ‘Logout’ button in Kibana, SearchGuard will delete the cached credentials for that specific user? Setting the searchguard.cache.ttl_minutes setting lower or to zero is not an option due to the Duo 2fa proxy; as soon as the cache TTL expires it will prompt for 2fa authentication again. However, this side effect is actually really useful because by setting a 2-4 hour TTL it acts as a forced inactivity logout (from a 2fa perspective) and/or forced re-authentication on active sessions.
The problem that happens is two fold:
When a user clicks the ‘Logout’ button in Kibana, if they log in again before the cache TTL expires they can essentially bypass 2fa.
Setting a long TTL makes any changes in the LDAP provided roles take potentially a long time to take effect (short of purging the cache…which in this example forces a system wide 2fa re-authentication)
Wondering if there are any configuration options that I am missing that can help in this case, or if there is a better way to approach this?
No, the purge cache command is an all-or-nothing command. Executing it would purge all caches. The problem here is that Elasticsearch itself does not have any notion of a session. Each request has to carry user credentials, like Basic Auth, JWT, Kerberos ticket etc. In that sense, Elasticsearch is completely stateless. The session is maintained by the Kibana plugin only - we store an encrypted session cookie and the plugin ensures that the credentials are added to each call from KI to ES. So it will be difficult to bridge this gap - we’d need to extend the purge cache command to only remove a single user. I’m wondering if there is a better / easier solution for this. Let me talk with the devs and see if we can come up with something here. I’ll keep you posted.
···
On Monday, December 3, 2018 at 5:52:31 PM UTC+1, Brian wrote:
The REST call would clear the cache for only the single user logging out, or the whole cache for all users?
If it is possible to clear the cache for only the single user that is loggign out, then what you propose sounds acceptable.
Ok, and thank you for the response and considering this.
My use case is a corner case, under normal circumstances the auth refresh that happens after a cache purge is a non-issue and the current implementation is probably perfectly acceptable for a majority of people. Its only when 2fa is integrated inline on that authentication that problems start to happen since the 2fa doesn’t cache credentials, every auth refresh essentially requires the user to re-login. The best way around this is probably a more direct method of 2fa integration on the Kibana side, instead of trying to integrate 2fa inline on the back end (since as you mentioned, Elasticsearch has no concept of a session).
Not that I am requesting a direct integration 2fa option, only playing devils advocate to my own question.