I'm currently working with Spring 3.0.4 and Spring Security 3.0.2 (latest stable release at the moment). I'm kind of struggling migrating from Spring 2.5 to this new version, but that's a different subject.
The real question is coming, inside the <http> tag you can put the <intercept-url>, but it seems like it can also be used inside Security Filters (as seen here : Core web filters).
Can someone tell me the difference between these two? Why using it inside the http tag instead of inside in a security filter?
Thanks
Using <http> tag is a convenient way to configure security filters. When you use it, you typically don't need to configure individual filters.
However, in the complex cases you may configure filters manually as shown in the docs you referenced.
So, they do basically the same thing, but <http> tag is simplier and therefore it's a preferred way to configure Spring Security.
Related
TL;DR
Is there a way to mix Spring Web Security configuration with both annotations and xml?
Full Story
For our legacy spring web application we are looking into using annotation driven configuration for part of our web security.
Currently all our web security (<security:http>) is driven by xml based configuration. But we are adding a new login mechanism (SAML 2.0) that seems like it would be much easier to configure via annotations than xml.
We have been attempting to mix the use of annotations and xml, but it seems as though only one or the other works. Meaning that when any xml based web security is referenced, either via an xml (<import resource="classpath:web-security.xml"/> or via the #ImportResource annotation, the annotation based web security is ignored.
If we remove references to the xml based configuration our annotation configuration gets called.
Any friendly suggestions or advice is appreciated.
Mixing the Spring Web Security XML and annotation configurations would mean that that the same bean instance, viz., security:http is being configured via XML as well as JavaConfig. It would be configured with some intercept URL patterns using XML and some other Ant matchers using JavaConfig. But please note that intercept URL patterns are always evaluated in the order they are defined and also the matchers are considered in order. So, Spring Security only considers the XML configurations and ignores the JavaConfig ones as, if it considers both, it won't have any sense of order of URL definitions. I couldn't find any documentation that directly supports this theory. If you share the Spring Boot log statements that are produced when the application boots up, we may get a better view of what Spring Boot is doing.
So, I don't think that you can mix Spring Annotations with XML Configuration when configuring Spring Web Security and will advise to migrate legacy XML configurations to JavaConfig.
In a bunch of the tutorials and code samples of Spring Boot and Jersey that I've seen, the following line appears:
register(RequestContextFilter.class)
What is this really used for? I don't see anything unusual in those samples, and if I remove it from my (simple) application, nothing seems to break.
RequestContextFilter's javadoc says
This filter is mainly for use with third-party servlets, e.g. the JSF
FacesServlet. Within Spring's own web support, DispatcherServlet's
processing is perfectly sufficient.
I haven't seen third party servlets in those examples.
In one of them I read
org.glassfish.jersey.server.spring.scope.RequestContextFilter, which
is a Spring filter that provides a bridge between JAX-RS and Spring
request attributes
What would be an example of a Spring request attribute?
What is some typical use case, besides needing a third party servlet?
I am developing a Web application which uses JBoss RESTEasy (resteasy-jaxrs-3.0.8) but I want to disable the RoleBasedSecurityFilter.java and only use my own custom SecurityInterceptor class (which also implements javax.ws.rs.container.ContainerRequestFilter just as the RoleBasedSecurityFilter class does, so they are both security filters).
The reason for this is that line 43 in RoleBasedSecurityFilter.java calls a isUserInRole() method, which always returns false in my application. And as result a ForbiddenException gets thrown, which prevents the user from accessing resources he should have access to.
I really like being able to use the #RolesAllowed annotation to declare which roles have access to certain functionalities, but as explained, the RoleBasedSecurityFilter class is blocking this. So my question is, does anyone know how to disable one specific RESTEasy filter (i.e. RoleBasedSecurityFilter)?
I'd imagine that it might be done in the deployment descriptor (web.xml) (for example with a context-param element), but I have no clue how to actually disable the filter.
I realize I could also change the line in the RoleBasedSecurityFilter.java file in the RESTEasy library I am using, but that approach is too hacky for me as I don't want to be stuck having to apply this hack again everytime I would upgrade my RESTEasy version. (not sure how often that would be though..)
You can enable / disable the role based security by adding this configuration in the web.inf deployment descriptor.
<context-param>
<param-name>resteasy.role.based.security</param-name>
<param-value>true</param-value>
</context-param>
Hope this helps.
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'd like to configure one or more ServletContextListener's programmatically, that is, without configuring them via web.xml. I'm currently doing something similar by adding servlets and filters programmatically.
Is this possible? If so, could someone provide an example?
With Tomcat 7 you have two options to avoid web.xml. The first is to use the #WebListener annotation but I suspect that isn't quite what you want. The second it so use a ServletContainerInitializer (SCI). For an exmaple, see how Tomcat's WebSocket SCI does it. That SCI does a lot of things. The relevant line for you is servletContext.addListener(new WsContextListener());
Note that an SCI uses the services API to register itself.