On Tue, Dec 30, 2008 at 3:34 PM, Jeremy Haile <[email protected]> wrote:
> 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.
I agree. But if the architecture is sound, it shouldn't matter. I'm
currently using JSecurity in a complicated web-based product where some
shortcomings of the current architecture surface rather quickly:
We have a distributed architecture - the application is deployed in two
different tiers of physical machines. The web code runs in one set of
machines and the business tier code runs on another set of machines.
Although obviously not ideal and I hate it, it must be done this way as the
company's internal security team has an incredible distrust of web
applications - they force a firewall between the two sets of machines. We
use Spring remoting between the two tiers.
So, there is one JSecurity SecurityManager in the web tier that handles
cookies and such, but this is (aside from specific web/cookie support) a
proxy to the business-tier JSecurity security manager. The business-tier
one manages actual Session instances and their lifecycle.
Setting this up _should_ have been simple. But because of the current
architecture, I couldn't just use the DefaultWebSecurityManager on the web
tier and make it proxy to the business-tier DefaultSecurityManager. I had
to subclass DWSM, re-implement a few methods that explicitly called
super.doSomething, proxy many more methods to an injected remote proxy of
the business-tier SM and more junk. I'm not finished with this process
either, and its causing me a lot of problems.
Most of this hardship is related to Session Management. Because
SecurityManager doesn't extend the SessionManager interface (it extends
SessionFactory instead), I couldn't just easily proxy the SessionManager
methods to the back-end SecurityManager instance. I'm jumping through a lot
of unnecessary hoops because of the architecture. Needless to say, I want
to clean this up significanty.
I see the need for a Remote/Client SecurityManager implementation that can
reside in 3rd party processes (e.g. my current web environment, or maybe an
applet, or standalone application) that remote back to a 'primary' JSecurity
DefaultSecurityManager. This would be in addition to the already nice web
infrastructure. It would certainly make a federated application cluster
built on top of JSecurity much nicer. But in any case, these things surface
the need for architectural improvements that would benefit many
environments.
The Spring Remoting support needs to be cleaned up quite a bit too - instead
of relying on a session id system property, we need to acquire the subject
in another way (SecurityUtils?) and acquire the session id that way. I had
to do more subclassing there, as well as alter the server-side
InvocationExecutor. More fun...
Anyway, lots to do to support web, non-web, and hybrid solutions. But it
shouldn't affect web-only solutions in any way though - will make them a
little cleaner in fact.
1) I like the idea of using a SubjectAccessor and having the SecurityManager
> delegate to that.
Cool. I think we'll also need to create the notion of a SubjectFactory
again. It'd be nice for people to inject one of those into the
SecurityManager instance instead of having to subclass the SecurityManager.
Based on my experiences above, I'm quickly becoming an advocate that people
should not have to subclass the SecurityManager in any environment unless
something _really_ weird is being done. A SubjectFactory in addition to a
SubjectAccesor I think would round out the things necessary to realize this
architectural philosophy.
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)
The default would probably be thread based (DefaultSecurityManager), but the
DefaultWebSecurityManager would have as its default a web based one, sure.
In any case, anyone could override either just by injecting their own
implementation. Pretty clean.
For example (default implementations):
DefaultSecurityManager() {
setSubjectAccessor( new ThreadContextSubjectAccessor() );
}
DefaultWebSecurityManager() {
setSubjectAccessor( new HttpContainerSubjectAccessor() );
}
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?
This is because the data required to construct a Subject differ across
environments. In one environment (a non web based one), it could be just a
session id. In a web-based environment that initData object could be (new
HttpServletPair(request, response)).
The implementation could determine what that 'initData' object could be. In
the web support, the JSecurityFilter would be changed to construct an
instance of HttpServletPair and inject that. A Portlet-specific
implementation could receive a PortletPair.
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.
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.
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() )
Absolutely, that wouldn't go away.
These changes wouldn't affect the web functionality in any way - it just
makes other environments much easier to use as well.
