When asking questions, please provide the following information:
Search Guard and Elasticsearch version: 6.5.4-oss-24.2
Hello
We have a kibana with search guard plugin exposed via kubernetes nginx ingress(reverse proxy).
We have enabled authentication on ingress level and forward the Authorization header to the kibana. The log-in is working fine because we are using the same username and password for the ingress and kibana and we do not have to type the credentials twice.
It looks like the kibana is using a cookie to keep the credentials data, while the ingress keeps it in the Authorization header.
If we try to logout from the kibana, we are redirected to the login screen of the Search Guard with non-invalidated or removed Authorization header. So If I try to open the root path <kibana-hostname>/ I am successfully logged in, because the Authorization header is still valid.
On the other side, If try to log in with other user with different permissions, the dashboard shows me as the other user, but I am actually logged in as the first one that is coming from the Authorization header. As result the second user has the permissions of the first one.
So generally, the logout is not working very well when the search guard is enabled to accept Authorization header.
Is it possible to make the search guard to invalidate the Authorization header on log out ?
to advise on that let me try to understand the use case a bit better.
So the auth/auth is taking part on the Ingress level. Upon successful authentication, does Ingress add the HTTP Basic auth header to each request from Ingress to Kibana? Or just for the very first one?
If the authentication headers are present in each request, then we do not need the session cookie at all. We would just grab the auth header from each request, and forward it to ES/SG. If the auth headers are present only once, i.e. in the first request, then we need to store the credentials in the session cookie.
If authentication takes place solely on Ingress, then you are right, redirecting the user to the login page does not make much sense. Does Ingress has something like a logout endpoint?
···
On Thursday, March 28, 2019 at 4:06:52 PM UTC+1, Владимир Начев wrote:
When asking questions, please provide the following information:
Search Guard and Elasticsearch version: 6.5.4-oss-24.2
Hello
We have a kibana with search guard plugin exposed via kubernetes nginx ingress(reverse proxy).
We have enabled authentication on ingress level and forward the Authorization header to the kibana. The log-in is working fine because we are using the same username and password for the ingress and kibana and we do not have to type the credentials twice.
It looks like the kibana is using a cookie to keep the credentials data, while the ingress keeps it in the Authorization header.
If we try to logout from the kibana, we are redirected to the login screen of the Search Guard with non-invalidated or removed Authorization header. So If I try to open the root path <kibana-hostname>/ I am successfully logged in, because the Authorization header is still valid.
On the other side, If try to log in with other user with different permissions, the dashboard shows me as the other user, but I am actually logged in as the first one that is coming from the Authorization header. As result the second user has the permissions of the first one.
So generally, the logout is not working very well when the search guard is enabled to accept Authorization header.
Is it possible to make the search guard to invalidate the Authorization header on log out ?
So the auth/auth is taking part on the Ingress level.
Yes
does Ingress add the HTTP Basic auth header to each request from Ingress to Kibana?
**Yes, the Authorization header is part of every request to the Kibana, not for the first one only.
then we do not need the session cookie at all.
How could I disable cookie usage?
Does Ingress has something like a logout endpoint?
Unfortunately, it has no logout endpoint.
So for my use case, I need to disable the credential cookie and make “logout” button of the Search Guard invalidate the Authorization header.
Best Regards
Vladimir
четвъртък, 28 март 2019 г., 17:46:22 UTC+2, Jochen Kressin написа:
···
Hi,
to advise on that let me try to understand the use case a bit better.
So the auth/auth is taking part on the Ingress level. Upon successful authentication, does Ingress add the HTTP Basic auth header to each request from Ingress to Kibana? Or just for the very first one?
If the authentication headers are present in each request, then we do not need the session cookie at all. We would just grab the auth header from each request, and forward it to ES/SG. If the auth headers are present only once, i.e. in the first request, then we need to store the credentials in the session cookie.
If authentication takes place solely on Ingress, then you are right, redirecting the user to the login page does not make much sense. Does Ingress has something like a logout endpoint?
On Thursday, March 28, 2019 at 4:06:52 PM UTC+1, Владимир Начев wrote:
When asking questions, please provide the following information:
Search Guard and Elasticsearch version: 6.5.4-oss-24.2
Hello
We have a kibana with search guard plugin exposed via kubernetes nginx ingress(reverse proxy).
We have enabled authentication on ingress level and forward the Authorization header to the kibana. The log-in is working fine because we are using the same username and password for the ingress and kibana and we do not have to type the credentials twice.
It looks like the kibana is using a cookie to keep the credentials data, while the ingress keeps it in the Authorization header.
If we try to logout from the kibana, we are redirected to the login screen of the Search Guard with non-invalidated or removed Authorization header. So If I try to open the root path <kibana-hostname>/ I am successfully logged in, because the Authorization header is still valid.
On the other side, If try to log in with other user with different permissions, the dashboard shows me as the other user, but I am actually logged in as the first one that is coming from the Authorization header. As result the second user has the permissions of the first one.
So generally, the logout is not working very well when the search guard is enabled to accept Authorization header.
Is it possible to make the search guard to invalidate the Authorization header on log out ?
Thanks for the information. In my view this means that Ingress is acting like a proxy (taking care of adding auth credentials to all requests), so you actually do not need the login screen / session cookie at all. To use proxy authentication set the following in kibana.yml:
searchguard.auth.type: “proxy”
``
This will simply pass all requests with all headers from Kibana to ES/SG without using a session cookie.
“make “logout” button of the Search Guard invalidate the Authorization header”
This is not possible because you cannot invalidate an HTTP Basic header. The header just contains the username and password base64 encoded, and there is no state. Since your proxy is performing authentication, you need to find a way to end the user session there.
···
On Thursday, March 28, 2019 at 5:00:05 PM UTC+1, Владимир Начев wrote:
Hi
So the auth/auth is taking part on the Ingress level.
Yes
does Ingress add the HTTP Basic auth header to each request from Ingress to Kibana?
**Yes, the Authorization header is part of every request to the Kibana, not for the first one only.
then we do not need the session cookie at all.
How could I disable cookie usage?
Does Ingress has something like a logout endpoint?
Unfortunately, it has no logout endpoint.
So for my use case, I need to disable the credential cookie and make “logout” button of the Search Guard invalidate the Authorization header.
Best Regards
Vladimir
четвъртък, 28 март 2019 г., 17:46:22 UTC+2, Jochen Kressin написа:
Hi,
to advise on that let me try to understand the use case a bit better.
So the auth/auth is taking part on the Ingress level. Upon successful authentication, does Ingress add the HTTP Basic auth header to each request from Ingress to Kibana? Or just for the very first one?
If the authentication headers are present in each request, then we do not need the session cookie at all. We would just grab the auth header from each request, and forward it to ES/SG. If the auth headers are present only once, i.e. in the first request, then we need to store the credentials in the session cookie.
If authentication takes place solely on Ingress, then you are right, redirecting the user to the login page does not make much sense. Does Ingress has something like a logout endpoint?
On Thursday, March 28, 2019 at 4:06:52 PM UTC+1, Владимир Начев wrote:
When asking questions, please provide the following information:
Search Guard and Elasticsearch version: 6.5.4-oss-24.2
Hello
We have a kibana with search guard plugin exposed via kubernetes nginx ingress(reverse proxy).
We have enabled authentication on ingress level and forward the Authorization header to the kibana. The log-in is working fine because we are using the same username and password for the ingress and kibana and we do not have to type the credentials twice.
It looks like the kibana is using a cookie to keep the credentials data, while the ingress keeps it in the Authorization header.
If we try to logout from the kibana, we are redirected to the login screen of the Search Guard with non-invalidated or removed Authorization header. So If I try to open the root path <kibana-hostname>/ I am successfully logged in, because the Authorization header is still valid.
On the other side, If try to log in with other user with different permissions, the dashboard shows me as the other user, but I am actually logged in as the first one that is coming from the Authorization header. As result the second user has the permissions of the first one.
So generally, the logout is not working very well when the search guard is enabled to accept Authorization header.
Is it possible to make the search guard to invalidate the Authorization header on log out ?