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.
Related
We have a legacy HttpServlet class that is the backbone of our application. At this point, the app doesn't have any Spring libraries in it. We are looking to introduce Spring, in particular so we can use Spring-Data in conjunction with Hibernate.
I was wondering if there is a way to make this legacy Servlet web-aware so we can have Request and Session scopes injected. In particular, we would like to be able to inject the HttpServletRequest object into some beans.
One of the main reasons we need to do this, is for a weird multi-tenancy solution we have in place. Hibernate can handle Multi-Tenancy using a combination of a AbstractMultiTenantConnectionProvider and a CurrentTenantIdentifierResolver When using Spring-JPA's Repositories, you lose control of the session creation. One way to take care of this is to implement the CurrentTenantIdentifierResolver Since our tenant identifier is partially determined by something that comes in on the request, it is necessary to inject the request into our CurrentTenantIdentifierResolver implementation.
Also, it would be great to get Spring involved for all the other benefits it can provide in a legacy app.
Do you know how we can accomplish this?
You can define org.springframework.web.context.ContextLoaderListener within your web.xml, which will load your spring application context.
Then, within your servlet code, you access the context using WebApplicationContextUtils.getWebApplicationContext(servletContext) helper method.
Take a look at the Spring docs here:
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#web-integration-common
At present I have a Spring MVC web application, which uses ServletFilter to filter each HTTP request and check whether the user has really purchased the licence by checking and validating the licence file content.
I have mapped the filter in both spring xml file as well as web.xml appropriately. As I have access to HttpServletRequest and HttpServletResponse in the filter, I am able to redirect the user to error page if the validation fails.
So, now as the title suggests is it possible to do the same thing using Spring AOP? How can Spring AOP be configured to get access to the request and response objects created by the container to redirect the user?
How can Spring AOP be configured to get access to the request and
response objects created by the container to redirect the user?
You won't be able to get the same exact behavior as servlet Filters. A Filter operates around the target Servlet by passing in the ServletRequest and ServletResponse objects. In that sense, you can get similar behavior since AOP advice can operate around the joinpoint and intercept arguments that get passed around.
However, the AOP advice can't magically have access to the request and response. It either needs to advise a method that receives them or get them from some ThreadLocal or other container. For example, Spring has RequestContextHolder which you can use to get the HttpServletRequest. But it doesn't have anything to give you the HttpServletResponse (not technically true, but it's not reliable). You could write something similar that does.
Once the advice has access to the objects, it can simply invoke HttpServletResponse#sendRedirect(..) or forward() or whatever.
The best way to implement this would be using exceptions. That way the check and the handling can be different in different situation, e.g. web application vs. normal application.
Your check could be added to particular joinpoints using aop. In case it finds something amiss, it would throw a InvalidLicenseException (extends RuntimeException). Now there are several ways in which you can redirect a request to an error page when an exception is thrown. You could add this to your web.xml :
<error-page><exception-type>InvalidLicenseException</exception-type><location>/license-error.jsp</location></error-page>
Since you're using spring, you could also use annotations. Read this
You can do it out with AOP Advises,
Advice: Advices are actions taken for a particular join point. In
terms of programming, they are methods that gets executed when a
certain join point with matching pointcut is reached in the
application. You can think of Advices as Struts2 interceptors or
Servlet Filters.
So you can configure an advice to take care of validation . you can also configure them to execute at a particular point (i.e) where it needs to be executed .
But remember scope of AOP remains only for method invocation and it doesn't provide response as servlet filters does.
Learn More ..
Simple example here to start with.
I want to add a couple of filters to my spring web app, but there won't be anything about security in them, at least for now. So. All I'm able to do without spring-security is to define multiple filters in web.xml (old way of defining filters). It seems strange that to be able to use spring filter chains, I need to add spring-security as a dependency for my project. Maybe I'm doing something wrong and there are indeed filter chains that can be used without spring-security dependency?
Spring Security is able to bundle multiple filters into a single Filter using the FilterChainProxy which is included within Spring Security. Since the code exists within Spring Security, you cannot use it without adding a dependency on spring-security-web short of copy pasting the code into your own project (which is acceptable by the license). The FilterChainProxy is indeed the Spring Bean defined Filter that the DelegatingFilterProxy delegates to. So it looks like this
DelegatingFilterProxy
-> delegates to FilterChainProxy
-> delegates to multiple Filter's defined on the FilterChainProxy
You can use DelegatingFilterProxy. This Spring Forum Entry has a good example of how to use it.
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.
Correct me if anything is wrong.
As I understand, all Spring functionality, namely DI works when beans are got thru
Spring Context, ie getBean() method.
Otherwise, none can work, even if my method is marked #Transactional and I will
create the owning class with a new operator, no transaction management will be provided.
I use Tomcat 6 as a servlet container.
So, my question is: how to make Servlet methods managed by Spring framework.
The issue here is that I use a framework, and its servlets extend the functionality of
basic java Servlets, so they have more methods. Still, web.xml is present in an app as usual.
The thing is that I do not control the servlets creation flow, I can only override a few methods
of each servlet, the flow is basically written down in some xml file, but I control this process
using a graphical gui.
So, basically, I only add some code to a few methods of each Servlet.
How to make those methods managed by Spring framework? The basic thing I need to do is
making these methods transactional (#Transactional).
comment to Bozho:
#Bozho Let's see. In these servlets' methods I work with framework capabilities, let's say special variables that are got and saved in the current session. And what is needed, is looping through those framework-based collections while saving some values in a database. What you suggest is introducing a new very complex object, so that it could be passed to a service layer. (Service layer will not know anything about framework, its classes and objects kept in current Session! First, we "wrap" framework based collections to such a object, so copy everything into it. Then, again, the Service layer method should either save changes in a database or, worse case, return a new complex object so that Servlet framework method could update framework variables depending on the result of Service layer method execution. It is a workaround but do you think it is a good idea?
You can also define your servlets directly in the Spring application context. You'll need a "proxy" servlet registered in web.xml and delegating to the servlet instance which is configured as bean in the applicationContext.xml. Proxy servlet is configured with the name of the target servlet bean, it discovers this bean via WebApplicationContextUtils.getRequiredWebApplicationContext().getBean(...) and delegates all the processing to the target servlet. In this case an instance of your servlet is completely managed by Spring.
I'd suggest restructuring your code - making servlet methods transactional is not a good thing to do. Put the transactional logic in a separate, service class, and either
obtain these spring-managed classes by WebApplicationContextUtils.getRequiredWebApplicationContext().getBean(..) or
in your servlet init() method obtain the ApplicationContext with the above method and call appCtx.getAutowireCapableBeanFactory().autowireBean(this). This way you can inject the transactional classes in your servlet as if it was spring-managed.
Now, you can do all this, but it is definitely not a beautiful way to go. I'd suggest using Spring MVC or any other MVC framework (which support spring integration of its components)
If this is all not possible, as a last resort I think you can use #Configurable (on your servlets) with a <context:load-time-weaver/>.
You should take a look how Spring proxy filters:
http://grepcode.com/file/repository.springsource.com/org.springframework/org.springframework.web/3.0.2/org/springframework/web/filter/DelegatingFilterProxy.java
In theory you could easily make the same sort of proxy for servlets and DispatcherServlet is sort of a proxy.