David, Thank you for the review and comments. Replies inline:
1. the hierarchy of artifacts should not be static as you have described; what we care about for access control is how an artifact is used, not where it is statically located; for example we don't care if the AcctgTransEntry entity is part of the accounting component, but we do care if it is used by service X or in screen Y or in webapp Z; in other words, the hierarchical description for the context of a resource isn't static, it is built up at run-time as things are being executed; this is a big problem with the current security stuff, and something Andrew started to address but that wasn't fully fleshed out
Hmmm... I thought it would make more sense the static way - from an administrators perspective. The static method would make it easy to draw up an administration screen where an administrator could pick a user, pick an artifact, and then assign permissions to the artifact for that user.
It will be interesting to see how the dynamic way works out.
2. I don't like the idea of "User Group", "User Role" and "Policy"; it is confusing to have the multiple terms that mean slightly different things, and things that overlap in some ways with existing OFBiz concepts; I also don't think we need 2 levels of grouping between a user and what it has access to; in other words the current SecurityGroup that is used instead of referring directly to users is adequate as it takes care of not having to duplicate access control configuration for multiple users without adding too much complexity; I know this came from discussion in an email thread, but this seems to include every possible idea and try to make them fit together somehow instead of picking a single concept and making it work; in other words if someone is used to calling something a "role" or a "group" or a "policy" it won't make it any simpler if they get into the UI and all three are present and all three used in slightly different ways from what they are used to... the goal to make it easy for users of other systems to use it fails, and the goal to make it work well on its own also fails; hopefully this is okay, and I think so based on your comments in a blue info box about just using the User Groups (and hopefully I've expressed why I agree with that approach here)
I updated the page to suggest a single group as an alternative. But I'm going to push hard for the idea that groups can be members of groups. Maybe the implementation of that is a task I can tackle.
3. we should support services to check authorization and also support configuration of record-level permissions; in most cases these are really simple with just a view-entity that goes between the userLoginId or partyId and some other end-point, like a productId or a partyId, with specific constraints along the way (like a productCategoryI, productCategoryTypeId, roleTypeId, partyRelationshipTypeId, etc); for the most part I think we should try to eliminate the services that do permission checks and instead make it all configurable; also, if there is a service involved it should be referenced in the database-driven configuration and NOT in the artifact itself (again the goal is to get those out of the artifacts so that they are more readily and flexibly configurable)
I agree with you on the needs, and I thought I accommodated those needs in the design, but perhaps I didn't make it clear. The approach I proposed was to take the permission service declaration out of the service definition and make it an assignable permission.
In the design, there are three types of security checks you can assign to artifacts: 1. permission flags (the create, update, delete, etc like we have now), 2. permission services (like the ones we have now that check the user's relationship to data) that return access-granted or access-denied), and 3. filter services - where data sets are filtered based upon the user.
You can use the three types of security checks in any combination. I'm pretty sure that will accommodate most scenarios.
I'll continue to build out the design page as I have time. -Adrian
