This true. But to reuse db connection we use a pool, so we connect to the DB with one user, and reuse that connection. Based on that, I don't see how can we configure the DB to do so. And configurations wouldn't be portable. So if I am working on some client code, and configured these ACL rules with derby, then when deployed to production, I have to find a way to configure MySql DB to do these rules.
We do this already by checking permissions in the services: <if-has-permission permission="ORDERMGR" action="_VIEW"/> But this is just another way to apply this on the whole entities. This doesn't always work as expected. For example, the project manager component, shows projects that the user doesn't belong to, and should not see. /org/ofbiz/project/ProjectPermissionServices.xml: <not><if-has-permission permission="PROJECTMGR_ROLE_VIEW"/></not> The solution comes with ofbiz, is ProjectPermissionServices, which is fine, but for each application needs a different set of security rules, and may implement its own security services to provide some set of this rules. What is the reason of creating a security services script for each component. Keep in mind that most of these permissions applies to the screen engine, or to the services. If we want to do a record level security we need to bring the whole set of records from the DB, Then iterate over them to see which one we are allowed to access for the current user. Adding it into the delegator will make this transparent to application users. The user need to edit acl.xml to reflect security on entities. IMO your point is separation of concerns. Something like "Let the delegator do the data access, and services select what data it needs". And I agree about this, but from different perspective, we can say "this is the data available for this user". and therefore it's part of the business rules. Not sure if my point is clear here. The concept has been done with different database access technology, like JPA http://jpasecurity.sourceforge.net/ After all, I see your point, and I will reconsider this option and give it another thought. For now, we agree on the need to refactor Delegator, and we are looking for a plan to minimize the risk involved. What are you thoughts ? On Tue, Mar 27, 2012 at 9:48 AM, Adrian Crum <[email protected]> wrote: > On 3/27/2012 2:41 PM, Mansour Al Akeel wrote: >> >> Thank you Adrian. >> I don't think a lot of developers will see an immediate gain. But in >> the long run, it will be appreciated. >> It allows us to introduce new functionality. >> >> For example, in one of my previous emails, I pointed out the need >> for a Record Level Security, like the one offered by Oracle DB and >> recently by postgresql. Where the loged in user >> have specific access to the data. The same principal, is used in most >> NoSQL data bases. >> My plan was to have an xml config file next to the entities (ie, >> acl.xml), and restrict access based to entities I need. >> The whole idea is, to appends some query parameters to calls to DB, >> giving the application programmer a nice and >> clean way to work with records. > > > If you want to restrict access to data based on a user login, then the > access control should be configured in the database - not in XML files. I am > not convinced that the type of security you describe should be handled by > the delegator. In most cases, that type of access control is included in a > broader set of business rules - so it should be implemented in services. > > -Adrian >
