This is a long email, but very core to JSecurity's functionality - please do read it in its entirety. It has wide-reaching implications ;)
A question asked by Tamas on the user list surfaced the question of how to access a Subject outside of a web environment. Of course there is SecurityManager.getSubject(), which should work fine. But digging into the code, one realizes to support this method outside of a web environment, the end-user would have to subclass the SecurityManager implementation and override the bind(...) implementation to place the subject identity data somewhere it could be retrieved later to reconstitute the Subject instance. This is certainly less than ideal (subclassing core JSecurity components - blech). I've actually thought about this a bit myself a long time ago when coding the web environment support in the form of the DefaultWebSecurityManager - I never really liked how Subject binding/acquisition was very specific to either SecurityManager implementaiton - I wanted it to be cleaner in some way. So in that light, I propose that we add two new things: 1. A SubjectAccessor (or anything that might be better named) interface, with two methods: bind(Subject subject) : void acquire( Object initData ) : Subject An instance of this interface can be injected into the DefaultSecurityManager implementation with, of course, a sensible default being provided automatically. The DefaultWebSecurityManager would initialize a different default for binding and acquiring the Subject based on the HttpServletRequest. This would also make it easy to support PortletRequest and Restlet environments - just use a different SubjectAccessor implementation. This is reminiscent of the SecurityContextBinder that was in JSecurity in the older < 0.2 days. Seems like now we have a good reason to bring back that concept. 2. A SecurityManager.getSubject( Object initData ) : Subject method The current SecurityManager.getSubject() implementation expects that the 'initData' can be acquired in some known way from the currently executing thread or perhaps static memory - not ideal. The new approach would delegate to the SubjectAccessor instance. This additional method would also clean up some of our web and ThreadContext related code. We could do things like this in the JSecurityFilter or other similar implementations for Portlet and Restlet support: securityManager.getSubject( httpServletRequest ); //underlying SubjectAccessor impl would be an HttpSubjectAccessor securityManager.getSubject( portletRequest ); //underlying SubjectAccessor impl would be a PortletSubjectAccessor securityManager.getSubject( restletRequest ); //etc, etc. Ultimately these changes would enabled JSecurity deployments in any custom manner based on an injected SubjectAccessor. StaticMemorySubjectAccessor, FileSubjectAccessor, CacheSubjectAccessor, etc, etc. What do you guys think? - Les
