What's the preferred way to handle Spring Security for JMS Listeners?

Question

I have a somewhat monolithic Java application, built around Spring @Service beans for my business service layer. As a rule, each of my business service methods has Spring Security annotations (e.g. @PreAuthorize) to enforce appropriate authorization rules for that action.

Within the main web application flow, this works very well; each web request implicitly has authentication handled by session cookies, etc.

However, when it comes to various integration points with other, "internal" systems, I'm not seeing as clear of a solution.

For example, I am going to be consuming methods from a JMS queue, which already has its own authentication & authorization rules defined within the broker, so I want to implicitly "trust" the messages that I get. However, as things stand now, a simple enough Camel route like this:

WidgetService widgetService = lookup(WidgetService.class);
from("activemq:newWidget")
    .unmarshall(...)
    .bean(widgetService, "newWidget");

ends up throwing a AuthenticationCredentialsNotFoundException.

This tells me that Camel is calling my bean correctly, with all of the magic AOP applied from Spring.

With other things of this sort, I've resorted to applying AOP advice around the entry point for the system (e.g. around a Quartz Job's execute method), which injects a PreAuthenticatedAuthenticationToken, but I'm not sure if that's really the best approach.

Should I continue to wrap these "trusted" entry points in advice to add an Authenication context, or should I change my service layer to have special forms of some business methods which require no authentication, and just make sure I document clearly that they are not for use in web @Controller methods, etc?

Answer 1

Unfortunately there is best way to do that. It depends on the application and in my experience all solutions work but have some drawbacks.

The first solution would be to move the @PreAuthorize up to the web level. This way you will be free to use your services internally as much as you want. I think this is the simpler solution and easier to comprehend. You want to secure your web users right? Why not apply the security to in the web layer. The problem with it is that web layer changes more often than the business layer and it is easier to leave security breach if you don't develop your controllers and endpoints carefully. I would still take that approach for most applications and let the service layer take care just of business rules and not security (which is kind of business rule too? ). Of course you can still add some default security logic to groups of controllers and stuff so you don't have to repeat yourself everywhere.

The second approach is the one that you have taken. Run such methods in authenticated context which you generate. And it is a bit counter-logic - why to run in authenticated context when there is no authenticated user? You shouldn't have to do it but unfortunately that's the only way if you want to have secured services. This methods is less prone to security errors and you can maintain the security easier. If you stick to that you can use the template pattern or create some executor class that runs stuff in context.

I cannot think of a third approach :)