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

[Alef A. <al...@jt...>]

First of all I must say I forget about you Ben and I really have to take a
look at your code soon! I just downloaded it...

Our proposition is: easier J2EE.

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!).

Colin, you're right about varying requirements. The question is: are
role-based security and method-level restrictions enough. Well, I have been
able to build decent apps with that, so I would say: yes. Unfortunately
there are no decent common grounds on which all servlet containers base
their security (like JTA), so that I guess, is the real problem.

Alef

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Colin Sampaleanu
> Sent: Thursday, March 11, 2004 10:36 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Road map (security)
> 
> Ben Alex wrote:
> 
> >>How about declarative security, should somehow also be
> >>mentioned in the roadmap. Any ideas so far about how to go about it?
> >>
> >>
> >
> >Thought I'd jump in here. The Acegi Security System for Spring project
> now
> >has a home at SoureForge. I'm currently writing automated container
> >integration unit tests (ie unzip a stock standard container release,
> install
> >the security module to it, and run unit tests). CVS and a new ZIP release
> >will be at SourceForge in a day or two, and anyone interested is welcome
> to
> >participate in development.
> >
> >Whilst I initially wrote the above project with a view to inclusion in
> >Spring, I also recognise there are no Spring-specific dependencies apart
> >from standard bean context and interceptor services. As such, from a
> >technical perspective security could be effectively developed in a
> separate
> >project, or as a separate module under Spring CVS. There is no technical
> >requirement in having it in Spring core. The real issue is whether from a
> >marketing perspective the Spring Framework needs its very own security
> >capability/project, an "official" separate security project that users
> are
> >pointed towards, or a list of external (untested) security projects that
> >claim to support Spring.
> >
> >It would be nice to avoid duplication of efforts on security,
> particularly
> >given most of it involves writing adapters between the project security
> and
> >the container's native security. Maximising the user and developer base
> of a
> >single security project will also have obvious benefits in terms of
> testing,
> >issue identification, support and improvement.
> >
> >Ben
> >
> >
> Ben,
> 
> Your stuff looks great. I'm probably going to try using it in our main
> app in the relatively near-term (a month or so). I _really_ appreciate
> the work you've put into it.
> 
> At the same time, due to the fact the people's security needs are so
> varied, it might be a bit preliminary to bake it into Spring itself
> without letting people use it for a while, hopefully with the idea that
> any relevant comments or issues would be raised in the process. Once
> something is part of Spring itself it's going to be much harder to make
> backwards incompatible changes, whereas with an external add-on, there
> could simply be two versions. Just IMHO...
> 
> Regards,
> Colin
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer