Bug 1823305 - Kibana Logout Function Does not log off user [NEEDINFO]
Summary: Kibana Logout Function Does not log off user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Logging
Version: 4.2.z
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: 4.4.z
Assignee: Jeff Cantrill
QA Contact: Anping Li
URL:
Whiteboard:
: 1847949 (view as bug list)
Depends On: 1836230 1836410
Blocks: 1835578
TreeView+ depends on / blocked
 
Reported: 2020-04-13 08:23 UTC by Shivkumar Ople
Modified: 2020-07-02 05:06 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The signoff link pointed to an incorrect handler for the oauth proxy which provides security for Kibana Consequence: Fix: Modify the signoff link to be correct Result: User's cookie is invalidated and they are navigated correctly to a page that allows them to sign-in again
Clone Of:
Environment:
Last Closed: 2020-06-23 00:57:24 UTC
Target Upstream Version:
cvogel: needinfo? (jkaur)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift origin-aggregated-logging pull 1894 0 None closed Bug 1823305: Fix sign-off kibana link 2021-01-14 21:34:18 UTC
Github openshift origin-kibana pull 35 0 None closed Bug 1823305: Correct sign off link and remove obsolete code 2021-01-14 21:33:39 UTC
Red Hat Product Errata RHBA-2020:2580 0 None None None 2020-06-23 00:57:42 UTC

Description Shivkumar Ople 2020-04-13 08:23:20 UTC
Description of problem:

The logout function doesn't work properly in Kibana. After the user is logged out from the Kibana dashboard, user will be able to login again in the new tab again without having to put in the login credentials.

Version-Release number of selected component (if applicable):

OpenShift version
Server Version: 4.2.14
Kubernetes Version: v1.14.6+b294fe5

How reproducible: Always


Steps to Reproduce:
1. Login to the kibana console
2. Logout from the kibana 
3. Open the <Kibana route> again in the new tab of the browser, and you will be logged in automatically.

Actual results:
Kibana console is not asking for the Login credentials after logging out.

Expected results:
Kibana Console should ask for the login ID & password after logging out from a previous session.

Additional info:

1] Kibana is installed with the EFK stack (Cluster Logging operator).
2] Customer has checked opening the kibana in browser's incogito window too but still they are able to open the kibana dashboard without entering the credentials.

One more  point in the Additional Info about the incognito window behavior:

3] It is not that when user log out from Kibana and try to access the same Kibana in incognito mode, we still get redirected. In that case, we are asked to enter the password. But when we log out from Kibana in an incognito browser and try to access Kibana in the same incognito browser, we can access the GUI even without login again. So basically we experience the same behavior either in a normal browser or incognito browser.

Comment 2 ewolinet 2020-04-23 15:01:02 UTC
Hi,

Can you please clarify on step 3?

> Open the <Kibana route> again in the new tab of the browser, and you will be logged in automatically.

Are you saying that the user is clicking the link to the Kibana route from the console?


> In that case, we are asked to enter the password. But when we log out from Kibana in an incognito browser and try to access Kibana in the same incognito browser, we can access the GUI even without login again.

This sounds like this is more related to the oauth proxy issue holding onto your credentials than something Logging specific.

Comment 4 Jeff Cantrill 2020-04-24 18:46:09 UTC
(In reply to Vedanti Jaypurkar from comment #3)
> Hello Team,
> 
> Below are the outputs from the Customer:

> 3) Type/paste the Kibana URL [1] in a new tab on the same browser. You will
> still get the redirected to the Kibana console as an already logged user.

A new tab or a new private/incognito tab?  If they use a private or icognito tab and are able to login using a different user this indicates its a browser caching issue that can be resolved by the user clearing their browser cache

Comment 5 Shivkumar Ople 2020-04-27 05:34:23 UTC
(In reply to Jeff Cantrill from comment #4)
> (In reply to Vedanti Jaypurkar from comment #3)
> > Hello Team,
> > 
> > Below are the outputs from the Customer:
> 
> > 3) Type/paste the Kibana URL [1] in a new tab on the same browser. You will
> > still get the redirected to the Kibana console as an already logged user.
> 
> A new tab or a new private/incognito tab?  

  -- If they hit the kibana URL in the same browser window/session, just by opening the same kibana URL in the 'New Tab', then they are getting logged in the kibana console directly without needing to enter the credentials. 


If they use a private or icognito
> tab and are able to login using a different user this indicates its a
> browser caching issue that can be resolved by the user clearing their
> browser cache

  -- When opened the kibana URL in a fresh private or incognito window, they are asked for the password/credential which is an obvious thing, but what they actually want is once they are in the new incognito window and again when they are opening a new tab in that same incognito window then they are able to log in without putting in the credentials. So they don't want this behavior.

They want something like they should get asked for credentials whenever they are opening URL in the new TAB in the same browser session/window.

So in a gist, in both the scenarios "In the normal browser window && in the incognito window", they should get asked for the Credentials when they are trying to open the kibana URL in the NEW TAB of the same browser session. 

Hope it is clear


Best,
Shivkumar

Hello Jeff,

Comment 6 Shivkumar Ople 2020-04-27 05:50:29 UTC
(In reply to ewolinet from comment #2)
> Hi,
> 
> Can you please clarify on step 3?
> 
> > Open the <Kibana route> again in the new tab of the browser, and you will be logged in automatically.
> 
> Are you saying that the user is clicking the link to the Kibana route from
> the console?

  -- Not from the console exactly, I was saying here when he hits the URL in the new tab of the browser window where in he was already logged into the kibana. 
And he opened the new tab and hit the URL in that same window, so CU wants to get asked for credentails when he is opening the kibana URL in the new tab. 

> 
> 
> > In that case, we are asked to enter the password. But when we log out from Kibana in an incognito browser and try to access Kibana in the same incognito browser, we can access the GUI even without login again.
> 
> This sounds like this is more related to the oauth proxy issue holding onto
> your credentials than something Logging specific.

-- I have briefed to this query in #5, please check.

Comment 10 ewolinet 2020-05-05 15:17:59 UTC
Since Kibana uses an annotation to redirect to the OCP cluster's oauth, the customer will need to adjust the session expiration for their cluster's oauth client. The default is 24 hours:

https://docs.openshift.com/container-platform/4.1/authentication/configuring-internal-oauth.html#oauth-configuring-internal-oauth_configuring-internal-oauth

Comment 36 Anping Li 2020-06-17 12:09:12 UTC
Test follow Comments 3, 21, 34.  The user can logout as expected.

Case 1: User can login out Kibana

1) Login Kibana as LDAP user
2) Log out Kibana
3) Login Kibana in a new Tab

Result:
   Redirected to the OAuth console. Users need to select the OAuth type and log in again. 


case 2: User can log in out Kibana

1) Login kibana as an github idp user
2) Log out kibana
3) Login kibana in a new Tab

Result:
   Redirected to the Kibana console. Users need to select the OAuth type and auto-login.

Case 3: Only logout Kibana
1) Login Kibana as LDAP user
2) Login console as LDAP user
3) Logout Kibana
Result: Console wasn't logout.

4) Logout console
Result: Kibana wasn't logout.

Comment 38 Jeff Cantrill 2020-06-17 13:02:02 UTC
*** Bug 1847949 has been marked as a duplicate of this bug. ***

Comment 39 Jeff Cantrill 2020-06-17 13:08:32 UTC
(In reply to Anping Li from comment #37)
> As kubeadmin is a very special user,  file a new bug to trace comment 35.
> https://bugzilla.redhat.com/show_bug.cgi?id=1847949

From logging perspective, kubeadmin is no different then any other user; logging only relies on bearer tokens provided by making calls to the api server and the oauth workflow.  There is nothing logging can do to change how the token is acquired, expired or invalidated.  If this is truly an issue with token expiration and not being asked for credentials again I would suggest opening an issue with the auth team to address though I think https://bugzilla.redhat.com/show_bug.cgi?id=1823305#c34 sums it up correctly and its working as expected.

Comment 41 errata-xmlrpc 2020-06-23 00:57:24 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2580


Note You need to log in before you can comment on or make changes to this bug.