I was playing around with potential solutions this weekend for assumed identity support as well as thinking about how to acquire a Subject without requiring a log in by the software developer and this issue:
https://issues.apache.org/jira/browse/JSEC-17 is very much related to this thread. It goes back to being able to acquire a Subject instance based on some initial set of data. In SSO applications, that 'initial set of data' might be just an SSO Token (e.g. session id). In a daemon process, it could be a PrincipalCollection instance. Or maybe its just a single principal. I think we'll need to the ability to do this - not just get the 'current' subject. Might this be related to assuming an identity? At first glance, I think it is an orthoganal issue. I'm not sure that this: securityManager.getSubject( initData ); is (or should be) semantically equivalent to this: Subject subject = securityManager.getSubject(); subject.assumeIdentity( initData ); Thoughts? On Wed, Dec 31, 2008 at 2:09 PM, Jeremy Haile <[email protected]> wrote: > 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... >> > >
