Selective authentication for a servlet?

Question

I have a servlet that returns data to users from a mapping system. Most of the data are publicly accessible, so those requests need to work without any security or login challenge.
Depending on the items requested in the URI and querystring, I may need to authorize the user to see some of the data. Determining whether the request requires security uses criteria in the querystring and a bit of other logic, so I can't use security constraints in the web.xml. I set up a servlet filter that checks to see if the request requires any secure roles. I can also figure out if the user is logged in and has those roles.
I have most of the pieces I need. What baffles me is how to make a user log in to a servlet some of the time, but not other times. I've tried 2 things and hit dead ends:
1) Send back a 401 response. The browser asks them to log in and sends their username and password back in the header. (This is an URL-based RESTlike data service, so I'm using the basic browser pop-up login.) This 401 challenge gets me their info, but doesn't seem to authenticate with the container (Tomcat). With the user/pass, I can query our user database for the authentication and authorization myself, but this seems really, really ugly. Is there a way to make the container to do the authentication on a 401?
2) Use a RequestDispatcher to forward the request to another servlet mapping that does have security set up in the web.xml. Unfortunately, this bypasses the web.xml with no login challenge. The idea is that if servlet code forwards someone to another resource, you knew what you were doing and meant to send them there. Is there a way to enforce the forwarding using the web.xml settings?
The last thing I was thinking about is if there is a way to extend the security constraint to determine whether the request requires authentication or not?
thanks, David

Answer 1

Welcome to the Sun Forums.
One way that I can think of is that instead of sending the 401 yourself (which bypasses the container), maybe you should have your filter send back a redirect (302) to the user instead. You could redirect to either a custom login page or to a protected resource. Since a redirect results in a new request being issued by the browser, the container should be able to handle the situation from there on.