Thanks for the rapid response. We are in the very early stages of looking at this, so it would be premature to claim that there is actually any "design" to speak of. I'm just asking noob questions at this point. I am not even sure we really want/need to do session tracking for the web services clients. But if it should turn out that we do, I was hoping that we could somehow wind up with three worlds:
1. The Restlet servlet; 2. Our existing security filter (or something similar to it); 3. Our Restlet code. ...and somehow not have anything in world #3 need to access either the HttpServletRequest or the HttpSession at all. The only requirement would be that, by the time we reach world #3, we are running in an authenticated context, created/recreated in world #2 (which would access stuff in HttpXxx to accomplish this), in which we can invoke secured EJBs as the appropriate user. Not sure whether this clarifies things or not. Would it help to describe what #2 is doing now, for our existing UI-oriented servlets?