i use session in my application.on locally session is creating and i can see jsessionid is in cookies and also when I called my application directly then it's working as local machine. The issue is when i called this application from other applications by SSO then session id not updated in cookies.
Related
Situation
For my web application, I have set up a keycloak (v18.0.0) realm with an external SAML IDP.
After successfully logging in, the application is using its own cookies (I can't change this since this is an external piece of software) and has a logout endpoint to destroy those cookies when visited through the browser.
In the corresponding client configuration, I set a front-channel logout URI to be called by the browser whenever a logout is triggered from the IDP.
Problem
When triggering the single sign-out from keycloak itself using this "https://baseurl/realms/my-realm/protocol/openid-connect/logout"`, keycloak successfully logs out from the IDP and destroys its own cookies but does not redirect to the front-channel logout URI, which leaves the app in a logged-in state. I tested this without an IDP enabled and it logged me out from my app.
Question
How can I force keycloak to trigger the front-channel logout URI on a single sign-out request?
I have next components:
RP-1 (connected by Ws-Fed, WIF)
RP-2 (connected by SAML, Federation Provider, actially it is another ADFS)
MY-ADFS (ADFS Server 2019 as primary STS)
MY-IP (separate Identity Provider web service, Identity Server 4)
Thus, when I make a sing-out request from RP-1(Ws-Fed), a simple Ws-Fed Logout is formed a request to ADFS:
GET https:/MY-ADFS/adfs/ls/
wtrealm: https://RP-1.com/
wa: wsignout1.0
wreply: https://RP-1.com/logout/
Next ADFS makes redirect to IP:
GET https://MY-IP/WsFederation
wa: wsignout1.0
wreply: https://MY-ADFS/adfs/ls/?redirectContextId=2dd581d2-6e02-4476-915b-a581e3c855d4
thus the user clears the session from ADFS and from IP. - as expected.
However, if before the logout, the transition to SAML RP was made and the SAML session became active, then upon exiting ADFS gives an error:
MSIS7055: Not all SAML session participants logged out properly. It is
recommended to close your browser.
To fix it, I configured the logout endpoint (URL) in the SAML relying party trust as:
https:/RP-2/adfs/ls/?wa=wsignout1.0
With POST binding. After these changes, the error disappeared. But now ADFS no longer does make Logout redirec to to IP, but instead it does a SAML Logout redirect to RP-2:
POST https://RP-2/adfs/ls/?wa=wsignout1.0
SAMLRequest: PHNhbWxwOkxvZ291dFJl
And as a result, Instead of switching to IP, I remain on the RP-2(ADFS also) page where it is written that the exit was successful. However, the user still has an active session (cookies) on the IP side.
Several questions here:
It is not clear why ADFS changes the chain of calls with the SAML active session.
It is not clear how to exclude SAML Logout redirects, or force ADFS to make Logout to IP also.
You will have to add the logout URL in the IP (Identity provider) side as well to ensure that the SAML token generated by signing out from the SaaS application through ADFS is forwarded to the Identity provider and is updated for logout at IP authorization provider end. So that, the cookie on the browser will be updated and sign out will be processed smoothly.
Please find the below probable steps to update the logout URL at the Identity Provider end: -
Open the authentication provider workspace.
Find the logout URL.
Update the URL to the ‘https://RP-2/adfs/ls/?wa=wsignout1.0’ same as that configured in ADFS Server.
Save your changes.
And as for your first query why ADFS changes the chain of calls with SAML active session, it is because the cookies and cache must be removed from the system for successful logout request, thus the logout time as recorded when signing out is updated at the SaaS app end and thus, it is recommended to close the browser let it update in the system also.
Thus, recommend you open both the RP trust apps in different browser windows as both are configured for different token providers.
Please refer the below thread for more information: -
How do you handle the logout process for applications federated with ADFS?
Thanking you,
Our application is protected with OpenAM web agent. We are encountering a situation where after the OpenAM is sending a post request with HTTP_REMOTELOGIN and Set cookie.But as response Iplanetdirectorypro cookie is getting expired. The issue came when the domain of our web site got changed from a.x--> a.y. Things are working perfectly for old URL domain.
Same configuration for the new domain is working on pre production and when the changes where done to Production, the web page after authentication from SSO is not properly loading due to the fact the OpenAM cookie is getting expired.
In the browser we can see the warning as "A cookie associated with a cross-site resource was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032."
The issue is persisting on all web browsers.
We tried various things in IIS such as enabling CORS, disabling secure cookie setting but we had no luck.
So the question is whether OpenAM cookie managed somewhere in IIS which needs to be configured specific to the new domain.
Can anyone help !
I'm playing around with Kerberos SSO. As experimented so far,
When I open a web app that is configured with Kerberos, from the browser, it prompts me for the username and credential, once I enter, I'm logged into the web app .
When I do a kinit from the terminal and give my credentials, I'm signed into the KDC for the given user. After kinit, when I open a web app I'm signed into the web app, without any credentials.
One possible explanation is, when I do a kinit, the TGT is stored in the OS which is available for other clients in the host machine so that my browser was able to use that TGT without prompting me for password.
Now my questions are,
Will I be able to cache the TGT without using kinit?
If yes, how can I do it using a Java client?
If the answer for the first question is yes, will I be able to do it from my web app opened in the browser?
Whenever kinit is executed, a TGT is requested and stored in OS ticket cache.
This TGT can be used to get TGS (service ticket) for multiple services.
If you haven't added your app url as a 'trusted intranet site' in browser, then browser will give you pop-up for the first time for every new session.
Browser accepts the credentials, gets the TGT from your KDC, and puts it in cache. Furthermore, using this TGT, it ask the KDC for the TGS to your app url (usually identified as "HTTP(S)/APP_SERVER_HOSTNAME").
You can verify this-
Perform klist purge to clean all the tickets from cache.
Open browser and hit your app url.
Provide credentials in pop-up and submit.
Execute klist- observe there are two tickets in cache.
One of the ticket is TGT, which spn like - krbtgt#XXX.domain.
The other is TGS for your service - usually "HTTP(S)/APP_SERVER_HOSTNAME".
Please note:
TGT is created by default when you login to the OS. So you can see there's a TGT for your user in OS cache.
OS ticket cache behavior can be platform specific (not verified by me).
You can obtain TGT/TGS or even delegate the credentials using (java)code.
Cache mentioned in your KRB conf is not necessarily the OS ticket cache.
For credential delegation, check out this - Java SPNEGO Authentication & Kerberos Constrained Delegation (KCD) to backend service
We are about to integrate our JAVA application with SSO Federation. We will get a metadata in SAML2 Assertion format and all the session tracking is taken care by SSO federation.
I am not clear how the session tracking happens with each request in our JAVA application. Our main page URL is configured in the SSO federation and after user clicks the link control comes to our application. So if I navigate to other URL apart from the one configured, how the federation track the session? Do we need to pass any metadata for each and every request?
We have been asked to share the home page URL and certificate information and SSO federation will configure those in their portal.
A Java application server normally trackes a user session using a 'JSESSIONID' cookie. Once the SAML assertion generated by an IDP(say ADFS) has been validated by the SP(the java application here) a security context /session is created which is identified by a JSESSIONID. The browser sends JSESSIONID cookie with seubsquest requests and the application verifies it and servers the requetsed resource/URL.