Re: [Acegisecurity-developer] Instance based security
March, Andres wrote: 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). - 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. - 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? I couldn't see a FK mapping to acl_object_relationship so I wasn't 100%. Perhaps we should provide an additional JDBC DAO provider with a view to sharing a central table structure between authentication and ACLs. ie: - Recipient table: id IDENTITY, type INTEGER (user or role), name VARCHAR (username or rolename) - 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 - 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
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/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
