I have a scenario where I have roles and permissions in a different system (where i need to make a REST call) and that system will specify whether I can access a particular resource or not.
I need to intercept my controller methods and that Interceptor should talk to external service and figure out the authorization. I am using just spring boot (no spring security).
It should be similar to this with JAX-RS but I'm looking in spring context. Can I achieve this using #RolesAllowed?
I would recommend using an interceptor:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html#mvc-handlermapping
You need to have a configuration that you will annotate with (check spring documentation)
#EnableGlobalMethodSecurity(jsr250Enabled = true)
Then you will have to create your own access decision manager and register your own roles. With this you should be able to annotate your controllers to a specific user like #RolesAllowed("admin")
Related
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.
Normally, we use the annotation #SessionAttributes("myAttribute") over the #Controller class, to enable sessions. But if we're using Spring Data REST, i.e. exposing our repository directly using #RepositoryRestResource, then we don't have to make a separate class for the controller.
Then, in this case where do I use the annotation #SessionAttributes("myAttribute") or how do I use sessions? Could someone explain with an example?
This is continuing after this question: Custom LDAP authentication using Spring Security 4. After the user has been authenticated, I need to authorize it. My roles has and the user mapping is stored in a database. I need to fetch the roles and save them in the GrantedAuthority object. How do I do this using Spring Security 4? I am using Java based config.
You need to implement your own AuthenticationProvider (i.e. a class implementing org.springframework.security.authentication.AuthenticationProvider) and configure Spring Security to use it. Give a look to this: Implement custom AuthenticationProvider in Spring Security 2.06
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.
I need to interface an existing application with Acegi/Spring security.
In order to get started I am looking for one simple piece of information: in this context, will HttpServletRequest.getUserPrincipal() called from my application properly return the username obtained through Spring (as opposed to using Spring-specific objects)? I have Googled conflicting information on this.
I assume that if Acegi is implemented with filters, it is able to overload the Servlet API's getUserPrincipal(), right?
Subsidiary question: if this is not the case by default, is there any way to turn it on?
Thanks,
-Erik
As previous user has answer, spring security support the getUserPrincipal and isUserInRole. Here is how spring security does it.
When you configure spring, it can load the following filters:
http://static.springframework.org/spring-security/site/reference/html/ns-config.html#filter-stack
As part of the standard filter configuration the SecurityContextHolderAwareRequestFilter filter is loaded.
Examining the filter # https://fisheye.springsource.org/browse/spring-security/tags/spring-security-parent-2.0.4/core/src/main/java/org/springframework/security/wrapper/SecurityContextHolderAwareRequestFilter.java?r=2514
You can see it wraps and changes the HttpServletRequest object to the SecurityContextHolderAwareRequestWrapper class which extends HttpServletRequestWrapper which implements HttpServletRequest and feed it back to the standard Servlet Filter doFilter chain. Since spring security filter should be configured as the first filter, all subsequent classes will see the SecurityContextHolderAwareRequestWrapper instead. This includes JSP pages or Servlets behind this filter.
When you make a call to isUserInRole or getUserPrincipal from the JSP page, Servlet or any framework behind this filter, it is calling the HttpServletRequest implementation from Spring Security.
If you use the security filter, yes it does. I believe this is the default behavior.
Exactly which class you're getting back depends on your configuration, but they all implement the Principal interface by way of Spring's own org.springframework.security.Authentication interface which extends it.
I've used request.getUserPrincipal() and request.isUserInRole() in a Spring application and it works seamlessly, even within JSPs.
I do believe that Spring Security stores this information in the SecurityContext and not in the request though. You could easily write a FilterSecurityInterceptor that can be configured to add this info to the request also.