I have a Spring Boot (1.5.6) with Spring Security (4.2) with ThymeLeaf application that allows a user to reset their password. All html pages are in src/resources/templates. The basic flow is:
user provides username (via resetPage.html)
credentials are cleared
token is generated and emailed to username email
user clicks url from email is redirected to reset password page (changePassword.html) for user to create new password
new password is post'd to service where it is persisted and is handled by this code:
#RequestMapping(value = "/user/savePassword", method = RequestMethod.POST)
public String savePassword(Locale locale, #RequestParam("username") String username,
#RequestParam("password") String password, Model model) {
// logic goes here
...
"return "login";
}
At this point everything has worked as desired. The db has been updated, no errors in the console log.
The user is prompted to the login page (although the browser bar says "savePassword) to login. The username and new password are provided and the server returns a 403. There is no error in the console, the only indication that something went wrong is the Chrome Developer Tools returning a 403 from the login POST. The default error page is shown.
If I navigate to the home & then login page, I can authenticate with the newly changed credentials.
I do not see where the error is coming from or why. I have tried running via "java -jar" and with the IDE debugger with debug comments turned on. No errors or messages at all are generated. There is no session, the user had not authenticated, so why would a 403 be thrown (assuming via Spring Security)?
I finally tracked this down. Because the logs were free of any information, I figured it was Spring Security framework doing the work. I updated the security configuration to disable CSRF for the /login page. Now it works as desired.
See your authentication methods and make sure both passwords match in DB or not.
Make sure when changing new password are you using passwordEncoders?. Because 403 error is Forbidden.
Related
We are working on an existing application where web services (tomcat) as well as UI (nginx) applications are hosted on separate containers. One of the service application is used for sending login request (SAML request) to identity provider (ping). Here are the steps for user login to the system:
User loads the application (domain URL: https://ui.domain.com), it loads the UI where it checks for logged in user (JWT token string generated for user/role) on local storage and when not found, it redirects to ping (IDP) for authentication.
Once authenticated with ping, it calls the spring controller which is configured for the success URL on service application (https://api.domain.com/auth-service/auth).
This controller service (/auth), gets the SAML response sent by ping and processes it further to get user details and generates the JWT token for the user and redirects the user to UI (https://ui.domain.com).
Problem Statement:
To pass the token to UI, the JWT token string is added to URL by using
redirectAttributes.addAttribute(“auth-token”, token);
With the above, it shows up in the address bar like: https://ui.domain.com/?auth-token=
This has raised a concern with respect to security as the token is displayed on address bar and exposed which can be decoded to get user information.
Current Approach (tried):
Before redirection from controller to UI, tried to set cookie
Cookie cookie = new Cookie(“auth-token”, token);
cookie.setMaxAge(-1);
cookie.setPath(“https://ui.domain.com”);
response.addCookie(cookie);
However we couldn’t find the cookie from UI.
We tried to set it to response header too.
response.addHeader(“auth-token”, token);
Since it is a redirection, the adding to response doesn’t help.
Further trials:
We are also putting a thought about changing the approach of authentication controls where after ping authentication is done, the success URL can be replaced with UI url rather than service URL, i.e.
Current: saml.sso.default-success-url= https://api.domain.com/auth-service/auth
Proposed: saml.sso.default-success-url= https://ui.domain.com/
With the above, the SAML response supposed to go directly to UI (after ping authentication is successful).
However we couldn’t get the response in UI and it also behaves like ping is doing a redirection to UI and due to the same reason, UI doesn’t get it.
Any ideas and suggestions over this would be great.
Have the below route defined in web.php Testing Using laravel 5.5 in my local mac laptop withvalet
Route::get('/cart/add', function () {
// Only authenticated users may enter...
return "hello owlrd123";
})->middleware('auth.basic');
First time when I hit the url http://eshop.dev/cart/add it prompts for username and password. When i enter the valid credentials it displays the message "hello owlrd123". Cleared the cookie & session(laravel_session,XSRF-TOKEN) in chrome and when i hit the url again it doesnt prompt for credential it directly displays the message "hello owlrd123". How does it remembers the session? I dont want it to remember the session.
You are using auth.basic, there is no proper way of logging out with Basic Authentication, it was simply not designed to handle logging out.
There are some ways in which you could invalidate basic auth, but none are proper fixes.
Closing browser completely
Pop up another auth window and send a 401
See these answers for more info:
- How to log out user from web site using BASIC authentication?
- How to logout user for basic HTTP authentication
Main question is:
Why are you using basic auth instead of cookies for this?
We are working on an application, which is protected with spring security saml.
Authentication works fine, but there is one problem with the following workflow in production environment.
user requests the unprotected address www.server.com
response is a html page with an inline script that changes window.location.href to the saml protected page (service provider) www.server.com/app/action?param1=value1¶m2=value2
spring saml detects that authentication is needed and redirects the user to the login form (identity provider) on www.login-server.com
at this point the login form is the first page that is displayed to the user
user adds this login page as bookmark (including saml related url params for this http session) www.login-server.com/adfs/ls/?SAMLRequest=xxx&SigAlg=xxx&Signature=arGdsZwJtHzTDjQP1oYqbjNO
user works with the application...
at the next day the user opens this bookmark and login
IdP redirects to the SP but the belonging http session has already expired
Now we get the following exception in our application:
org.opensaml.common.SAMLException: InResponseToField of the Response doesn't correspond to sent message arGdsZwJtHzTDjQP1oYqbjNO
Any ideas how to handle this workflow so the user can use the application after successful login?
Thanks for your answers!
We have solved our issue with following changes to the spring saml configuration:
In bean with id successRedirectHandler (org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler) we set the defaultTargetUrl to the init-Action of our application (including all request parameters). This url will be automatically used in case of IdP initiated SSO.
In Bean with id contextProvider (org.springframework.security.saml.context.SAMLContextProviderLB) we set storageFactory to org.springframework.security.saml.storage.EmptyStorageFactory. This disables the check of the InResponseToField.
When you applicate generated an AuthnRequest, the request has an ID which your application somehow keeps. The corresponding response from IdP must have InResponseTo attribute set to that same ID value so that your application can verify that the response is meant to be for the request it sent.
However, when your user bookmarked the adfs link that contains request (www.login-server.com/adfs/ls/?SAMLRequest=xxx...), your application had totally forgotten about that request. In other word, it no longer kept the request ID somewhere and couldn't verify response.
The solution is to tell your users not to bookmark the www.login-server.com/adfs/ls/?SAMLRequest=xxx... link. Instead, they must bookmark a link in your application where it can generate a new request and send to ADFS.
I am using Shiro with Jersey in a REST API. I am using the form based authentication since I need to send from my angular app a post message in order to authenticate (username, password). There is no jsp nor other page, just the filter and corresponding realm.
I am having following configuration: I have my custom FormAuthenticationFilter, let's say MyFormAuthenticationFilter. Then, in configureShiroWeb I have
addFilterChain("/login", Key.get(MyFormAuthenticationFilter.class));
When I access the /login path with correct credentials sent with post request for the first time, I get logged in. So far so good. The problem is that when I log in successfully and try to access the /login path again, then I get 404. I understand that there's no resource under this path, but is it possible to somehow make it return no content in case I am already logged in?
Thanks
BR
I have been working on this for several days, and hope someone can help me.
There are three requirements for the authentication processing.
Authentication using OpenID, login page is login.jsp. After login is successfully, display the username and email address at login-succ.jsp
There is a input field in the login.jsp, I also need to display the value of mymessage in the login-succ.jsp if login is successfully
After login successfully, user is in the login-succ.jsp, with his username email address and mymessage value. If user refresh the login-succ.jsp page, these three values should be display again.
I have tried to achieve these three requirements using CustomOpenIDAuthenticationFilter at my another post, but if I save the message into session and there are two instances of login.jsp, the two instances will overwrite the message values to each other after refresh action. I do not know if I am doing everything wrong. So can anyone please give me some suggestions about how to meet these three requirements using Spring security and Spring MVC.
Thanks.
To me, this feels like a design that is begging for some type of injection attack (taking a URL parameter that is displayed blindly on the page to the user is a really bad idea).
Instead, I would stick the message in the HttpSession prior to the user being redirected to OpenID login, and retrieve the message after they are successfully redirected. Obviously, you would need code to clear the message from the session upon failure, logout, etc.