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
Re: [Acegisecurity-developer] Instance based security
March, Andres wrote: I need to implement this anyway, so if you can wait I would be glad to help out. But I won't need to start this effort for awhile. It might be better for you do this until I get comfortable with the code. I am eager to contribute but I have non-instance based security to implement first (product priorities). One other question, were you planning on implementing a voter for this functionality? I know you mentioned this earlier. Hi Andres I just checked into CVS the improvements. The end database schema is now heavily normalised, with plenty of constraints to prevent incorrect data: CREATE TABLE acl_object_identity ( id IDENTITY NOT NULL, object_identity VARCHAR_IGNORECASE(250) NOT NULL, parent_object INTEGER, acl_class VARCHAR_IGNORECASE(250) NOT NULL, CONSTRAINT unique_object_identity UNIQUE(object_identity), FOREIGN KEY (parent_object) REFERENCES acl_object_identity(id) ); CREATE TABLE acl_permission ( id IDENTITY NOT NULL, acl_object_identity INTEGER NOT NULL, recipient VARCHAR_IGNORECASE(100) NOT NULL, mask INTEGER NOT NULL, CONSTRAINT unique_recipient UNIQUE(acl_object_identity, recipient), FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity(id) ); Do you have any further suggestions/feedback? Best regards 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
You're quick. I'm glad you took this on and not me. The new schema is more where I was headed. The only things that I will be implementing differently are the parent-child relationship and identity. It appears you have made the relationship 1-to-many (parent has many children) while I will need to create a many-to-many relationship table. But I think a 1-to-many design is better for your base implementation. The object identity difference I refer to is that my recipient can sometimes be the object being accessed. For example, a user may be granted access to another user (like an administrator role with specific users they may access). In my case, a recipient can also be in the acl_object_identity table with a parent and so on. Where this applies to your design is that you have recipient as a VARCHAR field not an id INTEGER from acl_object_identity. You may not want objects to have parents when they serve as recipient to a permission but that can be dictated in code by just not navigating the relationship of the recipient (is that confusing?). When the object serves as the entity on which permissions have been granted, that parent relationship could have value. Guess all I'm trying to say is that it would make sense to make the recipient an INTEGER constrained via foreign key to the id in the acl_object_identity table. For me this is worthwhile, what do you think? Hi Andres I just checked into CVS the improvements. The end database schema is now heavily normalised, with plenty of constraints to prevent incorrect data: CREATE TABLE acl_object_identity ( id IDENTITY NOT NULL, object_identity VARCHAR_IGNORECASE(250) NOT NULL, parent_object INTEGER, acl_class VARCHAR_IGNORECASE(250) NOT NULL, CONSTRAINT unique_object_identity UNIQUE(object_identity), FOREIGN KEY (parent_object) REFERENCES acl_object_identity(id) ); CREATE TABLE acl_permission ( id IDENTITY NOT NULL, acl_object_identity INTEGER NOT NULL, recipient VARCHAR_IGNORECASE(100) NOT NULL, mask INTEGER NOT NULL, CONSTRAINT unique_recipient UNIQUE(acl_object_identity, recipient), FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity(id) ); Do you have any further suggestions/feedback? Best regards 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
3 more things: - I sync'd to cvs and don't see your changes. Got the JAAS ones though. - What is acl_class for? I don't see it used in your tests. - 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. CREATE TABLE acl_object_identity ( id IDENTITY NOT NULL, object_identity VARCHAR_IGNORECASE(250) NOT NULL, CONSTRAINT unique_object_identity UNIQUE(object_identity), FOREIGN KEY (parent_object) REFERENCES acl_object_identity(id) ); CREATE TABLE acl_object_relationship ( id INTEGER NOT NULL, parent_id INTEGER NOT NULL, CONSTRAINT pk_object_relationship PRIMARY KEY (id, parent_id), FOREIGN KEY (parent_id) REFERENCES acl_object_identity(id), FOREIGN KEY (id) REFERENCES acl_object_identity(id) ); CREATE TABLE acl_permission ( acl_object_id INTEGER NOT NULL, recipient_id INTEGER NOT NULL, mask INTEGER NOT NULL, CONSTRAINT pk_object_relationship PRIMARY KEY (acl_object_id, recipient_id), FOREIGN KEY (acl_object_id) REFERENCES acl_object_identity(id), FOREIGN KEY (recipient_id) REFERENCES acl_object_identity(id) ); Hi Andres I just checked into CVS the improvements. The end database schema is now heavily normalised, with plenty of constraints to prevent incorrect data: CREATE TABLE acl_object_identity ( id IDENTITY NOT NULL, object_identity VARCHAR_IGNORECASE(250) NOT NULL, parent_object INTEGER, acl_class VARCHAR_IGNORECASE(250) NOT NULL, CONSTRAINT unique_object_identity UNIQUE(object_identity), FOREIGN KEY (parent_object) REFERENCES acl_object_identity(id) ); CREATE TABLE acl_permission ( id IDENTITY NOT NULL, acl_object_identity INTEGER NOT NULL, recipient VARCHAR_IGNORECASE(100) NOT NULL, mask INTEGER NOT NULL, CONSTRAINT unique_recipient UNIQUE(acl_object_identity, recipient), FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity(id) ); Do you have any further suggestions/feedback? Best regards 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: I agree with your assessment Ben. Had many of those thoughts myself as I was pondering our situation. In the end we went with VOTERS DETECT OBJECT AS PARAMETER AND QUERY ACL OBJECT. Seems like the best choice for us since we only want to deny or allow access not mutate or filter properties of the object. I've just added an access control list (ACL) package to CVS HEAD. It offers: - integer bit masking (like Unix's chmod command) - permission inheritance (including blocking) - JDBC ACL repository - caching - pluggable like the rest of Acegi Security - about 99% unit test coverage accordingly to Clover - all classes have Javadocs - covered in the reference guide No sample application yet, but I'm working on that tomorrow as part of Spring RCP's Petclinic. People's comments on the new package are most welcome. Best regards Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Instance based security
Wow, great work Ben. One question though, shouldn't the parent-child object identity relationship be maintained outside the ACL table since conceivably there will be many records for the same child? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Thursday, July 29, 2004 12:52 AM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] Instance based security March, Andres wrote: I agree with your assessment Ben. Had many of those thoughts myself as I was pondering our situation. In the end we went with VOTERS DETECT OBJECT AS PARAMETER AND QUERY ACL OBJECT. Seems like the best choice for us since we only want to deny or allow access not mutate or filter properties of the object. I've just added an access control list (ACL) package to CVS HEAD. It offers: - integer bit masking (like Unix's chmod command) - permission inheritance (including blocking) - JDBC ACL repository - caching - pluggable like the rest of Acegi Security - about 99% unit test coverage accordingly to Clover - all classes have Javadocs - covered in the reference guide No sample application yet, but I'm working on that tomorrow as part of Spring RCP's Petclinic. People's comments on the new package are most welcome. Best regards Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ 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
[Acegisecurity-developer] Instance based security
Has any thought been given to adding instance based security support to Acegi? This seems to be a common requirement. Basically, what I mean by this is that you can apply security constraints (hopefully in a declarative fashion) to an object class with rules that are capable of discriminating on instance data. As an example, say you have an Employee object with a salary property. Only some roles should be allowed to view the salary. And only some roles should be able to view any information related to a CEO Employee. As an implementation example, I have recently had to implement something similar to this, and I did so by applying aspects to my service instances. As DTOs enter and leave a service, my aspect would inspect the various object instances and apply the declarative security constraints. In our case, it was even more involved, as we needed the ability to actually modify the DTO: if a property was off limits, then its value would be replaced with a secured value. This way, when the DTO is transmitted to a client (via a web service), the sensitive information will not be sent across the wire. Such security constraints also had the ability to enforce data operations: create, read, update, delete. So, for example, I could say that a role can read the salary field, but not be allowed to change the salary field. We also provided a mechanism whereby a client can ask for a security map of an instance (or a class, for more general cases), so that it can know what security constraints are in effect for a particular object. This is useful to dynamically alter a UI based on what is allowed on an instance. Thoughts, comments? - Andy --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Instance based security
Can't this be done such using Method SecurityMethodInvocation security in Acegi? Not sure how you know it is a CEO employee declaratively though. I guess this is what you are asking. like: sample.Employee.getSalary=ROLE_MANAGER sample.Employee.getAddress=ROLE_ALL Sorry, I know the example is not adequate. Has any thought been given to adding instance based security support to Acegi? This seems to be a common requirement. Basically, what I mean by this is that you can apply security constraints (hopefully in a declarative fashion) to an object class with rules that are capable of discriminating on instance data. As an example, say you have an Employee object with a salary property. Only some roles should be allowed to view the salary. And only some roles should be able to view any information related to a CEO Employee. As an implementation example, I have recently had to implement something similar to this, and I did so by applying aspects to my service instances. As DTOs enter and leave a service, my aspect would inspect the various object instances and apply the declarative security constraints. In our case, it was even more involved, as we needed the ability to actually modify the DTO: if a property was "off limits", then its value would be replaced with a secured value. This way, when the DTO is transmitted to a client (via a web service), the sensitive information will not be sent across the wire. Such security constraints also had the ability to enforce data operations: create, read, update, delete. So, for example, I could say that a role can read the salary field, but not be allowed to change the salary field. We also provided a mechanism whereby a client can ask for a "security map" of an instance (or a class, for more general cases), so that it can know what security constraints are in effect for a particular object. This is useful to dynamically alter a UI based on what is allowed on an instance. Thoughts, comments? - Andy --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Instance based security
This is something I've been pondering as well. Stefan: I don't think that's what Andy means. I believe that the security would be based on some property of the instance, rather than of the user. I came from the Notes/Domino world, where a similar concept was applied with Readers and Authors properties of a document. There, a document might have a property called AllowedReaders which might be a list of something like (turning into the Acegi type terminology): ROLE_Admin ROLE_Approver Steve Storey/SomeCompany In this case, ideally, I'd like the security manager to decide whether to allow the action based on who I am as well as the roles I have. In this case, the action would be allowed if one of my principals was Steve Storey/SomeCompany or I have the ROLE_ADMIN role, or ROLE_Approver role. I haven't properly thought it all through yet, but I think this can be done with a custom Voter implementation (rather than having to do a complete AccessDecisionManager, which might be more appropriate for some circumstances). It should be fairly easy if the Object implements a specific interface (e.g. InstanceSecured) which might have the facility to return a list of principals (including names, roles, groups etc.) authorised to read the object and modify it. There's no reason why this couldn't be extended further to specific applications, so an object might return specific lists of principals authorised to read, modify content, approve, delete, etc. just by implementing different interfaces. As I'm learning a fair amount at the moment with Acegi, Spring and Hibernate, I haven't got down to actually trying to implement such a scheme yet, and I think there can be ways to make it more generic. Steve. Steve Storey Cygnite Ltd. 4th Floor, Counting House, 53 Tooley Street London SE1 2QN. T : (+44) 020 7645 3833 F : (+44) 020 7645 3834 E : [EMAIL PROTECTED] W : http://www.cygnite.com/
Re: [Acegisecurity-developer] Instance based security
Actually, that is exactly what I was stating. He needs to know whether an employee is a CEO or a regular employee since both use the same Employee object. What I was eluding to is that currently, even if you added a property in the Employee object to determine if it is a CEO or not, I was not sure if the Method security would be able to decide upon that attribute. But I think your suggestions regarding using a voter or other way may just work. I am also now starting to integrate Acegi with my application so I am no expert and have not looked into writing a custom voter. I have written a custom provider, custom processing filter and custom filter entry point. I will need to give this some more thought since I have came across this scenario many times and sure will in this current application. Thank uyou. This is something I've been pondering as well. Stefan: I don't think that's what Andy means. I believe that the security would be based on some property of the instance, rather than of the user. I came from the Notes/Domino world, where a similar concept was applied with Readers and Authors properties of a document. There, a document might have a property called "AllowedReaders" which might be a list of something like (turning into the Acegi type terminology): ROLE_Admin ROLE_Approver Steve Storey/SomeCompany In this case, ideally, I'd like the security manager to decide whether to allow the action based on who I am as well as the roles I have. In this case, the action would be allowed if one of my principals was "Steve Storey/SomeCompany" or I have the ROLE_ADMIN role, or ROLE_Approver role. I haven't properly thought it all through yet, but I think this can be done with a custom Voter implementation (rather than having to do a complete AccessDecisionManager, which might be more appropriate for some circumstances). It should be fairly easy if the Object implements a specific interface (e.g. InstanceSecured) which might have the facility to return a list of principals (including names, roles, groups etc.) authorised to read the object and modify it. There's no reason why this couldn't be extended further to specific applications, so an object might return specific lists of principals authorised to read, modify content, approve, delete, etc. just by implementing different interfaces. As I'm learning a fair amount at the moment with Acegi, Spring and Hibernate, I haven't got down to actually trying to implement such a scheme yet, and I think there can be ways to make it more generic. Steve. Steve StoreyCygnite Ltd.4th Floor, Counting House,53 Tooley StreetLondon SE1 2QN.T : (+44) 020 7645 3833F : (+44) 020 7645 3834E : [EMAIL PROTECTED]W : http://www.cygnite.com/
RE: [Acegisecurity-developer] Instance based security
This is exactly what I am implementing right now. Funny, that this is the first post I see when I joined the list. I am creating a series of custom voters: SimpleRoleVoter will grant access if the user has the role in question, deny otherwise EntityRoleVoter will grant access if any of the users roles matches any of the roles of the entity being accessed, deny otherwise. OwnerRelationshipVoter will grant access if the entity being accessed is owned by the user, deny otherwise Maybe another type of relationship as well. I am not creating my own AccessDecisionManager. In order to plug in to existing authentication, I am implementing a custom provider and token. Anything about this seem not right? We are going to use the method invocation interceptor but it might be useful to write a custom one in the future. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan D Sookraj Sent: Thursday, July 22, 2004 9:51 AM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] Instance based security Actually, that is exactly what I was stating. He needs to know whether an employee is a CEO or a regular employee since both use the same Employee object. What I was eluding to is that currently, even if you added a property in the Employee object to determine if it is a CEO or not, I was not sure if the Method security would be able to decide upon that attribute. But I think your suggestions regarding using a voter or other way may just work. I am also now starting to integrate Acegi with my application so I am no expert and have not looked into writing a custom voter. I have written a custom provider, custom processing filter and custom filter entry point. I will need to give this some more thought since I have came across this scenario many times and sure will in this current application. Thank uyou. This is something I've been pondering as well. Stefan: I don't think that's what Andy means. I believe that the security would be based on some property of the instance, rather than of the user. I came from the Notes/Domino world, where a similar concept was applied with Readers and Authors properties of a document. There, a document might have a property called AllowedReaders which might be a list of something like (turning into the Acegi type terminology): ROLE_Admin ROLE_Approver Steve Storey/SomeCompany In this case, ideally, I'd like the security manager to decide whether to allow the action based on who I am as well as the roles I have. In this case, the action would be allowed if one of my principals was Steve Storey/SomeCompany or I have the ROLE_ADMIN role, or ROLE_Approver role. I haven't properly thought it all through yet, but I think this can be done with a custom Voter implementation (rather than having to do a complete AccessDecisionManager, which might be more appropriate for some circumstances). It should be fairly easy if the Object implements a specific interface (e.g. InstanceSecured) which might have the facility to return a list of principals (including names, roles, groups etc.) authorised to read the object and modify it. There's no reason why this couldn't be extended further to specific applications, so an object might return specific lists of principals authorised to read, modify content, approve, delete, etc. just by implementing different interfaces. As I'm learning a fair amount at the moment with Acegi, Spring and Hibernate, I haven't got down to actually trying to implement such a scheme yet, and I think there can be ways to make it more generic. Steve. Steve Storey Cygnite Ltd. 4th Floor, Counting House, 53 Tooley Street London SE1 2QN. T : (+44) 020 7645 3833 F : (+44) 020 7645 3834 E : [EMAIL PROTECTED] W : http://www.cygnite.com/
[Acegisecurity-developer] Instance based security
Andy Depue wrote: Has any thought been given to adding instance based security support to Acegi? This seems to be a common requirement. There are so many ways of approaching instant-level security, as touched on by the other replies to this thread. The major issues are where to get the domain instance specific ACL information from and how to change any returned value. I've copied this to the RCP list as they probably have some views on the optimal approach, and which they'd like to see demonstrated in Petclinic RCP. Here is a quick summary of the main ways to approach instance-level security from an Acegi Security perspective: BUSINESS METHODS DO SECURITY THEMSELVES. This isn't as bad as it sounds. Business methods can simply access the ContextHolder and obtain the Authentication object. That way they can filter etc as they see fit. Advantages: simple, no infrastructure required, can change the returned object. Disadvantages: couples business code to Acegi, more difficult to test as there is limited separation of concerns (though you can write separate utility classes to help overcome this). VOTERS DETECT OBJECT AS PARAMETER AND QUERY EXISTING GrantedAuthority[]s. In this case you add custom GrantedAuthority[]s to the Authentication object during the original authentication process. Later the voter looks up those authorities and authorizes access to the domain instance accordingly. I'm presently using this approach in the Petclinic RCP sample (still being written, yet to be checked in). Advantages: simple, easy to test. Disadvantages: not scalable to thousands of instances, must customise the AuthenticationProvider (or AuthenticationDao if using DaoAuthenticationProvider), cannot change the returned object. VOTERS DETECT OBJECT AS PARAMETER AND OPEN ACTUAL INSTANCE. This is used in the Contacts sample application. A voter handles detecting a method invocation concerning an identity, opens the domain instance, calls a getter to obtain the ACL (access control list) information, and a comparison is made to the Authentication object. Advantages: fairly simple, easy to test. Disadvantages: opens a domain instance twice (in the voter and again in the business method), cannot change the returned object. VOTERS DETECT OBJECT AS PARAMETER AND QUERY ACL OBJECT. This would be a variation on the above option, but instead of opening the target domain instance twice, an ACL manager object would be consulted to obtain the instance-specific privileges. Advantages: highly decoupled from the domain objects, addresses performance issues, simple to test the parts, easily offers ACL inheritance, administration tools have a central reference point for all application ACL information. Disadvantages: getting complex, cannot change the returned object. MethodSecurityInterceptor CALLS A RESULT PROCESSOR. This would be done so that a list of classes can routinely be applied against the object returned from a method invocation. These classes could do things like Andy needs, such as obfuscate properties etc. If we went with the voter backed with an ACL manager approach on the way into the method invocation, these classes can easily determine which mutations they should perform on the returned object. The only requirement would be the classes should not throw an exception, as the business methods have already taken place. An issue is how mutated values would affect ORM if they were subsequently re-presented for committing. How do you handle this, Andy? Comments? Preferences? Best regards Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Instance based security
I agree with your assessment Ben. Had many of those thoughts myself as I was pondering our situation. In the end we went with VOTERS DETECT OBJECT AS PARAMETER AND QUERY ACL OBJECT. Seems like the best choice for us since we only want to deny or allow access not mutate or filter properties of the object. - Andres March Platform - Apps Engineering Sony Online Entertainment desk: 858.577.3373 cell: 619.519.1519 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Thursday, July 22, 2004 5:16 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Acegisecurity-developer] Instance based security Andy Depue wrote: Has any thought been given to adding instance based security support to Acegi? This seems to be a common requirement. There are so many ways of approaching instant-level security, as touched on by the other replies to this thread. The major issues are where to get the domain instance specific ACL information from and how to change any returned value. I've copied this to the RCP list as they probably have some views on the optimal approach, and which they'd like to see demonstrated in Petclinic RCP. Here is a quick summary of the main ways to approach instance-level security from an Acegi Security perspective: BUSINESS METHODS DO SECURITY THEMSELVES. This isn't as bad as it sounds. Business methods can simply access the ContextHolder and obtain the Authentication object. That way they can filter etc as they see fit. Advantages: simple, no infrastructure required, can change the returned object. Disadvantages: couples business code to Acegi, more difficult to test as there is limited separation of concerns (though you can write separate utility classes to help overcome this). VOTERS DETECT OBJECT AS PARAMETER AND QUERY EXISTING GrantedAuthority[]s. In this case you add custom GrantedAuthority[]s to the Authentication object during the original authentication process. Later the voter looks up those authorities and authorizes access to the domain instance accordingly. I'm presently using this approach in the Petclinic RCP sample (still being written, yet to be checked in). Advantages: simple, easy to test. Disadvantages: not scalable to thousands of instances, must customise the AuthenticationProvider (or AuthenticationDao if using DaoAuthenticationProvider), cannot change the returned object. VOTERS DETECT OBJECT AS PARAMETER AND OPEN ACTUAL INSTANCE. This is used in the Contacts sample application. A voter handles detecting a method invocation concerning an identity, opens the domain instance, calls a getter to obtain the ACL (access control list) information, and a comparison is made to the Authentication object. Advantages: fairly simple, easy to test. Disadvantages: opens a domain instance twice (in the voter and again in the business method), cannot change the returned object. VOTERS DETECT OBJECT AS PARAMETER AND QUERY ACL OBJECT. This would be a variation on the above option, but instead of opening the target domain instance twice, an ACL manager object would be consulted to obtain the instance-specific privileges. Advantages: highly decoupled from the domain objects, addresses performance issues, simple to test the parts, easily offers ACL inheritance, administration tools have a central reference point for all application ACL information. Disadvantages: getting complex, cannot change the returned object. MethodSecurityInterceptor CALLS A RESULT PROCESSOR. This would be done so that a list of classes can routinely be applied against the object returned from a method invocation. These classes could do things like Andy needs, such as obfuscate properties etc. If we went with the voter backed with an ACL manager approach on the way into the method invocation, these classes can easily determine which mutations they should perform on the returned object. The only requirement would be the classes should not throw an exception, as the business methods have already taken place. An issue is how mutated values would affect ORM if they were subsequently re-presented for committing. How do you handle this, Andy? Comments? Preferences? Best regards Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http
