incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Haile" <>
Subject Re: [PROPOSAL] Incubate JSecurity Project
Date Fri, 30 May 2008 12:31:36 GMT
The fact that JSecurity is container-agnostic is certainly a
differentiator.  JSecurity aims to support security in any environment. 
In fact, we have several users that are using JSecurity in non-web
environments, such as pure-service layers or even Swing applications.  

JSecurity also aims to greatly reduce the amount of configuration
required to setup security in an application.  In many cases, JSecurity
can be configured in web-based environments via a single filter

Another differentiator is that JSecurity provides a session framework
that is not limited to being shared across just web-based applications. 
We have users that share sessions across multiple environments, such as
Swing apps talking to a server over Spring remoting or RMI, applets, and
web applications - so they can all share common session information in a
heterogeneous environment.

JSecurity also provides powerful dynamic, instance-level authorization
control.  Essentially JSecurity supports powerful instance-level control
using String-based permissions (or Object-based, depending on
preference/environment).  For example, I could simply grant a user a
"sendNewsletter" permission.  But if I wanted instance level control, I
might grant them the permission "newsletter:send:123" where 123 is the
ID of the newsletter that they are allowed to send.  I could even grant
a user permission to "newsletter:send:*" or "newsletter:send:123,124" 
Then when I check to see if the user has the permission for
"newsletter:send:124" JSecurity would grant the authorization.  

This simplicity and power is unmatched in any existing security
framework out-of-the-box.

Finally, JSecurity strives for simplicity in all areas.  To this end, it
explicitly supports common security mechanisms used in most applications
such as roles and permissions.  This makes code more readable, limits
the amount of custom coding required, and makes security definitions
very concise and readable.  Despite our goals of simplicity we also aim
for flexibility - so out of the box the framework should be extremely
easy to get up and running, requiring minimal configuration and custom
code.  But for users who have much more advanced needs, JSecurity
provides the pluggability and extensibility to be used for almost any
security application.

Please don't hesitate to ask further questions.


On Fri, 30 May 2008 08:04:34 -0400, "James Carman"
<> said:
> Isn't there something that states that an incubating project needs to
> be novel or provide something that's not already provided by another
> library (with an open-source license)?  I have looked at the JSecurity
> proposal only briefly, but it seems to me that most of what it aims to
> provide is already provided by Spring Security (a.k.a. Acegi).
> Although, Spring Security is somewhat bound to the Spring framework
> (they implement InitializingBean and stuff), so that might be what
> JSecurity is trying to provide, a container-agnostic security
> framework.
> On Fri, May 30, 2008 at 2:32 AM, Bertrand Delacretaz
> <> wrote:
> > Hi,
> >
> > On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <> wrote:
> >> ...
> >
> > Looks good to me, IMHO this is ready for a vote.
> > -Bertrand
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message