I was working on a Spring-security LDAP application. I'm following the link - https://spring.io/guides/gs/authenticating-ldap/ . Problem I'm facing is that I have made a very simple controller and a method to handle a request, returning a string. But browser is opening a login page (which I can't find anywhere). I deleted cache, restarted Eclipse and system both but to my dismay it displays the same page irrespective of any url configured in controller or any port. I'm unable to elucidate this behavior of browser.
If you had followed the guide exactly as it is, then you may notice that the file WebSecurityConfig.java has the following line http.authorizeRequests()
.anyRequest().fullyAuthenticated()
.and().formLogin(); Which means that all your requests need to be authenticated. That means any end points that you define need to be authenticated too. They are secured by default.
You seem to have made a GET request to your endpoint, which is secured by Spring Security. If you want to create an unsecure endpoint then you have to make changes to the WebSecurityConfig file.
The login page that you mention is provided by Spring security library itself. It won't be available in your cloned project. At the end of the page they have also mentioned that the username is ben and password is benspassword. Spring security provides lot of default options which are useful. But, unless you read the documentation to understand what they are, you are in for quite a few surprises.
Related
I'm in need of changing the DefaultRedirectStrategy used out of the box by the LoginUrlAuthenticationEntryPoint.
The scenario is when an unauthenticated user navigates a secured URL: I can see from the logs that LoginUrlAuthenticationEntryPoint.commence is called, and, following the flow, eventually a DefaultRedirectStrategy is called. The login URL created for the redirect, however, is not correct because of a reverse proxy (built on Apache) sitting in front of the web application.
I already did the same in many spots (for example in the logout success handler, which was doing exactly the same, but it was easy to customize with my own redirect strategy). In this case I can't find an obvious way to tweak the LoginUrlAuthenticationEntryPoint.
Is there a way I can do that?
In our project we where using spring-security 4.1.3 and the behavior was as follows :
when the user is a remember me and want to access a page that requires a full authentication, a redirection will be made to a custom page (not login) using AccessDeniedHandler to enter a password confirmation from it
Once we upgraded to release 4.2.20 we are facing a problem with the remember me feature the application behaves as follow :
when the user is a remember me and want to access a page that requires a full authentication, a redirection will be made to the login page
When I checked the source code from spring-security I found that a change was made in the mentioned version
https://github.com/spring-projects/spring-security/blob/20577c39c1eba147a033624f37414f63aba2f99e/web/src/main/java/org/springframework/security/web/access/ExceptionTranslationFilter.java#L183
in the handleAccessDeniedException method a check of isRememberMe was added that it's causing the problem
I am wondering if this is the normal behavior for ExceptionTranslationFilter.java or I must added some customization in my code to make it works as before, if so how ? Thank you in advance.
This situation was mentioned in the original bug of spring-security https://github.com/spring-projects/spring-security/issues/2427
I am quite new to using Spring and the Spring security, so maybe the problem is small.
Current set-up:
We have made an application using Vaadin, Spring and Keycloak. Now to my understanding Spring security and Keycloak can work together to make pages accessible to logged in users or not. So far we have multiple pages that work just fine, as long as you are logged in.
Goal:
Now we want to add a public page "hardware", that requires no login. This seems to be harder than it should be? The hardware URL would be like /hardware/(valid serial number). The /hardware path itself does not exist and is never used as a path, only in combination with the serial number!
Attempt:
In our SecurityConfig we have the following code:
http.csrf()
.disable()
.logout()
.logoutUrl("/logout")
.permitAll(false)
.and().authorizeRequests().antMatchers("/vaadinServlet/UIDL/**").permitAll()
.and().authorizeRequests().antMatchers("/vaadinServlet/HEARTBEAT/**").permitAll()
.and().authorizeRequests().antMatchers("/hardware/**").permitAll()
.and().authorizeRequests().antMatchers("/**").hasAuthority(Privilege.AUTHENTICATED);
But now on our public page "hardware" we are still met with the "Server connection lost, trying to reconnect..." error of doom. Is it likely that somewhere either Spring or Vaadin or Keycloak are calling some other things that make this page fail, or is it that this configuration is wrong?
Or maybe any tips in general on how about to go debugging this? We have been trying to get past this for over a week now with absolutely zero progress....
Regards,
Arnoud
Why you use the /** after hardware ?
It covers all the sub links of hardware and not itself
I'm trying to get SSO up and running. So when I sign in on a different application (on the same auth0 domain) and go to the login page of my application I want my application to automatically log me in.
I managed to get the first parts running and I received an authorization code from auth0. But when I try to retrieve the tokens they are all null.
my redirectuUri and clientSecret are correct and I assume the authorization code returned earlier is correct aswell.
It seems as if the request doesn't return any tokens. They are all null.
Where do I start to find out what's going wrong? Thanks!
public Tokens getTokens(final String authorizationCode, final String redirectUri) {
Validate.notNull(authorizationCode);
Validate.notNull(redirectUri);
System.out.println("Sending request with code to retrieve tokens.");
final Credentials creds = authenticationAPIClient
.token(authorizationCode, redirectUri)
.setClientSecret(clientSecret).execute();
return new Tokens(creds.getIdToken(), creds.getAccessToken(), creds.getType(), creds.getRefreshToken());
}
If using the Auth0 Spring MVC Library (not Spring Security MVC) - then best place to stick a breakpoint would at the top of the Callback Controller's handle method
You can then step through / step in - and inspect what is going on. This method calls getTokens and that delegates to Auth0ClientImpl which is the code block you reference in the question.
Check your ClientId, ClientSecret and Domain are all correct - and if your code is reaching this method - that the code / redirectURI being passed in are also correct. Would check the Auth0 logs from the Dashboard too, and determine if any successful authentication events are recorded.
Finally, please can you confirm which version of auth0-java (maven POM dependency / gradle dependency) you are using - and which version of the auth0-spring-mvc library you are referencing also.
For SSO Specific Examples - plain Spring falls between two stools as I wrote one for plain java and one for Spring Security MVC - but you should get a good idea of what is going on by studying these two samples:
Auth0 Servlet SSO Sample
Auth0 Spring Security SSO Sample
In particular, study the JSP pages since that is where the SSO checks and auto-login logic lives. Ensure too that you enable SSO on the Settings of each of your Clients defined in your Auth0 tenant.
Disclaimer: am the author of the above libraries - please leave me comments below if you still have problems and require any clarifications.
I am using spring security login mechanism for my application and tested everything.Things were working fine.I have the following use case
If customer is not logged in , application will redirect customer to the login page.
On successful login, application will redirect customer back to same page from where they were redirected to the login page
this is the Java code used to redirect user to his original location
final SavedRequest savedRequest = this.requestCache.getRequest(request, response);
targetUrl = savedRequest.getRedirectUrl();
getRedirectStrategy().sendRedirect(request, response, targetUrl);
RedirectionStrategy being used here is DefaultRedirectStrategy, things were working fine. Application is now deployed on the Pre Production server and now this seems not working and I am getting 404 error.
When customer is being redirected to the home page,targetUrl is coming out as "/", I have a Spring controller named with this mapping
#RequestMapping("/")
public class HomePageController{ // home page code }
my application's current Pre-Prod urs is prepd-www.mysite.com so when sendredirect come in to action, webpage URL is getting changed to prepd-www.mysite.com/prepd-www.mysite.com
I am not sure what is causing this issue. is it because of the proxy server settings ?
Can any one suggest me about the possible root cause of this issue?
I have already tried it on all local machines and well on our QA but everything is working perfectly fine.
Current setup for the environment where this is happening is
We have 4 app server
We have one load balancer which is redirecting traffic to one of the app server.
Just a wild guess since you could not give the reverse proxy configuration, nor the exact URL used in pre prod and in developpement.
You say you are using DefaultRedirectStrategy from Spring security. This strategy has an option (contextRelative) that prepends the ServletContext path to the URL. If in your developpement system you were using the root context, that is if you were accessing home page at (for example) : http://localhost:8080/ the serlet context was empty.
But if now in preprod, the servlet context is no longer root but is say /myApp once translated by apache reverse proxy, when you redirect you get an URL of /myApp/myApp that could be translated back to what you gave.
You could try to control whether you have contextRelative as true in DefaultRedirectStrategy and if yes if you can set if to false and also control if you redirect to absolute or relative URLs.
If you are using apache in front check rewrite rule and redirect rules of apache config. Best way would be to ssh tunnel directly to application server(by skipping apache) and test. If it's working that means your application config is fine and it needs to be fixed in apache.
Are you using in preproduction tomcat or another application server?, normally if your war is calling foo and your commit to tomcat, the path for this war is
http://localhost:8080/foo/
So if you are using servlet you need specify in your web.xml that the main path is foo/*