regd: > we wouldn't try to mine all of the existing artifacts and create data in the database for each
We wanted to have 2 things. 1. In UI a way that the admin would be able to see all resources and be able to set security groups. 2. If there was a protected resource pointers to it would change. e.g. if screen is not accessible, the menu or hyperlink types would not show up in user interface. Similarily if a user does not have access to a screen, the unique services referenced by screen are not accessible. Ofbiz has the graph metadata of artifacts but navigating graph to dynamically determine will be expensive. One approach could be dynamically calculating and store in db or cache would be nice. So overhead is limited to one time graph navigation and works for n app to 1 db server. We have not yet implemented static analysis but we lazily build the set of resources/artifacts on actual access. This makes system dyanmic. Professional service person can customize to add new artificats and they will show up in db. The main motivation behind static analysis was (1). We will have to walk all the artifacts to determine the UI. This could be done in hybrid approach.. but we will have to walk the graph.. in any case ie. do static analysis. I think (1) should be a requirement for security as it makes it easier to administer. Harmeet On Mon, May 4, 2009 at 9:04 PM, David E Jones <[email protected]>wrote: > > Thanks for sharing this Harmeet. I've started a couple of threads about > brainstorming, and this sounds a lot like the option #4 for the Security > Configuration Patterns. > > A few people have mentioned over time that they'd like to change security > without changing code (or XML configuration, etc)... and I think that's a > very reasonable and possible thing. As I've been thinking about it over time > my opinion is that this is the best approach, ie that we remove all > permission checking code and configuration from the screens, services, etc > and refer to them externally. > > One small difference in what I've been laying out recently: we wouldn't try > to mine all of the existing artifacts and create data in the database for > each. They exist in files and OFBiz knows all about them (especially through > the ArtifactInfo stuff this is pretty easy now), so we can just refer to > artifacts externally and not worry about the redundancy and likely > inconsistency if we created database records for each. > > -David > > > > On May 4, 2009, at 4:05 PM, Harmeet Bedi wrote: > > Security permission seems to be based on action, resource and context of >> resource. >> >> I have been working on system to extending ofbiz security for our custom >> system. >> A main difference is that we wanted to get away from has-permission >> constructs in the xml files. Hope was that end users would be able to create >> new groups, edit membership, associate resource and action with a set of >> groups through UI and manipulating database tables. The extension we were >> thinking of is add to SecurityPermission Resource and Action information >> >> >> SecurityPermission references SecurityActionType(new) >> SecurityPermission references SecurityResource(new) >> SecurityResource references SecurityResourceType(new) >> >> <extend-entity entity-name="SecurityPermission"> >> <field name="resourceId" type="id-ne"></field> >> <field name="actionTypeId" type="id-ne"></field> >> </extend-entity> >> >> <entity entity-name="SecurityActionType" title="Security Action Type"> >> <field name="actionTypeId" type="id-ne"></field> >> <field name="parentTypeId" type="id-ne"></field> >> <field name="hasTable" type="indicator"></field> >> <field name="description" type="description"></field> >> </entity> >> >> <entity entity-name="SecurityResource" title="Security Resource"> >> <field name="resourceId" type="id-ne"></field> >> <field name="parentId" type="id-ne"></field> >> <field name="resourceTypeId" type="id-long"></field> >> <field name="application" type="name"></field> >> <field name="resourceName" type="name"></field> >> <field name="fullPath" type="long-varchar"></field> >> <field name="description" type="description"></field> >> </entity> >> >> <entity entity-name="SecurityResourceType" title="Security Resource >> Type"> >> <field name="resourceTypeId" type="id-long"></field> >> <field name="parentTypeId" type="id-long"></field> >> <field name="hasTable" type="indicator"></field> >> <field name="description" type="description"></field> >> </entity> >> >> >> SecurityResourceType is types derived from ModelWidget (screens, forms, >> screelets, hyperlink etc.), Entries(Request Map) in controller.xml, db >> entities, services etc. >> >> >> Changed ModelWidget to put in hooks for access control >> >> public abstract class ModelWidget<R extends ModelWidgetRenderer> >> implements Serializable { >> ... >> /** >> * renders widget. Writes render output to writer. >> * Applies access control and calls abstract renderWidget method if >> allowed to render >> * @param writer target for rendering >> * @param context context used by widget to render itself. >> * @param renderer renderer specific to derived class >> */ >> public final void render(final Appendable writer, final Map<String, >> Object> context, final R renderer) >> throws GeneralException, IOException >> { >> .... >> } >> >> /** >> * called after acl check is done and widget can be rendered. Derived >> classes need to implement this method >> */ >> protected abstract void renderWidget(Appendable writer, Map<String, >> Object> context, R renderer) >> throws GeneralException, IOException; >> ... >> } >> >> ModelScreen::renderScreenString changed to ModelScreen::renderWidget >> >> ModelScreen has this: >> >> public class ModelScreen extends ModelWidget<ScreenStringRenderer> >> implements Serializable { >> .. >> @Override >> protected void renderWidget(Appendable writer, Map<String, Object> >> context, ScreenStringRenderer screenStringRenderer) >> throws ScreenRenderException { ... } >> } >> >> >> The net result is that to secure access(action type) for a >> screen(resource) we can add entry in db for the resource and a unique >> permission id for resource and action(intent something like access:ap:report >> in doc). Intent is to build this list by statically examining the xml >> files(*Screens.xml, controller.xml etc) to build database seed. >> >> The way we were thinking of configuring was that each resource(page -> top >> level screen) has a link to manage access groups based on logged in users' >> permission. Clicking on link shows list of groups and update mechanism to >> associate security groups with action+resource using standard >> SecurityGroupPermission table >> >> >> This seems to have some overlap with proposals in this thread. >> We are based on an older ofbiz fork, but would like to contribute if there >> is interest. >> >> Harmeet >> >> >> >> >> ----- Original Message ----- >> From: "Anil Patel" <[email protected]> >> To: [email protected] >> Cc: "Anil Patel" <[email protected]> >> Sent: Monday, May 4, 2009 9:19:21 AM GMT -05:00 US/Canada Eastern >> Subject: Re: Domain Based Security ( was re: Authz...) >> >> Vince, >> Here are the documents >> >> http://docs.ofbiz.org/display/~jaz/OFBiz+Security+Refactor<http://docs.ofbiz.org/display/%7Ejaz/OFBiz+Security+Refactor> >> http://docs.ofbiz.org/display/~jaz/Permissions+By+Application<http://docs.ofbiz.org/display/%7Ejaz/Permissions+By+Application> >> >> Thanks for asking for the document. I have example on "How successful >> people been in confusing the community". >> >> Regards >> Anil Patel >> >> >> On May 4, 2009, at 9:11 AM, Vince Clark wrote: >> >> Anil, you mentioned a document. Can you send out the link? I'm sure >>> it is in these threads somewhere but with all the traffic on this >>> topic I cannot seem to find a link to the doc. >>> >>> ----- Original Message ----- >>> From: "Anil Patel" <[email protected]> >>> To: [email protected] >>> Cc: "Anil Patel" <[email protected]> >>> Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain >>> Subject: Re: Domain Based Security ( was re: Authz...) >>> >>> Over last few days this discussion has changed subject few times. This >>> is going more on lines of "confuse them if you cannot convenience". >>> >>> The new security system proposal document, implementation code and >>> code demonstrating its use, been out for more then week, All big names >>> in community have had chance to see it. I will rather discuss on list >>> of items that are so bad about new security system (which is now in >>> proposal status). If Andrew or others who like it cannot solve or >>> disprove them then either we will know that its bad and cannot be >>> used. >>> >>> I like the system and will like to use it. >>> >>> Regards >>> Anil Patel >>> >>> >>> On May 4, 2009, at 2:35 AM, Adrian Crum wrote: >>> >>> >>>> I don't see us agreeing on anything. I'm saying each artifact is >>>> responsible for its own security. You're saying security is defined >>>> by a process. >>>> >>>> If you were to view a collection of artifacts - each responsible for >>>> its own security - defining some kind of process-driven security, >>>> then that might be true. >>>> >>>> Applying your process-driven security design to the picture analogy >>>> (from what I have gathered so far from your design), it would be >>>> like there is a gatekeeper at the entrance to the picture. The >>>> gatekeeper says "Adrian intends to start the car, does he have >>>> permission to do that?" The car has no say in the matter. The >>>> gatekeeper controls everything. >>>> >>>> The inherent limitation to that design is, the gatekeeper has to >>>> account for every motive I might have in interacting with every >>>> artifact in the picture. That gatekeeper has a lot on its hands! >>>> >>>> I think it is simpler to have each artifact decide for itself what >>>> Adrian can or cannot do with it. I believe that was what David was >>>> trying to express when he said "it's the artifact we want the code >>>> attached to not the permission itself." >>>> >>>> -Adrian >>>> >>>> >>>> --- On Sun, 5/3/09, Andrew Zeneski <[email protected]> >>>> wrote: >>>> >>>> From: Andrew Zeneski <[email protected]> >>>>> Subject: Re: Domain Based Security ( was re: Authz...) >>>>> To: [email protected] >>>>> Date: Sunday, May 3, 2009, 11:00 PM >>>>> I like to think of it more as process-driven permission vs >>>>> artifact driven permissions, because the "permission >>>>> string" is defined to match a specific process. Other >>>>> than that I think we finally agreed on something.. Ha! :) >>>>> >>>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote: >>>>> >>>>> >>>>>> --- On Sun, 5/3/09, Andrew Zeneski >>>>>> >>>>> <[email protected]> wrote: >>>>> >>>>>> The question I believe now is, which is better? I >>>>>>> personally think in terms of processes which is >>>>>>> >>>>>> why what I >>>>> >>>>>> proposed was all process based. However, artifact >>>>>>> >>>>>> based may >>>>> >>>>>> be more granular, but possibly too granular. If I >>>>>>> >>>>>> understand >>>>> >>>>>> this right, artifact based we could potentially >>>>>>> >>>>>> have >>>>> >>>>>> different access requirements for every single >>>>>>> form/screen/service/entity/etc; where in a process >>>>>>> >>>>>> based >>>>> >>>>>> system the developer would define the processes as >>>>>>> >>>>>> part of >>>>> >>>>>> the application and these processes could be >>>>>>> >>>>>> shared across >>>>> >>>>>> common artifacts (forms can share with screens >>>>>>> >>>>>> that share >>>>> >>>>>> with services, etc). >>>>>>> >>>>>>> Does this sound like a fair assessment? >>>>>>> >>>>>> >>>>>> Yes it is. It boils down to permission-driven >>>>>> >>>>> permissions, versus artifact-driven permissions. >>>>> >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >> >
