It's all about the answers!

Ask a question

Problem with authentication in JRS with enabled Kerberos/SPNEGO SSO


Marko Tomljenovic (31650109) | asked Sep 18 '18, 3:39 p.m.
edited Sep 19 '18, 10:56 a.m.

Hello,

I have identified the following problem while testing SSO in our CLM 6.0.5 installation. Steps to reproduce the problem are:
  1. A new browser window is opened without any URL given.
  2. Using the [rs host]/jts/auth/authrequired url I perform a login with user "A"
  3. In the same browser tab switch the URL to RS in order to open JRS. There user "A" is listed as logged-in user
  4. Now open again the jts/auth/authrequired page in the same tab and login with user "B"
  5. Now open ccm in the same tab, it is visible that user "B" is logged in
  6. Now open the JRS page in the same tab.
  7. Here it is visible that still user "A" is logged in rs.
Only known workaround is to shutdown browser window before logging in to RS with a different user. 
Can somebody explain this behaviour? Does JRS use some different/additional cookies for authentication than the other applications, ...?

Could some other applications be affected in the same way?


Comments
Marko Tomljenovic commented Sep 19 '18, 11:02 a.m.

I did some more testing. Actually it does not seem to work for all applications that are using delegated authentication (all except RTC, RQM and JTS). 

Accepted answer


permanent link
Ralph Schoon (63.5k33646) | answered Nov 01 '18, 6:58 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Nov 01 '18, 6:59 a.m.
For 7. Here it is visible that still user "A" is logged in rs.

For all I know if you refresh the page showing User A is logged in, it should show User B


I don't think it is supported to be logged in as different users in the same browser, and this is also behavior that is unrelated to PNEGO/Kerberos. I see the same e.g. in demos - which is why I use different browsers for each user. This is all related to the same cookies and session ID headers being used in browsers. Another trick at seems to be using "private sessions". I have not looked int this too deep though.

Marko Tomljenovic selected this answer as the correct answer

Comments
Marko Tomljenovic commented Nov 05 '18, 3:49 p.m.
Hi Ralph,
You are right that this is independent of Spnego/Kerbero.
You are also right that it is not supported, otherwise I wouldn't ask ;). And it is most likely also not an urgent or important feature but technically it should not be any problem that every login simply overwrites the cookies so that the correct user is identified, isn't it?

I will not create an enhancement request for this due to the relatively low importance of this feature for our end users AND we have an less efficient but still easy workaround for it.

Thank you

One other answer



permanent link
Marko Tomljenovic (31650109) | answered Sep 20 '18, 10:44 a.m.

I have done some more cookie research on the topic and found out the following:

The first time a user is authenticated against e.g. rs or rm the cookie JAZZ_AUTH_TOKEN is created that I guess related to the other two tokens JSESSIONID and LtpaToken2.

When I login with a new user only the LtpaToken2 is changed but not the two other ones. So I feel the problem here is that the JAZZ_AUTH_TOKEN would need to be updated but is not and therefore the first user is still logged in.

Can somebody confirm my assumption and propose whether I should file an Enhancement/Bug for this?

Thank you


Comments
Fariz Saracevic commented Nov 01 '18, 5:05 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

Hi Marko,


Did you follow up with support on this forum posting? Is this still something you are facing in your environment? 


Regards 


Ralph Schoon commented Nov 06 '18, 1:49 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Please feel free to submit this as a defect or enhancement, Marko. 

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.