I have configured SSO for Jenkins via google workspace.
https://support.google.com/a/answer/9002495?hl=en
This works as expected but after the session expires or when trying to login after closing the tab, it gives below error. Clicking log in just keeps redirecting to the same error page.
However, it works after clearing cookies every single time before logging in. Any idea why this is happening or a solution to login without having to clear browser cookies every single time?
Thank you in advance.
Google does not support SAML SLO, so this message seems to be expected behavior (meaning that the app could expire their login session but Google will remain logged in).
What I can recommend is to change the session limit on Jenkins and I found some references about it, hope it can come in handy:
References:
Jenkins login session timeout
Github -Jenkins session timeout configuration
Related
I setup a SPA authentication with Laravel Sanctum, it works fine. I login successful with an user. In Chrome Devtools, Application > Storage > Cookies, I copy and save the values of laravel_session and XSRF-TOKEN to a text file, then logout and delete all cookies and refresh browser, here I logged out.
Then I re-open Devtools, restore the values of laravel_session and XSRF-TOKEN manually, refresh browser, now my status is logged in.
Is this normal? Is this the way that cookie based session authentication work?
Thank you.
I was running into the same issue. My problem was that I called Auth::logout() instead of Auth::guard('web')->logout(); inside my AuthController in Laravel.
By using Auth::guard('web')->logout(); the cookies seem to get revoked by the server and can't be used for authentication any more.
By the way, I found the answer here: https://stackoverflow.com/a/63449251/10095327
I have some MVC websites that are being authenticated against ADFS.
Some users are facing an issue where they get stuck on loop after inputing their credentials. Then I get this event logged:
Additional Data
Protocol Name:
wsfed
Relying Party:
https://xxxxxxxxxxxxxxxxxxxx
Exception details:
Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '6' seconds. Contact your administrator for details.
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateLoopDetectionCookie(WrappedHttpListenerContext context)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.SendSignInResponse(WSFederationContext context, MSISSignInResponse response)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
I tried cleaning browser cache, but never got it to work. I can login with any user credentials on my PC, but when some users try to login on their PCs they get the error. In all browsers, with all user credentials.
I'm getting nuts because of that. It seems something related to the OS and not to the browser.
It does work perfectly with SAML.
Does anybody know anything about it?
Not sure if you have the same problem, but what happened to me before was because of javascript or cookies issues. As a result, the relying parties didn't receive tokens or tokens couldn't be written to authentication cookies and the relying parties ended up with sending new authentication requests to ADFS. Tools such as Fiddler can help troubleshooting this type of issue.
I have a REST service that is running on https://localhost:9090.
In order to provide token based authentication with Oauth2.0 for consumers of my REST service, I have cloned the 4.2 version of CAS from repository https://github.com/leleuj/cas-pac4j-oauth-demo and deployed only cas2.war (cas server) on tomcat 7. From the browser, I hit this URL :
https://localhost:8443/cas2/login?response_type=code&client_id=this_is_the_key&redirect_uri=https%3A%2F%2Flocalhost%3A9090%2Fv1%2Ffiles%2Fafb2265b-39e9-4172-bccc-e3f43700874e
I got the cas login page and after the successful login with valid credentials (leleuj::leleuj), I was not redirected to my service api as mentioned in the URL. Instead, the browser still shows the success cas login page. Is there something wrong in what I am doing? Sorry if this is a basic question, I am somewhat new to CAS.
As I'm leleuj on github, it feels a question for me ;-) Indeed, this doesn't work running mvn jetty:run, but if you run the webapps in Tomcat, it works, I haven't investigated more as CAS 5 is out now!
Keycloak, WSO2 and some other SSO IDP servers offer a possibility of "Single Logout" without forcing browser to redirect to every SP where current user is logged in by sending the <LogoutRequest> over HTTP-POST via back channel.
Unfortunately this does not work if SSO integration in the service is implemented using spring-security-saml2-core library (we are using Keycloack).
All I could figure out from the log file on the SP side was:
[2016-01-13 12:50:56.867] [DEBUG] [org.springframework.security.saml.SAMLLogoutProcessingFilter] - Received logout request is invalid, responding with error
org.springframework.security.saml.SAMLStatusException: No user is logged in
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.processLogoutRequest(SingleLogoutProfileImpl.java:168)
at org.springframework.security.saml.SAMLLogoutProcessingFilter.processLogout(SAMLLogoutProcessingFilter.java:176)
at org.springframework.security.saml.SAMLLogoutProcessingFilter.doFilter(SAMLLogoutProcessingFilter.java:102)
...
The application that uses Spring SAML extension is deployed on the Tomcat 7. It seems that <LogoutRequest> when sent via back-end channel does not have a browser session cookie, and user application session cannot be identified, so user cannot be logged out and the application session of the user will not be invalidated.
However the <LogoutRequest> contains the global SSO session identifier which can uniquely identify the application session. But this does not happen.
Is this behavior of the Spring SAML library intended by desing: do not support back-end communication during Single Logout? or am I missing something and the desired behavior can be configured?
Note: I understand that according to SAML specification HTTP-POST and HTTP-Redirect bindings are intended to be carried via User Agent (web browser), however broad support from SSO IDP servers made me ask this question :)
Thank you in advance!
UPDATE: According to Vladimir Schäfer's comment in the SES-162 ticket it seems to be an intended library behavior.
In Spring-SAML, Single Logout is currently supported with HTTP-Redirect and HTTP-POST bindings. SOAP binding is not available. Refer : Spring SAML Global Logout
Back channel is not supported in spring-saml
No, it is not possible to carry out <LogoutRequest> over HTTP-POST via back channel using Spring-SAML library.
This behavior is against SAML specification and according to Vladimir Schäfer's comment in the SES-162 ticket it will not be supported by Spring-SAML.
SOAP binding is meant for backend channel, but as it is noted by #meetarun it is not implemented in Spring-SAML library at the moment.
I am using JSF richfaces 3.3 on websphere server 7.x.
The problem is when
user logged in to the application using a browser window and had kept it open for more than LTPA token time out time then LTPA token expiration exception is occurring. Then page is not redirecting to the "logout" page configured. But it getting redirected to the Login page and after successful login then a weird xml page is displayed.
I understand that this is happening because on LTPA token time out when we try to access a JSF resource, as no authentication details are present page is being redirected to login page.
Then as no proper session is present Faces context is still trying to access previous session JSF tree this exception is occurring.
So Question is: How to handle this scenario of LTPA token time out in JSF richfaces3.3?
P.S.: Page is getting redirected to "logout" page on web session expiration.
Vamshi,
If the LTPA token has expired and you try to access a secured resource it will naturally take you to the login page.
That is the expected behaviour!
After you login again you go back to the page you had requested. Depending on your app, either a new HTTPSession is created or it might not even be created during this.
The application should be built to handle this. One approach could be to redirect the user to the main page of the application stating that required information is not available and that you are redirecting the user (after examining the HTTP Session for required information)
HTH