RE: [Acegisecurity-developer] Instance based security
> -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
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. 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 --- 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
RE: [Acegisecurity-developer] Instance based security
> > >3 more things: > > > >- I sync'd to cvs and don't see your changes. Got the JAAS ones though. > > > > > Welcome to SourceForge. AFAIK they have a timed synchronisation from the > developer CVS servers to the anonymous access ones. So give it a few > hours (I received the commit messages to acegisecurity-cvs, so I know > they're there). Ok. > > >- What is acl_class for? I don't see it used in your tests. > > > > > This is the BasicAclEntry instance created. I don't test for it > expressly in the unit tests because it has to be successful in order to > return anything from the JdbcDaoImpl. 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. > > >- I forgot, below is how I have had to model it. I would think it is to > >complex for a base implementation but I just wanted you to see what I > >must handle for our product. Notice we are using integers instead of > >varchar for all acl lookups. > > > We could make all "recipients" (roles and users) need an entry in > acl_object_identity, then use a FK to it from acl_permission.recipient. > The issue is it would require every possible recipient to have an entry > in acl_object_identity, when by their nature they already have other > tables within an application (usually the users and roles tables). > > I would assume most applications don't need the flexibility of treating > users and roles as both "recipients" as well as "domain object > instances" for which permissions can be assigned against. Is that what > you're trying to do? Yes. Not sure if you saw my previous post since you replied to this one. But I think it is a common use case to have specific users edit specific users' data. I am not saying to include this ability in your base design just that is common. Besides when I get done with my implementation, I will try and submit anything applicable to you for possible inclusion. But the farther you get with a base implementation really helps me out. I couldn't see a FK mapping to > acl_object_relationship so I wasn't 100%. > No, I purposefully drive everything off of the object_identity table. By association a recipient does not need a relationship entry but does require a entry in the object_identity table. > Perhaps we should provide an additional JDBC DAO provider with a view to > sharing a central table structure between authentication and ACLs. ie: > I think that is wise. > - Recipient table: id IDENTITY, type INTEGER (user or role), name > VARCHAR (username or rolename) 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. > - Users table: recipient_id INTEGER (FK to Recipient), password VARCHAR, > email VARCHAR, lastLogin DATE, unsuccessfulPasswords INTEGER etc > - Role_member table: role_recipient_id, user_recipient_id This is exactly the parent-child relationship that I must implement. It made sense to me to put this in acl_object_relationship since my recipients must be domain objects as well. > - Acl_permission: change recipient to be an INTEGER (with FK to > Recipient table) > > This would still not address your requirement to also treat recipients > as domain object instances. But still, with an appropriate trigger > against the Recipient table you shouldn't have much difficulty auto > creating/deleting a corresponding row in the acl_object_identity table. > > Ben > > > > --- > 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/acegisecu
