Every request has to be authenticated as the identity of the caller is a property of the request. The ThreadLocal is simply used to propagate the identity through the scope of the request and must be set on each request. The identity to credentials mapping are cached at the security manager layer to avoid having to perform full authentication. If the servlet container is also caching the caller identity because of a stateful session, it still should be calling out to the realm layer for authentication as the cached credentials may be expired ahead of the session. It also simplies the propagation of the caller identity outside of the servlet container when other secured J2EE components are invoked by the web component.
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Anatoly Akkerman" <[EMAIL PROTECTED]> To: "Julian Gosnell" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, December 28, 2001 6:03 AM Subject: Re: [jetty-discuss] Re: [JBoss-dev] Jetty security problem > > I am not sure myself where is the second thread coming from. I'll try to > figure that one out. But in priniciple, Greg is right, using ThreadLocal > for security association is improper in this environment. Again, as Greg > pointed out, we would have to authenticate every request. Here is a > snippet from my log: > ... > As you can see, SocketListener 3 did authentication, while SocketListener1 > is doing role checking. Does it make sense to store the user credentials > is the JBossUserPrincipal and in isUserInRole() do authentication > again? This will set the thread association with proper security > context. I don't know, though, how to unset this once the thread is done > processing the request. > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
