I am trying to secure my Webapplication which is based on a Spring MVC project containing REST controllers and Angular JS pages that get all their data from these controllers.
I am not at all familiar with Spring boot, just with 'classic spring'. I'd like to use the token based authentication which JHipster creates a skeleton for.
What needs to be done to get that security part and migrate it to my current Spring project? I tried copying relevant classes and the Token generation and such works, but the SecurityConfiguration seems to do nothing (no URL's are authenticated while I do say they need to be in the config, the tokenfilter never gets called etc.)
There's possibly some structural/ configurational differences between Spring and Spring boot which cause this?
What needs to be done to get the security mechanism working in a regular Spring application?
What is working:
- token generation
What is not working:
- every REST call goes through no matter if it's behind an .authenticated() URL
- the token filter never checks if there's a token and thus doesn't validate the token
Everything token-wise is okay, everything url-security wise is not at all okay.
(I've been trying to solve this for 3 days now and I just don't see where I'm going wrong.)
All help/ insights/ tips much appreciated as always.
Related
I have just returned to Spring after 5 years of gap and it seems lot is changed. I have a task to create a REST Service using Spring with hibernate as an ORM, So far I am able to run a basic Rest Service using embedded jetty and able to make GET/POST calls, the next is to integrate hibernate into it so that the data fetch/Sent operation actually use MySQL instead of sending hard-coded response(which I have done currently).
The issue is earlier I used to work on Spring MVC using Tomcat where we had web.xml to define the dispatcher servlet and application-context which in turn were used to define hibernate config and other beans declaration, but now having embedded jetty I am not finding a way to integrate hibernate to my REST app, Is the way to add configuration is changed from XML to class based config. I searched over internet but maybe I am out of words or not using correct keywords, in short, Have no luck finding some solution to integrate hibernate to my Spring app which is using embedded jetty.
Could some please breif me about the recent changes or point me to the right tutorial ?
Any help appreciated, thanks in advance !
ps - I have used this example to progress so far https://github.com/pethoalpar/SpringMvcJettyExample
Yes , lot of changes in these 5 years and one of the game-changer is spring-boot
If you want to build a brand new project especially if you want to run the web application on the embedded container such as Jetty , you can check out spring-boot.It already provides integration with Jetty , hibernate and Spring MVC REST service.
The end result is that you just need to change a little bit configuration (most probably the DB connection info) and you can quickly get a production-ready REST service backed by JPA/Hibernate which can just run without any XML configuration anymore.
There are tons of tutorials in Internet talking about how to do it . You should easily find them out such as this using the keywords something likes "springboot webservice hibernate jetty" etc.
I need configure my spring-boot web application to return different templates for same URL. Template should be returned checking roles for current user.
To solve this issue i think should be used UrlBasedViewResolver to create\configure special CustomSecurityBasedInternalResourceViewResolver. It will be really good if someone will show how to implement this idea.
I have a simple web application which I am writing using spring-boot and storm path for user authentication. (I'm actually using spring-boot-starter-stormpath-thymeleaf)
I have a have the following request mapping in my controller
#RequestMapping(value = "/secure", method = RequestMethod.GET)
public String secure(Model mode, HttpServletRequest request) {
Account account = AccountResolver.INSTANCE.getAccount(request);
if (account != null)
return "secure";
else
return "redirect:/login?next=secure";
}
which forces a user to login to view the secure page. It works, but it doesn't feel like it is the most elegant of solutions. Is there a better way? I think a solution with filters should be possible but I cannot figure it out.
The current Stormpath Spring Boot starter does not (yet) have an authentication filter, but it will on future releases for those that want an out-of-the-box experience without having to use Spring Security or Apache Shiro.
That said, we're currently working on natively supporting Spring Security and Apache Shiro as Spring Boot starters that 'just work' with the Stormpath Spring Boot starter. Until we can release those, creating a custom servlet filter as you indicate is the best approach.
Are you also using the Stormpath Servlet as well?
If so, you could do what you need following this piece of documentation. This way you will only need to declare which are the resources of your application that you want to secure and Stormpath's authc filter will prompt for authentication when required.
If you're using Spring MVC, you should use Spring Security and have Stormpath acting as an authentication provider. Then use the standard Spring Security tools to declare access rules and inject the current user where needed.
I have examples of both working individually, now trying to merge so that I have both capabilities / entry points.
Not surpised it is confused about the application contexts to load.
I want to know if this is even possible and if so any examples?
I know it is doable with spring boot however not wanting to move to that just yet.
I am attempting the impossible?
"Spring MVC (with embedded Jetty)" usually means an HTTP endpoint running in its own JVM (I suppose you have a main method that starts Jetty). Once you have that started, you can integrate it as any other HTTP endpoint in Spring Integration.
If you want them both to run in the same JVM, that probably means you don't want to make use of HTTP as you can invoke methods directly on your #Controllers or #Services.
Or perhaps I'm missing something here... ?
I'd go for Spring Boot. Version 1.1.6 was just released. I'm currently also migrating an "old" SI application to be based upon Spring Boot. I suggest you give http://start.spring.io a try. Migration should not be too difficult.
I tried using Basic Authentication by changing the server.xml config of Tomcat 6.0 but it did not worked: BASIC authentication in jersey JAX-RS service and Tomcat 6.0 getting failed
Hence I am opting a way where no server specific config is needed and I can add up the roles directly in my code (either client or server; not sure about theavailable options).
Please provide me some ideas about the possible options for setting the user roles so that I can authenticate my Web Service methods using the #RolesAllowed annotation.
You need to go back and figure out why your security constraints weren't working. Maybe start with the default file realm before moving on to JDBC realms. #RolesAllowed in an annotation that triggers behavior in the container.
If you really want to do it yourself (a bad idea) they you'd probably start by creating a custom servlet filter that implemented the entire basic http challenge mechanism. Next you'd have to replace the SecurityContext provider in Jersey.
They "thing" that enables #RolesAllowed in jersey is this: http://java.net/projects/jersey/sources/svn/content/trunk/jersey/jersey-server/src/main/java/com/sun/jersey/api/container/filter/RolesAllowedResourceFilterFactory.java Which, by the way, don't forget to add as an init-param to your jersey servlet. The RolesAllowedResourceFilterFactory gets its security info from an injected SecurityContext which I'm sure at some point just delegates off to the Servlet API for credential info.
So basically if you don't want to take the time to get security constraints working you are going to end up replacing most of the chain...like I said, a bad idea.
The features on application servers are there to keep you from having to spend time creating infrastructure code, if you write your own infrastructure code you're going to have a bad time.