Yeah - in my mind the web-specific portion of the subject binding is
actually the filter (who binds it to the thread local). But there are
lots of cases where the thread local stuff is useful (offline clients,
daemon threads, and yes, web clients) But I'm open to better ideas
for doing this that make it more cross platform. No matter which
solution we do, it will be easy for the end user to access, so it's
really a behind-the-scenes question for the most part.
On Dec 31, 2008, at 12:49 PM, Les Hazlewood wrote:
On Wed, Dec 31, 2008 at 10:40 AM, Jeremy Haile <[email protected]>
wrote:
This may even eliminate the need entirely for a Thread-bound
ServletRequest
and ServletResponse. They were originally bound to the thread
specifically
to aid in Subject construction. But I'd have to see whether or
not a
thread-bound request/response is used in other ways before we can
definitively say binding is not necessary anymore.
Not totally accurate in my opinion - the ThreadLocal is used so
that we can
access the subject anywhere without having to get access to JSecurity
objects, such as the SecurityManager. This to me implies one of
two things
a) you're proposing we store the Subject in the session or b) the
security
manager is pulling stuff out of the session and constructing a
subject every
time you ask for it.
I didnt' say anything about how the Subject is stored/accessed :).
I was
talking about a "Thread-bound ServletRequest
and ServletResponse". But, after thinking about this, and based on
your
reply, then maybe we need to still do that in a web environment so the
WebAccessor has something to pull from.
Consider this alternate implementation of JSecurityFilter's
doFilterInternal
method. Hopefully it will illustrate my thoughts:
HttpServletRequest request = (HttpServletRequest) servletRequest;
HttpServletResponse response = (HttpServletResponse) servletResponse;
//here is where we bound the InetAddress - maybe not necessary anymore
//construct JSecurityHttpServletRequest/JSecurityHttpServletResponse
same as
in
//existing implementation
//here is where we called WebUtils.bind(request)/.bind(response) -
maybe not
necessary anymore.
Subject subject = getSecurityManager().getSubject( new
HttpPair(request,
response) );
ThreadContext.bind(subject);
ThreadContext.bind(getSecurityManager());
FilterChain chain = getConfiguration().getChain(request, response,
origChain);
//rest of the implementation stays the same...
Again, I don't know if this is the way it should work, its just an
idea.
Maybe
getSubject( new HttpPair(request, response) );
is never called. Maybe the request and the response ARE bound to the
thread, and the WebAccessor implementation knows to pull them off of
the
thread when building the subject upon the very first request to
securityManager.getSubject().
Maybe that's the cleanest way to go - I dunno yet ;)
Automatically assuming a Thread-based model causes problems that
could be
easily mitigated by this approach (for example, in a daemon
environment,
when the thread executing isn't the same as a user request). Lots
of
flexibility there.
Well - there are ways to support a thread-based model, even for
daemon
threads. And I think daemon threads are even harder to support by
assuming
a request/response based model.
I'm not assuming any model - that's up to the Accessor
implementation. One
implementation could use the ThreadContext. Another can use Http
request/response pairs. Another can pull it from a file if it is a
desktop
app. Sure the daemon-compatible implementation can use the
ThreadContext -
I'm just saying that the SecurityManager doesn't need to know that -
it is
up to the Accessor implementation.
But, let's say we leave the Accessor out of it. We'll probably need
securityManager.getSubject( initData) just to suport runAs/
assumedIdentity,
where 'initData' is the identiy being assumed...
