We are using Spring Security for managing authentication. The issue we are seeing is that when a user's session is timed out between bringing up a GET form and hitting the save button that does a POST, they are sent to the login page but spring is saving the original post information in the session.
Our app does not bring them back to the original URL after login, but instead sends them back to a common starting page. This works fine, but when the user happens to return to the page they had originally tried to POST to (the form GET and POST are the same URLs) Spring tries to resubmit the POST automatically which is not what we want.
Is there a way to completely disable the SavedRequest storing logic in Spring?
I guess this jira issue of spring security describes your problem and how to handle this.
Based on Nathan's comment on Raghuram's answer, with namespaced XML it's something like this:
<security:http>
<security:request-cache ref="nullRequestCache" />
<!-- ... -->
</security:http>
<bean id="nullRequestCache" class="org.springframework.security.web.savedrequest.NullRequestCache" />
There are two scenarios:
1) If you want that after relogin, user should always get forwarded to the default target URL instead of the orginal requested URL then put always-use-default-target="true" in your security.xml like
<http auto-config="true">
.....
<form-login login-page="/login" always-use-default-target="true" default-target-url="/xyz"
authentication-failure-url="/login?error=true" login-processing-url="/j_security_check"/>
</http>
1) If you want that on session timeout after relogin, user should forward to the orginal requested URL but you do not want to resubmit the form then put session-fixation-protection="newSession" in your security.xml like
<http auto-config="true">
<session-management session-fixation-protection="newSession"/>
.....
</http>
Please put session-management tag as first line in http configuration.
It looks like the session-fixation-protection="newSession" attribute on (2.0) or (3.0) will also resolve the issue
With Spring 4.2.5 I ran into this too.
My case was almost identical: display GET form, wait for session timeout, then POST the form. In my app after re-authentication a start page is displayed. However, if the user then navigates to this GET form, and POSTs it, then the previous POST parameters are remembered and concatenated to the current request, resulting in comma separated values in the #RequestParam variables.
I dumped the session in my authentication controller and indeed I saw a "SPRING_SECURITY_SAVED_REQUEST" named key.
The spring documentation says that by default a "SavedRequestAwareAuthenticationSuccessHandler" is used for retrieving the saved request data from the session and apply it to the request.
I tried to use a do-nothing successHandler but couldn't make it work.
I also tried applying
http.sessionManagement().sessionFixation().newSession();
to the security config but that didn't help.
However
http.requestCache().requestCache(new NullRequestCache());
solved the issue.
Related
When Spring Security evolved from version 3.2.x to 4.0.0, multiple modifications became required when using XML based configuration, as stated in the Migration reference. After following throught, I'm still struggling with a few issues regarding the new form-login#login-processing-url attribute. Even though I have specified it to continue using /j_spring_security_check as path, it keeps the new /login path active.
I have been using Spring Security along with SpringMVC and began developing with version 3.2.7. I have a Controller mapping the path /login to a page that shows the login form and depending on possible parameters received shows a certain error message. Below is my controller
#Controller
public class LoginController {
#RequestMapping(value = "/login", method = RequestMethod.GET)
public String login(#RequestParam(value = "error", required = false) String error,
#RequestParam(value = "logout", required = false) String logout,
Model model) {
if (error != null) {
model.addAttribute("error", "Usuário e senha inválidos.");
}
if (logout != null) {
model.addAttribute("msg", "Logout bem sucedido.");
}
return "login";
}
}
In version 3.2, my spring-security.xml file specified the form-login#login-page parameter to /login, therefore showing my personalized login form (the same path was used for <logout>).
Now, even though I have explicitily configured form-login#login-processing-url, the /login still redirects to spring security's default login page. Besides it, even though I have also specified a logout#logout-url attribute, when login out spring still redirects me to the default login-form with the "logout successful" message, instead of my own controller to show my personalized logout message.
When I use the /login? path, the application shows my own login form, but if I call /login?logout or /login?error, which would, respectively, show my logout and error messages, Spring redirects to the default login page.
Question: Is there a way to fully disable the /login redirection?
I know I could simply change my personalized path to something else instead, such as /signin and avoid the confusion, but I'm doing it as an exercice to understand more about Spring Security 4.x. Besides, I'm concerned an user typing the URL instead of navigating through links would simply drop on spring's default login page.
Additionally, follows an excerpt of my spring-security.xml file, already adapted to version 4.x.
<http auto-config="true" use-expressions="true" disable-url-rewriting="true">
<access-denied-handler error-page="/403" />
<intercept-url pattern="/admin/**" access="hasRole('ROLE_ADMIN')" />
<intercept-url pattern="/power/**" access="hasRole('ROLE_POWER_USER')" />
<form-login
login-page="/login" <!-- my controller -->
default-target-url="/"
login-processing-url="/j_spring_security_check" <!-- to reproduce 3.2 behaviour -->
authentication-failure-url="/login?error"
username-parameter="username"
password-parameter="password" />
<logout logout-success-url="/login?logout"
logout-url="/j_spring_security_logout"/>
<headers disabled="true"/>
<csrf disabled="false"/> <!-- I know it could be ommited -->
</http>
UPDATE (04/16/2015): Looks like a bug on version 4.0.0. Check my answer.
What you need to do is implement a custom AuthenticationEntryPoint to turn off login redirect (which is set to default).
Here is some starter reading information:
http://docs.spring.io/spring-security/site/docs/4.0.0.RELEASE/reference/htmlsingle/#auth-entry-point
Here is also a example of how it is implemented:
http://krams915.blogspot.com.au/2010/12/spring-security-mvc-integration-using_26.html
I have changed my login controller mapping to /access. My login not only works (as expected), but for some reason the application stopped returning Spring's default login form when accessing /login.
It simply does not recognize the path (404 error). The behaviour I described previously, confusion between default and custom login forms when using /login looks to me like a bug. Let's hope gets fixed in future versions.
Therefore, the "fix" I suggest is changing the controller mapping, even though this my reflect in changing the calls on multiple views.
I've created my own UserDetailsService and UserDetails implementations and hooked it up. I can create users, and login as users. However, if I login, logout, and then login again, I'm getting a redirect to a timeout error page. This is because I'm preventing concurrent logins, but it's not working - it used to with the "hello world" auth examples, but now with my own implementations that piece has stopped working correctly for some reason. Spring basically thinks there are 2 sessions when I login, logout, and login again.
Now - I thought this was all handled automatically ....perhaps using your own UserDetailsService means you actually have to implement session management somewhere else as well? I'm sort of blown away that's not mentioned in the docs or in the book Spring Security 3.1 so I'm assuming I'm missing something.
This is in my web.xml bit for listening to session life cycle events
<!-- This listener updates spring-security on httpsession lifecycle events,
in this case to ensure each user can have only 1 session at a time. -->
<listener>
<listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class>
</listener>
and this is in my security.xml to prevent concurrent logins
<!-- This prevents the user from logging in more than once simultaneously -->
<security:session-management
invalid-session-url="/timeout.htm">
<security:concurrency-control
max-sessions="1" error-if-maximum-exceeded="true" />
</security:session-management>
My logout in the security context file is
<security:logout logout-url="/logout"
invalidate-session="true" delete-cookies="JSESSIONID,SPRING_SECURITY_REMEMBER_ME_COOKIE"
logout-success-url="/login.htm?logout" />
I've tried a few permutations of that. None seem to work. invalidate-session="true" is the default value, so I shouldn't even have to specify this. But it doesn't seem to be happening.
O.k., I just reverted everything to try and do in-memory auth and I'm getting the same errors. Meaning, I'm not using my custom implementations anymore. Sorry - I clearly have something wrong somewhere...and this is proving extremely difficult to find. I might have to start from scratch.
Do I have to do something special on logout with my custom UserDetailsService?
Any feedback or guidance is much appreciated.
To my understanding the error-if-maximum-exceeded attribute should be false. Settings the value to false will cause the original session to expire instead of throwing a exception as explained in http://docs.spring.io/spring-security/site/docs/3.0.x/reference/appendix-namespace.html#d0e7768
I discovered it was a conflict between using <session-management> in my configuration and my servlet container. I'm using STS 3.5 (custom Eclipse for Spring projects) with vFabric server that runs in the IDE. The Reference documentation did not refer to this in the actual Session Management section (Section 8). However, buried in Section 4 on auth is this little gem:
Note that if you use this mechanism to detect session timeouts, it may falsely report an error if the user logs out and then logs back in without closing the browser. This is because the session cookie is not cleared when you invalidate the session and will be resubmitted even if the user has logged out. You may be able to explicitly delete the JSESSIONID cookie on logging out, for example by using the following syntax in the logout handler:
<http>
<logout delete-cookies="JSESSIONID" />
</http>
Unfortunately this can’t be guaranteed to work with every servlet container, so you will need to test it in your environment
Well, apparently it doesn't work in STS 3.5
At first I tried to eliminate sections of my <session-management> tag so I could just control concurrency (i.e. have the user only able to log in with one session at a time). However, I just kept getting errors.
So, at this point I've removed the session management stuff altogether and will come back to it when ready to deploy.
I'm using spring 3.1.1 and spring security 3.1.0. I'd like to enforce a policy that all http requests that are not explicitly configured with an <intercept-url pattern="..." access="..."/> entry are handled in a particular way. For requests that match a configured <intercept-url/> I want to use typical role based access decisions. However, for non-matching requests, I want to either respond with a 404 (not found) (or maybe 403/forbidden). I want to do this so that I and other team members are forced to explicitly configure spring security and associated roles for any new endpoints.
I originally thought that I could use <intercept-url pattern="/**" access="denyAll"/> as the last intercept-url and that spring would do what I wanted. This technique works if the user is already authenticated but is a little strange for unauthenticated/anonymous users. For anonymous users, spring detects (in ExceptionTranslationFilter) that the user is anonymous and starts the authentication process when requests like /missingResource are processed. Typically this means that the user is redirected to a login form and, after logging in, is redirected back to /missingResource. So the user has to login in order to see a 404 (not found) page.
I ended up removing the intercept-url pattern="/**" access="denyAll"/> and writing a custom filter that runs after="FILTER_SECURITY_INTERCEPTOR" and responds with 404 for requests that are not matched by the FilterSecurityInterceptor but it seemed a little complicated. Is there a better or simpler way?
you can define a separate http element for intercept url /** with access ="denyAll" and add a custom entry-point-ref to avoid spring to redirect user to login form, you can use existing entryPoint Http403ForbiddenEntryPoint for showing 403 error response or implement your own by implementing AuthenticationEntryPoint.
Hope it helps.
I've been trying out 'Method Level' security on this application I've been working on. The idea is to secure a method which gets called from the presentation layer using DWR.
Now, I've tried adding the following annotations on my method:
#PreAuthorize("isAuthenticated() and hasRole('ROLE_CUSTOMER')")
And corresponding entry in my security context:
<global-method-security pre-post-annotations="enabled" />
On similar lines, I've tried #Secured annotation:
#Secured({"ROLE_CUSTOMER" })
And corresponding entry in my security context:
<global-method-security secured-annotations="enabled" />
Ideally, I would expect that if a user is not authenticated, they should be redirected to a 'Sign in' page and the 'ROLES' should not be checked. In this case, even for an unauthenticated user, this method call results in 'AccessDeniedException'. I need it to redirect the user to a login page in such a scenario.
To take it forward, I even tried handling the accessdenied exception by creating a custom AccessDenied Handler. Unfortunately, the handler never got called but the exception was thrown.
Here's the configuration:
<access-denied-handler ref="customAccessDeniedHandler"/>
This has a corresponding handler bean defined in the same file.
Still no luck. The accessdeniedhandler never gets called.
Just to summarize the requirement, I need to secure a method. If this method gets called, and the user is unauthenticated the user should get redirected to 'Sign In' page (which as of now is throwing Accessdenied execption).
Appreciate your help folks..
EDIT 1: Here is a snippet from the security context:
<http>
<intercept-url pattern="/*sign-in.do*" requires-channel="$secure.channel}" />
.....
.....
.....
<intercept-url pattern="/j_acegi_security_check.do" requires-channel="${secure.channel}" />
<intercept-url pattern="/*.do" requires-channel="http" />
<intercept-url pattern="/*.do\?*" requires-channel="http" />
<form-login login-page="/sign-in.do" authentication-failure-url="/sign-in.do?login_failed=1"
authentication-success-handler-ref="authenticationSuccessHandler" login-processing-url="/j_acegi_security_check.do"/>
<logout logout-url="/sign-out.do" logout-success-url="/index.do" />
<session-management session-authentication-strategy-ref="sessionAuthenticationStrategy" />
<access-denied-handler ref="customAccessDeniedHandler"/>
</http>
<beans:bean id="customAccessDeniedHandler" class="com.mypackage.interceptor.AccessDeniedHandlerApp"/>
I'm not very familiar with DWR, but I know that it's an RPC mechanism. The problem is that an RPC request sent by the client side javascript is not a regular page request initiated by the user who navigates the browser. The response to such an RPC request cannot possibly make the browser navigate away from the current page, because the response is processed by your javascript code and not by the browser.
What you can do is:
Implement a sort of eager authentication: redirect the user to a simple .jsp login page before allowing it to access the webapp (URL) that makes DWR (or any kind of RPC) requests.
If the AccessDeniedException thrown by the remote procedure gets propagated to the client side in some form, you can try to handle it from javascript code, for example by popping up a login dialog, and submitting user's credentials in an AJAX request. (In this case make sure to save the returned session id, and send it back with each subsequent requests.)
I would be interested in seeing the rest of your security.xml file (specifically, the <http> element), because if every user is being denied, it suggests to me that you have an <intercept-url> property which overrides calls to your controller class(es). If not, the added information might help shed some light on the problem.
Assuming I'm way off so far, another likely error point might be the specified access-denied-page itself -- if its path is a protected path (i.e. by <intercept-url>), or if it isn't specified, you might see the errors of which you speak.
Of course, I, too, am unfamiliar with DWR, so I'm somewhat obviously assuming a standard Spring MVC framework...
Okay, I have not had much success finding why I got an AccessDeniedException. Regardless, I've worked my way out of it till the time I find the reason. Here's a couple of approaches I took:
1) As mentioned by Zagyi, I was able to propagate the AccessDenied Exception over to the client side. I could create an exception handler to and redirect the user to the sign in page.
However, I took a different approach (which may not be the most optimal but seems to work as of now. Here's what I've done:
1) Created a DWRAjaxFilter and mapped to only the Remote Objects I am interested in. This would bean only the DWR calls to these remote methods get intercepted by the filter. This is because I do not want all DWR exposed methods to as for a sign in.
<create creator="spring" javascript="downloadLinksAjaxService">
<param name="beanName" value="downloadLinksAjaxService" />
<include method="methodOne" />
<include method="methodTwo" />
<filter class="com.xyz.abc.interceptor.DwrAjaxFilter"></filter>
</create>
2) Here is the actual filter implementation:
public class DwrSessionFilter implements AjaxFilter {
public Object doFilter(final Object obj, final Method method,
final Object[] params, final AjaxFilterChain chain)
throws Exception {
SecurityContext context = SecurityContextHolder.getContext();
Authentication auth = context.getAuthentication();
if (!auth.isAuthenticated()
|| auth.getAuthorities().contains(
new GrantedAuthorityImpl("ROLE_ANONYMOUS"))) {
throw new LoginRequiredException("Login Required");
} else {
return chain.doFilter(obj, method, params);
}
}
}
3) Here is the client side handler:
function errorHandler(message, exception){
if(exception && exception.javaClassName == "org.directwebremoting.extend.LoginRequiredException") {
document.location.reload();
}
}
4) I also added and exception mapper for DWR so that I could convert JAVA exceptions to JS exceptions:
<convert match="java.lang.Exception" converter="exception">
<param name='include' value='message'/>
</convert>
5) This seems to work well as of now. I'm still testing this to see if this fails somewhere.
Would appreciate any more inputs.
I was reading many tutorials and none of them is working for me...
I use Spring 3.1.x with Spring Security. I have a bunch of secured url and many unsecured. Now, when the user is logged in and tries to logout I want him to stay in the same page as he was before so I use this:
<beans:bean id="logoutSuccessHandler" class="org.springframework.security.web.authentication.logout.SimpleUrlLogoutSuccessHandler">
<beans:property name="useReferer" value="true"/>
</beans:bean>
This works fine, however when the user logs out from the secured page it redirects him to the login page, and I would like to redirect to home page.. How can I achieve this?
Thanks in advance!
Since you have custom logic for redirecting, you need a custom LogoutSuccessHandler.
In this handler, you need to add this logic:
String refererUrl = request.getHeader("Referer");
String normalizedRefererUrl = ...; // "Normalize" (if needed) the URL so it is in the form that you need.
if (requiresAuthentication(normalizedRefererUrl, authentication)) {
response.sendRedirect(request.getContextPath()); // home page
} else {
response.sendRedirect(refererUrl); // or normalizedUrl
}
In your requiresAuthentication() method, you need to use some part of Spring Security that determined if the URL needs authentication.
You can use a WebInvocationPrivilegeEvaluator reference there. You get a hold of it through Spring through autowiring by class (since there will be a bean implementing WebInvocationPrivilegeEvaluator).
The evaluator has a method that you can use, isAllowed(uri, authentication).
<security:http auto-config="true">
<security:form-login login-page="/spring/login"
login-processing-url="/spring/loginProcess"
default-target-url="/spring/main"
authentication-failure-url="/spring/login?login_error=1" />
<security:logout logout-url="/spring/logout" logout-success-url="/spring/logout-success" />
</security:http>
logout-success-url from the docs or for a custom succeshandler
as per documentation for spring security if you don't specify logout-success-url then it should be redirecting /. check this configuration and may be you can use SimpleRedirectInvalidSessionStrategy