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 definition. 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. Jeremy On Fri, 30 May 2008 08:04:34 -0400, "James Carman" <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > >> ...http://wiki.apache.org/incubator/JSecurityProposal... > > > > Looks good to me, IMHO this is ready for a vote. > > -Bertrand > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
