RE: [Springframework-developer] Road map (security)

[Ben A. <ben...@ac...>]

I agree there is value in allowing the Acegi security project to develop and
see where it leads for now. One question: should I establish a separate SF
mailing list or is there any objection in using springframework-developer
and spring-user for now? I doubt there will be much traffic and it will be
easier to solicit feedback from those not actively using it.

At this time I'm really focusing on Spring. Thus the project name has "for
Spring" at the end. It wouldn't be too hard to get the Acegi security
project supporting non-Spring containers, but doing so at this early stage
would dilute the focus of the project. I'm not even sure what the status is
of other IoC containers and security - do they already have it? If so, we
wouldn't bother. If not, security could be a differentiation factor for
Spring. I'd welcome other views on this.

> Actually, at the moment we're not doing everything that's out 
> there. One of those things is declarative security. I really 
> think it should be addressed in some way. Some people just 
> don't see Spring as suitable for enterprise apps, because of 
> lack of security infrastructure (this is the main reason for 
> some applications we're still using EJBs, arggghhhh, I hate it!).

The only argument I can think of against Spring's security support today is
the low installed base of the Acegi security project. Conversely, the code
is simple, with reasonable test coverage and easily reviewed. The Acegi
security project certainly provides plenty of features and plug-in points. A
major benefit is that it complements the existing container security
capabilities via the included "container adapters". This has a number of
benefits:

* Appeals to users who want to build on their understanding of J2EE
declarative security
* Your container obtains the authentication credentials from the user (form,
basic auth etc)
* Normal declarative security can be used to secure EJB, Servlets, JSPs,
static content etc
* The Acegi security approach complements future security enhancement of
J2EE specs
* It immediately works out-of-the-box, which is always encouraging to new
users
* You can still use the "alternative approach" (discussed below)

The "alternative approach" is to ignore container adapters. That is, you
populate your Authentication object in a Session (probably via a form), and
write your own handler for securing static content etc (like a
HttpRequestPathAuthorizationFilter). The price of this is ignoring container
capabilities and the J2EE specs. Still, you can easily do that using the
Acegi approach. Or you can do it the recommended way via container adapters.

Cheers

Ben