jsecurity VS acegi

[Jon.S]

Dear All,

I've been planning to use either one of these 2 security options.   But I haven't decide it yet because these each one has 1 feature I like.  I plan to use it in intranet site where user can create and define its own security policy at runtime.  

Frankly speaking I lean more towards ACEGI on this one because user and security are created at runtime(You don't need SecurityFilter...), but I really like Jsecurity plugin taglib where you can specify fine grained view down to each field.

I've planning to write separate domain model to complement either these security.  There'll be simple management screen where it list all domain and its fields with checkbox for R or W and store it to database.  Also some taglib more or less similar to jsecurity.  

However, I rather not implementing it if there is existing capabilities already :)

Appreciate other input or correction from more experience developer on this.   Thanks in advance.


Best Regards,

Joni Sudjito

[Peter Ledbrook-2]

> Frankly speaking I lean more towards ACEGI on this one because user and
> security are created at runtime(You don't need SecurityFilter...), but I
> really like Jsecurity plugin taglib where you can specify fine grained view
> down to each field.

I'm confused about what you mean by "user and security are created at
runtime". Could you explain, please? Also, I'm not sure there's a big
difference between the tag libs of the two plugins, but I haven't
looked at the Acegi one for a while.

Cheers,

Peter

--
Software Engineer
G2One, Inc.
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon.S]

Hi Peter,

In sample tutorial http://docs.codehaus.org/display/GRAILS/AcegiSecurity+Plugin+-+Basic+Tutorial
you end up with user/role management where you can create new user, role and define url you can(n't) access.

From what I gather in jsecurity tutorial I need to define security filter to specify each user priveleges.

It will be quite troublesome for me to add new user(or role) in jsecurity because I need to recode the security filter.  I rather let my user doing this themselves.

I think I plan to make my own taglib to do something similar to jsecurity's taglib(hasRole).


Best Regards,

Joni

[kouphax]

Joni,
 
In JSecurity you can define all your filters on a role basis.  If you have planned ahead there would be no need to re-code for each new user, jsut assign them to a certain role.  That said having played with both I personally currently favour Acegi as I like the requestMapping style of securing things.
 
James Hughes | Senior Software Engineer | Kainos | M: [phone] | j.hughes@...
 
P Please consider the environment and do not print this mail unless necessary

________________________________

From: Jon.S [mailto:bulkmailme@...]
Sent: Fri 16/05/2008 13:47
To: user@...
Subject: Re: [grails-user] jsecurity VS acegi




Hi Peter,

In sample tutorial
http://docs.codehaus.org/display/GRAILS/AcegiSecurity+Plugin+-+Basic+Tutorial
you end up with user/role management where you can create new user, role and
define url you can(n't) access.

From what I gather in jsecurity tutorial I need to define security filter to
specify each user priveleges.

It will be quite troublesome for me to add new user(or role) in jsecurity
because I need to recode the security filter.  I rather let my user doing
this themselves.

I think I plan to make my own taglib to do something similar to jsecurity's
taglib(hasRole).


Best Regards,

Joni
--
View this message in context: http://www.nabble.com/jsecurity-VS-acegi-tp17272804p17273892.html
Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email






--------------------------------------------------------------------
This e-mail is intended solely for the addressee and is strictly confidential; if you are not the addressee please destroy the message and all copies. Any opinion or information contained in this email or its attachments that does not relate to the business of Kainos
is personal to the sender and is not given by or endorsed by Kainos. Kainos is the trading name of Kainos Software Limited, registered in Northern Ireland under company number: NI19370, having its registered offices at: Kainos House, 4-6 Upper Crescent, Belfast, BT7 1NT,
Northern Ireland. Registered in the UK for VAT under number: 454598802 and registered in Ireland for VAT under number: 9950340E. This email has been scanned for all known viruses by MessageLabs but is not guaranteed to be virus free; further terms and conditions may be
found on our website - www.kainos.com



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Haotian Sun]

Jon.S wrote:

> Dear All,
>
> I've been planning to use either one of these 2 security options.   But I
> haven't decide it yet because these each one has 1 feature I like.  I plan
> to use it in intranet site where user can create and define its own security
> policy at runtime.  
>
> Frankly speaking I lean more towards ACEGI on this one because user and
> security are created at runtime(You don't need SecurityFilter...), but I
> really like Jsecurity plugin taglib where you can specify fine grained view
> down to each field.
>  

What other specific tags do you need? Shout and we can add on if your
requirement makes sense!




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon.S]

James,

I plan to make the role dynamic as well.  It is easier for me.

Best Regards,

Joni

Joni,
 
In JSecurity you can define all your filters on a role basis.  If you have planned ahead there would be no need to re-code for each new user, jsut assign them to a certain role.  That said having played with both I personally currently favour Acegi as I like the requestMapping style of securing things.
 
James Hughes | Senior Software Engineer | Kainos | M: [phone] | [e-mail]
 
P Please consider the environment and do not print this mail unless necessary

[lhazlewood]

I'm not sure where the disconnect is.  JSecurity as a framework has at
its very core the notion of a dynamic security model - roles, users,
even individual instances, all able to be changed at runtime with no
hard-coding of any role names, etc.  In fact, the framework was
founded due to this very requirement.

It is up to you however (or maybe a plugin) to do the actual
user/role/permission modifications and assignments.  Your JSecurity
Realm just needs to know how to access those model objects when
executing a role/permission check.  Are you asking that the JSecurity
Grails plugin provide this functionality (i.e. the web pages allowing
you to do the security modifications and permissions)?

And in regards to James' comments on requestMappings, the latest
version of JSecurity's requestMapping technique is the most succinct
and clean way of defining url mappings that I've seen, and is much
nicer than Acegi's mechanism.  The JSecurity Grails plugin will have
this ability in its next release (it is in the current framework
release now, just not made its way yet into the plugin).

On Fri, May 16, 2008 at 9:05 AM, Jon.S <bulkmailme@...> wrote:

>
> James,
>
> I plan to make the role dynamic as well.  It is easier for me.
>
> Best Regards,
>
> Joni
>
> Joni,
>
> In JSecurity you can define all your filters on a role basis.  If you have
> planned ahead there would be no need to re-code for each new user, jsut
> assign them to a certain role.  That said having played with both I
> personally currently favour Acegi as I like the requestMapping style of
> securing things.
>
> James Hughes | Senior Software Engineer | Kainos | M: [phone] |
> j.hughes@...
>
> P Please consider the environment and do not print this mail unless
> necessary
> --
> View this message in context: http://www.nabble.com/jsecurity-VS-acegi-tp17272804p17274222.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon.S]

Hi there,

I just notice your taglib test(AuthorizeTagLibTest) in plugin folder, I might play with it some more.  Somehow I miss that from your docs...    

The only thing remains is to create some manager program where I can specify each role permision for each domain fields.  

For example:

class DomainFoo{
    String blah;
}

then you have another domain to store your role

class DomainRolePermission{
   String domainName;
   Role  theRole;
   short permisionLevel;
}

Then I need to write a taglib something similar like this...
<g:fieldVisibility value="${permisionLevel}"> ...

the permisionLevel could be: read, write, hidden

Then it will render text box if writeable, or hidden input, etc....

I am actually planning to write this because its pretty simple actually(maybe).  But if you want to include that, it will be superb -- I'll owe you a beer for that :)


Best Regards,

J

[Daniel Honig]

I've had the pleasure of developing against both plugins.  JSecurity
has a nicer model, more granular control of permissions and  from what
I understand, it has a somewhat unique ability to integrate
crossplatform applications with a single signon.   Its very cliche for
me to say this, but the JSecurity plugin is a "Mac" and acegi seems to
be the PC in this case.



On Fri, May 16, 2008 at 9:35 AM, Jon.S <bulkmailme@...> wrote:

>
> Hi there,
>
> I just notice your taglib test(AuthorizeTagLibTest) in plugin folder, I
> might play with it some more.  Somehow I miss that from your docs...
>
> The only thing remains is to create some manager program where I can specify
> each role permision for each domain fields.
>
> For example:
>
> class DomainFoo{
>    String blah;
> }
>
> then you have another domain to store your role
>
> class DomainRolePermission{
>   String domainName;
>   Role  theRole;
>   short permisionLevel;
> }
>
> Then I need to write a taglib something similar like this...
> <g:fieldVisibility value="${permisionLevel}"> ...
>
> the permisionLevel could be: read, write, hidden
>
> Then it will render text box if writeable, or hidden input, etc....
>
> I am actually planning to write this because its pretty simple
> actually(maybe).  But if you want to include that, it will be superb -- I'll
> owe you a beer for that :)
>
>
> Best Regards,
>
> J
>
> --
> View this message in context: http://www.nabble.com/jsecurity-VS-acegi-tp17272804p17274871.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon.S]

I just having problem with defining all securityFilter and assigning to certain role in advance.  I rather like my customer to define its own role and user.  Because it seems to me that if I need to add new security permision into the filter I need to repackage my application to war file.  But correct me if I'm wrong on this.

It's like what had shown in ACEGI tutorial where you can create new role, and assign this role permision(such as restrict the role's url).  

Best Regards,

J

[Ricardo J. Méndez]

I may not be understanding what you're saying Jon, but I believe you're saying this:

Your user wants to be able to define which roles can access function F.  You don't want to hard-code roles R and S  in advance to access the function F, but allow the end user to be able to define his own roles, and then say that those permissions can access the function. Is that correct?

If so there are ways of doing that with Jsecurity. For instance, you could say that permission P is required to access the function (for instance, Modify Book), and then programatically, at run time, allow the end security admin to choose which users have that permission via JsecUserPermissionRel or JsecRolePermissionRel.

On Fri, May 16, 2008 at 8:06 AM, Jon.S <bulkmailme@...> wrote:

I just having problem with defining all securityFilter and assigning to
certain role in advance.  I rather like my customer to define its own role
and user.  Because it seems to me that if I need to add new security
permision into the filter I need to repackage my application to war file.
But correct me if I'm wrong on this.

It's like what had shown in ACEGI tutorial where you can create new role,
and assign this role permision(such as restrict the role's url).

Best Regards,

J
--
View this message in context: http://www.nabble.com/jsecurity-VS-acegi-tp17272804p17275557.html

Sent from the grails - user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

--
Ricardo J. Méndez
http://ricardo.strangevistas.net/

[lhazlewood]

Ricardo said it exactly correct.

To elaborate:  Permissions classes (not instances) reflect raw
functionality and only change when your application's source code
change.  That is, a Permission class reflects 'what' the application
can do, and Users and Roles reflect 'who' can do the 'what' by their
association to Roles (which in turn are associated with permissions).
Permission instances however (different target/action combinations)
can and do change at runtime.

You can create a, say, UserPermission( "*", "read,create"), save that
to the database, create a JsecRolePermissionRel to relate it to a
Role.  The controller would check to make sure that the current user
has the UserPermission("*","create") permission. That would be
hard-coded into your source code (remember Permission checks can be
hard coded - the runtime instances can change).

Then that would ensure that only people who have the create user
permission could access that page.  You can add and remove
UserPermission instances dynamically at runtime (changing targets and
actions - maybe giving one role more user actions, say, read, create,
delete - or deleting other actions), but the concept of a
UserPermission check itself is related to raw functionality and won't
change.

For more:  http://www.jsecurity.org/api/org/jsecurity/authz/Permission.html

On Fri, May 16, 2008 at 10:25 AM, Ricardo J. Méndez
<mendezster@...> wrote:

> I may not be understanding what you're saying Jon, but I believe you're
> saying this:
>
> Your user wants to be able to define which roles can access function F.  You
> don't want to hard-code roles R and S  in advance to access the function F,
> but allow the end user to be able to define his own roles, and then say that
> those permissions can access the function. Is that correct?
>
> If so there are ways of doing that with Jsecurity. For instance, you could
> say that permission P is required to access the function (for instance,
> Modify Book), and then programatically, at run time, allow the end security
> admin to choose which users have that permission via JsecUserPermissionRel
> or JsecRolePermissionRel.
>
>
>
> On Fri, May 16, 2008 at 8:06 AM, Jon.S <bulkmailme@...> wrote:
>>
>> I just having problem with defining all securityFilter and assigning to
>> certain role in advance.  I rather like my customer to define its own role
>> and user.  Because it seems to me that if I need to add new security
>> permision into the filter I need to repackage my application to war file.
>> But correct me if I'm wrong on this.
>>
>> It's like what had shown in ACEGI tutorial where you can create new role,
>> and assign this role permision(such as restrict the role's url).
>>
>> Best Regards,
>>
>> J
>> --
>> View this message in context:
>> http://www.nabble.com/jsecurity-VS-acegi-tp17272804p17275557.html
>> Sent from the grails - user mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> Ricardo J. Méndez
> http://ricardo.strangevistas.net/

[Peter Ledbrook-2]

2008/5/16 Jon.S <bulkmailme@...>:
>
> I just having problem with defining all securityFilter and assigning to
> certain role in advance.  I rather like my customer to define its own role
> and user.  Because it seems to me that if I need to add new security
> permision into the filter I need to repackage my application to war file.
> But correct me if I'm wrong on this.
>
> It's like what had shown in ACEGI tutorial where you can create new role,
> and assign this role permision(such as restrict the role's url).

Ah, I've read the tutorial now so I know what you're talking about :)
This is possible, but would require some work on your part. So in this
particular case, it may be better to go with the Acegi plugin.

I was about to explain how to do this with the JSecurity plugin, but
it requires some serious thought. One approach would be to dynamically
add Grails filters, but I don't know how feasible that is. The only
other option I think is to have a single filter that matches all pages
and then does some pattern matching against something akin to
RequestMap instances in the database. This wouldn't be easy, but is
certainly doable. Whether it's a feature that's worth adding to the
JSecurity plugin depends on what the users think :)

Regards,

Peter

--
Software Engineer
G2One, Inc.
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[lhazlewood]

I vote for it - the ability to specify requestMappings to the database
would be nice.

However my previous email stands as a valid solution.  And I think it
is the ideal solution, and here's why:

If an admin can create a user or delete a user, or modify a forum
post, or whatever - these are all actions related to application
functionality core to what your system does.

The fact that this functionality is executed based on what
controller/url you visit is irrelevant.  In my opinion, permissioning
Controllers or URLs is a backwards way to think of the problem - its
inherently tied to how the GUI operates, which is secondary to how
your business logic should operate.

Your code _should_ perform permission checks based on raw permission
types (JSecurity supports Strings as well if you don't want to code
Permission classes).

This has big implications for other plugins:  Other plugins could
export somehow the Permission types (along with possible actions that
you can perform for a given type) that they use to control access.
The JSecurity plugin could get these types, and create a GSP page that
dynamically shows you all permissions available to a system, and an
admin could check off permission types & action combinations that they
want to assign to specific roles.  It could be a unified dynamic
security functionality available to _any_ plugin, all without
requiring the plugin developers to code this themselves.

Incredibly powerful if you think about business logic checks and stop
thinking about which urls you visit.

Cheers,

Les

On Fri, May 16, 2008 at 10:57 AM, Peter Ledbrook <peter@...> wrote:

> 2008/5/16 Jon.S <bulkmailme@...>:
>>
>> I just having problem with defining all securityFilter and assigning to
>> certain role in advance.  I rather like my customer to define its own role
>> and user.  Because it seems to me that if I need to add new security
>> permision into the filter I need to repackage my application to war file.
>> But correct me if I'm wrong on this.
>>
>> It's like what had shown in ACEGI tutorial where you can create new role,
>> and assign this role permision(such as restrict the role's url).
>
> Ah, I've read the tutorial now so I know what you're talking about :)
> This is possible, but would require some work on your part. So in this
> particular case, it may be better to go with the Acegi plugin.
>
> I was about to explain how to do this with the JSecurity plugin, but
> it requires some serious thought. One approach would be to dynamically
> add Grails filters, but I don't know how feasible that is. The only
> other option I think is to have a single filter that matches all pages
> and then does some pattern matching against something akin to
> RequestMap instances in the database. This wouldn't be easy, but is
> certainly doable. Whether it's a feature that's worth adding to the
> JSecurity plugin depends on what the users think :)
>
> Regards,
>
> Peter
>
> --
> Software Engineer
> G2One, Inc.
> http://www.g2one.com/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[lhazlewood]

One of our other JSecurity developers just now responded to someone
about how our default String-based permissioning works - very useful
for those interested in this thread:

http://www.jsecurity.org/node/1041#comment-155

Cheers,

Les

On Fri, May 16, 2008 at 11:16 AM, Les Hazlewood <les@...> wrote:

> I vote for it - the ability to specify requestMappings to the database
> would be nice.
>
> However my previous email stands as a valid solution.  And I think it
> is the ideal solution, and here's why:
>
> If an admin can create a user or delete a user, or modify a forum
> post, or whatever - these are all actions related to application
> functionality core to what your system does.
>
> The fact that this functionality is executed based on what
> controller/url you visit is irrelevant.  In my opinion, permissioning
> Controllers or URLs is a backwards way to think of the problem - its
> inherently tied to how the GUI operates, which is secondary to how
> your business logic should operate.
>
> Your code _should_ perform permission checks based on raw permission
> types (JSecurity supports Strings as well if you don't want to code
> Permission classes).
>
> This has big implications for other plugins:  Other plugins could
> export somehow the Permission types (along with possible actions that
> you can perform for a given type) that they use to control access.
> The JSecurity plugin could get these types, and create a GSP page that
> dynamically shows you all permissions available to a system, and an
> admin could check off permission types & action combinations that they
> want to assign to specific roles.  It could be a unified dynamic
> security functionality available to _any_ plugin, all without
> requiring the plugin developers to code this themselves.
>
> Incredibly powerful if you think about business logic checks and stop
> thinking about which urls you visit.
>
> Cheers,
>
> Les
>
> On Fri, May 16, 2008 at 10:57 AM, Peter Ledbrook <peter@...> wrote:
>> 2008/5/16 Jon.S <bulkmailme@...>:
>>>
>>> I just having problem with defining all securityFilter and assigning to
>>> certain role in advance.  I rather like my customer to define its own role
>>> and user.  Because it seems to me that if I need to add new security
>>> permision into the filter I need to repackage my application to war file.
>>> But correct me if I'm wrong on this.
>>>
>>> It's like what had shown in ACEGI tutorial where you can create new role,
>>> and assign this role permision(such as restrict the role's url).
>>
>> Ah, I've read the tutorial now so I know what you're talking about :)
>> This is possible, but would require some work on your part. So in this
>> particular case, it may be better to go with the Acegi plugin.
>>
>> I was about to explain how to do this with the JSecurity plugin, but
>> it requires some serious thought. One approach would be to dynamically
>> add Grails filters, but I don't know how feasible that is. The only
>> other option I think is to have a single filter that matches all pages
>> and then does some pattern matching against something akin to
>> RequestMap instances in the database. This wouldn't be easy, but is
>> certainly doable. Whether it's a feature that's worth adding to the
>> JSecurity plugin depends on what the users think :)
>>
>> Regards,
>>
>> Peter
>>
>> --
>> Software Engineer
>> G2One, Inc.
>> http://www.g2one.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon.S]

>Ah, I've read the tutorial now so I know what you're talking about :)
>This is possible, but would require some work on your part. So in this
>particular case, it may be better to go with the Acegi plugin.

That's my general feeling, It will be faster to implement in ACEGI but I just don't want to make bad decision due to my initial impression on tutorial.  

>I was about to explain how to do this with the JSecurity plugin, but
>it requires some serious thought. One approach would be to dynamically
>add Grails filters, but I don't know how feasible that is. The only
>other option I think is to have a single filter that matches all pages
>and then does some pattern matching against something akin to
>RequestMap instances in the database. This wouldn't be easy, but is
>certainly doable. Whether it's a feature that's worth adding to the
>JSecurity plugin depends on what the users think :)

It will be useful feature to have(for me).  Here's my reason, Let's say I define all controller, action combination in relates to predefine role and give the end user the war file.   If the end-user later on would like to add more pages and add new roles with specific permission, then my tech support poeple need me to recompile new war for them.   They become depended to me and it is just inefficient.  If I can add the filter in database it will be less pain for me to maintain  for the long run.

One other thing I also suggest maybe if we could have simple tag like:
<jsec:visibility role="${role}" ifWriteable="textBox">

it will automatically substitute to text box if the role is read & write, label if read only  or not shown if the user don't have any privileges to read.

Pardon me if the tag already exist :) I just don't see something similar in your docs.  I suppose I could use hasRole, lacksRole combination but it might be more efficient to have it in 1 tag.

Best Regards

J

[Helmut Denk]

i would not say that ... it depends on your
needs, what's better for you.

3 +points regarding spring-security:

- because of its integration into the spring-plattfom
spring-security (acegi) has a much broader base of
usage and a quite long history of improvements and
bugfixing.

- spring-security 2.0 is a complete rework
and brings significant simplification compared
to 1.x.

- spring-security offers mature adaptors for many third-party
security components. for instance: many companys will
have decided what sso-solution they want to use, long
before they think of introducing grails. so grails-security
must be adaptable to their specific sso-solution.

the more choices one has, the better and jsecurity has
it's strongs too as you could read in the posts.

have a nice time

Daniel Honig wrote:

Its very cliche for
me to say this, but the JSecurity plugin is a "Mac" and acegi seems to
be the PC in this case