OK - I'll try to keep my feedback brief here. I believe that most
users of JSecurity are and will always be web application developers.
So although I want to make it easy to use JSecurity in a non-web
environment, I don't want to sacrifice the ease-of-use in web
environments to do so.
1) I like the idea of using a SubjectAccessor and having the
SecurityManager delegate to that.
2) I think you still run into the problem of where to get the
appropriate accessor from, how to configure it, etc. I presume the
default would be web based? Or we could do an SLF4J approach and make
the default depend on what modules are included in the classpath.
(i.e. if you include the "web" module that one is used, if you include
the "nonweb?" one that's used)
3) I'm not sure I understand why initData is used. In our current web
implementation we use ThreadLocal variables to store the subject -
wouldn't we just continue doing that? Shouldn't the accessor
internally contain any init data it needs?
4) I assume we'd still have some sort of static methods available for
web contexts that would allow easy access to the subject via a
threadlocal? (e.g. SecurityUtils.getSubject() )
On Dec 23, 2008, at 1:13 PM, Les Hazlewood wrote:
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
