we use Spring security 3.1.2.RELEASE and we need to switch off HttpSession. Is there any way how to do it? We tryed to use create-session="stateless" attribute of http element, but without any success. Is there any way how to switch of session or at least find where session is created? Thanks
I'd start with this FAQ. You can also find out where the session is created by adding <debug /> to your XML configuration.
Some authentication mechanisms require a session, but others don't. If you use never as the create-session attribute value then Spring Security won't create a session itself. The stateless option should be supported in 3.1, so I'd guess your application is most likely creating the sessions itself. In any case it would help if you clarify what you mean by "without any success" - i.e what actually happens, is there an error?.
Related
According to documentations- https://learn.microsoft.com/en-us/dotnet/api/system.identitymodel.services.wsfederationauthenticationmodule.signout?view=netframework-4.8#System_IdentityModel_Services_WSFederationAuthenticationModule_SignOut_System_Boolean_ and https://learn.microsoft.com/en-us/dotnet/api/system.identitymodel.services.sessionauthenticationmodule.signout?view=netframework-4.8 should clear all the sessions in application. But after calling WSFederationAuthenticationModule .SignOut(true) and SessionAuthenticationModule.SignOut() those session still remains valid. I am using .NET Framework 4.5.
To make cookie configuration SameSite=none the cookies must be made secure which we have done in Web.config file. But the WS Fed Authentication Sign out is not clearing the sessions as per the documentations. Reference- https://support.okta.com/help/s/article/FAQ-How-Chrome-80-Update-for-SameSite-by-default-Potentially-Impacts-Your-Okta-Environment.
I think this is due to buggy WS FED module by .NET Framework. Any help is much appreciated. Thanks.
Just to help others out with this same problem.
You have to change the "No SameSite" rule to also check for the "secure" flag. Like this:
<add input="{RESPONSE_Set_Cookie}" pattern="; secure" />
This is because WSFederation will do the clearing of the cookies without adding the secure flag and without the secure flag, chrome ignores the set cookie request to clear the cookies.
You don't need to do anything else, like clear/set the cookies manually, just use the SignOut() method provided by the WSFederationAuthenticationModule.
Spring Session uses a different format for its session cookies than Tomcat does. So if you implement Spring Session, even if you would name the session cookie JSESSIONID, all the users have to login again.
This is a point where you potentially lose users, because nobody likes to login. Perhaps this is an edge case, and certainly it's not worth a huge amount of trouble, but I'm curious if it's possible for existing users to use their already stored Tomcat session cookies?
You can implement your own org.springframework.session.web.http.CookieSerializer that matches Tomcat's default cookie serialization and register it as a bean.
Spring Session configuration will then pick it up and use it - see org.springframework.session.config.annotation.web.http.SpringHttpSessionConfiguration#setCookieSerializer for more details.
How I can create instance for per-request lifescope with cookie's data as parameter?
For example:
container.Register<ISampleRepository>(() =>
new SampleRepository(
container.GetInstance<ApplicationDbContext>(),
request.Cookie["Token"]));
As NightOwl888 stated in his comment:
Cookies are runtime data that are user specific (and already tied to the request). Dependency Injection is something that happens 1 time at application startup for all users in the composition root. It makes absolutely no sense to have a user's cookie as an input to your application configuration. Perhaps it would be better if you describe what it is you are trying to achieve with your cookie.
The problem you are having with the right way to solve this is described fully in this blog post.
Is it possible to somehow bypass spring security for certain cases? We are currently using spring security 3.1.x and this setup is working well (form-login, etc).
For our web-api, we now have a requirement that certain objects can be set as 'external' meaning that they should not require login. All objects will be under /api/* but the actual path will be dynamic (usually its /api/{type}/{id}).
Any suggestions?
you can define the url pattern in separate http to bypass spring security filter chain, like this
<http pattern="/api/**" security="none"/>
I am using Spring Security 3.0.5 and Camel 1.5 (yes, very old but we don't have time to update right now).
In this particular scenario I am uploading a file which hits a Spring Controller which then redirects the request body (which is XML) to an endpoint which is a method in another class. Here is the issue: I had a tester perform an upload but when the GUI listing of files came back it had another person's name as the person who uploaded the file. During debugging I found that in the first Spring Controller the SecurityContext is correct in that it is indeed the credentials for the person performing the upload. After the Camel redirect though the SecurityContext was for another user who happened to have a session in the web app. Obviously this is not good.
So two questions:
Does anybody know what to do or if there is anything I can do using Camel 1.5 to fix this issue?
Why would the credentials of another user from another session be in this session? This question is regardless of Camel.
What http are you using? Can you check if there is a single thread only processing the request at all time, or is multiple threads involved?
And btw Camel 1.5 is EOL, and not support at all anymore.