acegi ACL implementation - more thoughts

Hi all,
  Some more thoughts on the acegi ACL implementation and how
we could
use it:
1. For providing the hibernate based acl implementation we
could provide
an external mapping. We could even use Hibernate annotations
to provide
the mapping but that will involve changing the base classes
and I want
to avoid that. As Cosmo has the hibernate annotation based
mapping now,
do you feel that having a combination of xml mappings and
annotations
mapping is acceptable?

This are my initial thoughts, I have been looking at 
org.acegi.acls.domain.AclImpl
org.acegi.acls.domain.AccessControlEntryImpl
etc

2. There has been some interests on the acegi forum about
the hibernate
based acl implementation (old implementation)
http://forum.springframework.org/showthread.php?t=13956
http://forum.springframework.org/showthread.php?t=13956

3. Acegi 1.0.3 is out . It
includes the new acls from acegi's sandbox.
It did not work out of the box and I would like to know the
changes to
make it work with Cosmo. I am aware there is a bug to
upgrade to the
latest acegi, but if its documented/trivial to do, I could
do that.

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 11/21/06, Vinubalaji Gopal <vinuosafoundation.org>
wrote:

> 1. For providing the hibernate based acl implementation
we could provide
> an external mapping. We could even use Hibernate
annotations to provide
> the mapping but that will involve changing the base
classes and I want
> to avoid that. As Cosmo has the hibernate annotation
based mapping now,
> do you feel that having a combination of xml mappings
and annotations
> mapping is acceptable?

i'd rather use one mapping mechanism, and the annotations
are REALLY
nice. what base classes are you referring to - the acegi
ones?

> 2. There has been some interests on the acegi forum
about the hibernate
> based acl implementation (old implementation)
> http://forum.springframework.org/showthread.php?t=13956
> http://forum.springframework.org/showthread.php?t=13956

hm. after reading over that, i'm almost tempted to just
stick with
acegi's jdbc stuff and not worry about hibernate for acls.
here's a
thought:

   - define o.o.c.dao.AclDao interface
   - add a AclDao dependency to UserService and
ContentService
   - provide a o.o.c.dao.acegi.AcegiJdbcAclDao adapter to
acegi's
dbcExtendedDaoImpl

this seems like the least amount of work that isolates our
acl
persistence implementation from our service implementations.

> 3. Acegi 1.0.3 is out . It
includes the new acls from acegi's sandbox.
> It did not work out of the box and I would like to know
the changes to
> make it work with Cosmo. I am aware there is a bug to
upgrade to the
> latest acegi, but if its documented/trivial to do, I
could do that.

i haven't looked into the upgrade yet. upgrading spring and
acegi are
a lower priority than our newer feature work, so it's
possible they'll
slip to the next release. if you want to give the acegi
upgrade a try
and provide a patch, that would certainlly be helpful 
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Tue, 2006-11-21 at 12:29 -0800, Brian Moseley wrote:

> i'd rather use one mapping mechanism, and the
annotations are REALLY
> nice. what base classes are you referring to - the
acegi ones?
Yes the acegi classes - AclImpl, AccessControlEntryImpl,
etc. I could
provide my own implementation of Acl, AccessControlEntry -
but that will
mostly be rewriting the same thing again. So thought
providing mappings
based on the existing implementation will be easy/effective
reuse.

> 
> > 2. There has been some interests on the acegi
forum about the hibernate
> > based acl implementation (old implementation)
> > http://forum.springframework.org/showthread.php?t=13956
> > http://forum.springframework.org/showthread.php?t=13956


Yeh I was also tempted long time then thought that providing
a single
hibernate based implementation for all the data access will
be a nice
solution. Then if performance is better achieved using jdbc,
we need to
compromise.
Hibernate based ACL implementation in acegi issue was closed
saying
performance is better achieved using JDBC.
http://opensource.atlassian.com/projects/spring/bro
wse/SEC-92

so if everyone agrees on using jdbc for acl, we could go
ahead with it.
If you feel that if we can get the same kind of performance
using
hibernate, then I could have those implementations now.


>   - define o.o.c.dao.AclDao interface
>    - add a AclDao dependency to UserService and
ContentService
>    - provide a o.o.c.dao.acegi.AcegiJdbcAclDao adapter
to acegi's
> dbcExtendedDaoImpl
The new acegi does not have this dao's. Checkout the acls
directory in
acegi 1.0.3.  AclImpl is the implementation of all the Acl
interfaces -
JdbcAclService, JdbcMutablAclService (in acls/jdbc
directory) are the
services which insert, delete, modifies the actual tables.  


>yet. upgrading spring and acegi are
>a lower priority than our newer feature work, so it's
possible they'll
>slip to the next release. 

can you provide me with the osafoundation's url of the
sources for the
external libraries - esp acegi. I always get lost trying to
find them.



_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 11/21/06, Vinubalaji Gopal <vinuosafoundation.org>
wrote:

> so if everyone agrees on using jdbc for acl, we could
go ahead with it.
> If you feel that if we can get the same kind of
performance using
> hibernate, then I could have those implementations now.

i don't see any major advantages to doing acls with
hibernate, so i
vote that we go ahead and use jdbc until we find a
compelling reason
to stop and use hibernate instead.

> The new acegi does not have this dao's. Checkout the
acls directory in
> acegi 1.0.3.  AclImpl is the implementation of all the
Acl interfaces -
> JdbcAclService, JdbcMutablAclService (in acls/jdbc
directory) are the
> services which insert, delete, modifies the actual
tables.

ok,  i was going on what ben said in the forum post. the
concept is
the same tho - wrap whatever acegi provides ;)

> can you provide me with the osafoundation's url of the
sources for the
> external libraries - esp acegi. I always get lost
trying to find them.

we don't maintain a copy of acegi in our subversion
repository, if
that's what you're asking about. you can get the acegi
source at
acegisecurity.org.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Tue, 2006-11-21 at 13:51 -0800, Brian Moseley wrote:

> we don't maintain a copy of acegi in our subversion
repository, if
> that's what you're asking about. you can get the acegi
source at
> acegisecurity.org.

ah k. I thought we had our own version of acegi similar to
jcr, etc. let
me see the real *upgrade* problem then.

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Brian Moseley wrote:
> On 11/21/06, Vinubalaji Gopal <vinuosafoundation.org> wrote:
>
>> so if everyone agrees on using jdbc for acl, we
could go ahead with it.
>> If you feel that if we can get the same kind of
performance using
>> hibernate, then I could have those implementations
now.
>
> i don't see any major advantages to doing acls with
hibernate, so i
> vote that we go ahead and use jdbc until we find a
compelling reason
> to stop and use hibernate instead.
I'm confused.  Are we talking about using two persistence
apis (one for 
ACLs using straight jdbc and one for rest of the model using

hibernate)?  This might be confusing because ACLs are
associated to 
Items and ACEs to Users right?  Items and Users are managed
by 
hibernate, and ACLs would be managed by some other acegi
jdbc 
framework?  This seems like a bad idea, but I need to look
at the acegi 
stuff closer.

-Randy
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Tue, 2006-11-21 at 16:07 -0600, Randy Letness wrote:

> I'm confused.  Are we talking about using two
persistence apis (one for 
> ACLs using straight jdbc and one for rest of the model
using 
> hibernate)?  This might be confusing because ACLs are
associated to 
> Items and ACEs to Users right?  Items and Users are
managed by 
> hibernate, and ACLs would be managed by some other
acegi jdbc 
> framework?  This seems like a bad idea, but I need to
look at the acegi 
> stuff closer.

Here is the schema of old acl implementation. The new acl
schema will be
different but the basic idea will be the same.
http://www.ac
egisecurity.org/dbinit.txt

An ObjectIdentity is constructed to secure any domain object
and this
ObjectIdentity is based on class name, id, etc. So we will
have to
construct an ObjectIdentity based on the Item, ContentItem,
etc. 
Check out addPermission at:
https://svn.sourceforge.net/sv
nroot/acegisecurity/trunk/acegisecurity/samples/contacts/src
/main/java/sample/contact/ContactManagerBackend.java
and
https://svn.sourceforge.net/svnroot
/acegisecurity/trunk/acegisecurity/samples/contacts/src/main
/java/sample/contact/ContactDaoSpring.java 

User or Group will be mapped to an Sid.

So ultimately storing anything in the acl's table goes
through a mapping
process and it will not be really confusing  if we do this
mapping
neatly. 

Yes having two data sources may not be desirable but if that
is the best
way to achieve performance we have to go for it. If there
are ways in
which we can achieve the same performance using hibernate,
we could do
that. The jdbc based implementation also has a default cache
implementation. 

Other thing if we think about clustering, etc and if
hibernate has
inbuilt support for that, we could think about hibernate
based
implementation at that time or if there are more reasons we
could have a
hibernate based implementation now itself.


_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 11/21/06, Vinubalaji Gopal <vinuosafoundation.org>
wrote:

> Yes having two data sources may not be desirable but if
that is the best
> way to achieve performance we have to go for it. If
there are ways in
> which we can achieve the same performance using
hibernate, we could do
> that. The jdbc based implementation also has a default
cache
> implementation.

performance is not my concern - getting a working feature
built in an
architecturally sound way is. if it's going to take a month
to
re-implement a bunch of acegi interfaces to use hibernate,
that is a
red flag. if it would only take a week, okay fine.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Tue, 2006-11-21 at 15:39 -0800, Brian Moseley wrote:

> performance is not my concern - getting a working
feature built in an
> architecturally sound way is. if it's going to take a
month to
> re-implement a bunch of acegi interfaces to use
hibernate, that is a
> red flag. if it would only take a week, okay fine.


We won't know the performance details unless we see the real
performance
difference  - I am just speculating based on the acegi forum
and jira
issues. But I am concerned on how well ACL's will perform,
since every
access will have more overhead compared to the non-acl
implementation.
So in the long run any kind of performance improvement there
is really
important.

Let me see on how feasible it is to have this hibernate
based dao's ..If
I could easily plugin the hibernate based access, I would
happily do it.
That may not be the case with the new acl implementation.


_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev