Wow - Les, you sure know how to write long-winded responses =)
On Dec 31, 2008, at 10:15 AM, Les Hazlewood wrote:
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:
I agree. My point is that the backend architecture can be complex (if
necessary), but the user experience shouldn't suffer. And we should
focus foremost on the startup cost and user experience of simple web
apps, since that's our biggest audience. If through good architecture
we can make it simple to use, yet robust and powerful for edge-case
scenarios - that's the ideal.
As with any system, we should still strive for simplicity - even in
the backend, since it leads to more understandable, maintainable, and
SECURE code.
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.
Yeah - I definitely think solving this problem in the general case is
something that needs some more discussion, and perhaps some UML
diagrams before implementing. I think it's valid to ask whether this
should be very transparent, or whether it should be more explicit in
the code/architecture.
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...
Yeah, the Spring Remoting support is pretty basic now. It'd be good
to think it through along with other web service remoting support.
Cool. I think we'll also need to create the notion of a
SubjectFactory
again.<snip/>
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.
I like the idea of using factory pattern, accessor pattern, etc. as
long as this is hidden from the user in the common use cases.
DefaultWebSecurityManager() {
setSubjectAccessor( new HttpContainerSubjectAccessor() );
}
Small note - but again - currently we use ThreadLocals to store it in
a web environment. I see this as a separate change that should be
discussed separately (and I'll discuss more in response to your
comments below)
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'm not sure that either of those are desirable, but I'm open to
discussing it further.
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.
