> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Ben Alex > Sent: Saturday, July 31, 2004 4:41 PM > To: [EMAIL PROTECTED] > Subject: Re: [Acegisecurity-developer] Instance based security > > March, Andres wrote: > > >Ahh, I see now. This is like a permission type. I debated this idea > >here but could not find a use for it. I could not see how it would add > >info to what the permission meant. It seems that the recipient, > >accessed object, and mask conveyed everything I need to. I was planning > >on leaving it to the security framework to interpret the class of > >permission on the fly. In this way it is also polymorphic in nature. > > > > > Different domain objects are likely to have very different permission > meanings. A BankAccount object would have permissions like allowDeposit, > allowWithdraw, allowBalanceCheck, allowClosure. A Folder object would > have permissions like create, delete, read, write and execute. It's > better to provide a concrete class that reflects the possible > permissions, which bit represents which permission, and easy getters to > whether a permission is granted. Thus relying classes simply call > AclManager to get the AclEntry[]s, cast the AclEntry to the appropriate > concrete class, and call the respective getters (eg isAllowDeposit, > isAllowWithdraw). Enabling this behaviour requires the extra acl_class > column.
I see your point there. I guess I was planning to leave it up to the voter to determine what to do with the acl entry. This way a domain class is not bound to a single acl entry class. My domain objects will need several types of permissions which I thought would best be enforced by assigning voters to the domain methods. This could be a long discussion and I'm not sure it matters in the long run. You are just adding extra flexibility. The only thing that bothered me was the connection between a domain object and the acl_class. Wouldn't this be better expressed in the applicationContext of Spring? > > >Is this easier to implement than just putting this info into the > >object_identity table? Or is it better because you have a clear > >division between recipient and domain objects? This design is > >constraining to use cases such as mine but I can see the clarity in > >doing this. I figure on implementing my own dao anyway. I am using > >hibernate. > > > > > > > Indeed. The problem from a security framework design point of view is > that fuzzy line between what belongs in the framework and what belongs > in the realm of end developer responsibility. I can some applications, > like yours and say LDAP directories, do need to treat users and roles as > both recipients and domain object instances. The grey line is whether > that's "mainstream" enough to make the base JDBC implementation support > it or not. Whether it belongs in the framework or not, we must ensure > the base JDBC class is modular enough (in terms of protected methods) > such that it _could_ be done without writing a DAO from scratch. Do you > believe the existing JDBC DAO provides enough flexibility in this regard? > > Ben > > I do not think it would hurt to have the ability to treat users as both recipients and domain objects. But it certainly does not need to be in the base implementation. As for the question if your design would preclude someone like me from adding that flexibility later, I assume you are speaking of the interface BasicAclDao not the implementation. I don't forsee any issue with the interface. Personally however I would need to create my own implementation due to the fact I am using hibernate. > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Acegisecurity-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
