Question

I currently have a number of web applications which access a common service running in JBoss 5.0. The service is very simple, using Guice and POJOs. The web applications are authenticated and know who the user is and what roles they have. When calling the service how should I pass this authentication information to the service?

It would seem the simple approach is to simply add a parameter to the interface to take the user information. Possibly a Subject. But this has the downside of cluttering up the interface with contextual information that isn’t specific to the job in hand.

void doSomething(Subject subject, ...) {
}

The alternative I have seen is to use ThreadLocal storage, put the user information in there before making the call and make this accessible via some utility class that the service can use. This cleans up the interface but hides the fact that the client of the service has to set the user information before making the call.

Is there another way of doing this? I get the feeling the AOP may be of use here too but can’t quite see how. Is there some “best practice” I am missing? Would EJB help?

Answer 1

This cleans up the interface but hides the fact that the client of the
service has to set the user information before making the call.

True, but if you need to pass something to a particular method across the application then you are defeating the purpose of using Dependency Injection. It’s there so that you don’t have to pass a bunch of services and objects to other services and objects and so forth, they are created with everything they need.

Is there another way of doing this? I get the feeling the AOP may be
of use here too but can’t quite see how. Is there some “best practice”
I am missing? Would EJB help?

The other way of doing this would be to use a single filter on every Servlet that calls the services that need the Subject / User. Set the user in the filter, and clear the user at the end in a try-finally block. In fact, OWASP Esapi uses this style when setting their ThreadLocalUser, it allows the User to be available in every part of the application.

Something like this:

@Singleton
public MyUserFilter extends FilterOfTheMonth {

    private final Provider<Authenticator> authProvider;

    @Inject
    MyUserFilter(Provider<Authenticator> auth) {
        this.authProvider = auth;
    }

    public void doFilter(ServletRequest request, ServletResponse response, 
            FilterChain chain) throws java.io.IOException, ServletException {
        try {
            // Authenticate and SET the current user utilizing the request and/or                       
            // session objects
            authProvider.get().authenticateUser(HttpRequest currentRequest);

            // Continue on here along the servlet chain
            ... other processing
        } finally {
            authProvider.get().getRidOfCurrentUser();
        }
    }
}