Re: svn commit: r770084 - in /ofbiz/trunk/framework/example
Locked
1 ...
45678
1 ...
45678
 
|
Am I correct in thinking that artifact driven approach naturally integrates
the concept of allowing inherited permission checking by roles, but in the process-driven approach we would have to use something like the RoleCheckingDa API extension? So if I want to give an administrator access to all records in their district schools, but not to all records in the state, I would just have to attach that person (or their role?) to the district and it would all be handled, but in the process-driven case I would have to make a call to perform that check? -Al On Mon, May 4, 2009 at 12:35 AM, Adrian Crum <[hidden email]> 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 <[hidden email]> wrote: > > > From: Andrew Zeneski <[hidden email]> > > Subject: Re: Domain Based Security ( was re: Authz...) > > To: [hidden email] > > 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 > > <[hidden email]> 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 > > > > > > > > > > > > > > > > |
Re: Domain Based Security ( was re: Authz...)
|
|
I believe that no matter which method is used (process or artifact)
both would require similar access control logic to be implemented. I'm not sure how this would look in the artifact system (Adrian can comment on that), but in the process driven system there would be two options. 1. For simple checking a record against a role table (take ContentRole as an example for this discussion; note that content may or may not be considered a simple check, that has yet to be discussed/designed) you could define the process of update:content:data to use a common RoleCheckingDa extension and set the allowed role type values. This would remove the need for extra logic which would need to be implemented in simple circumstances. 2. Custom DA logic would be attached; in the case of the update:party:contact process, logic would be written to check first the owner of the party vs the user attempting to run the process, followed by checking to see if the user is an admin/owner of a group which the party to update is a member of. So to better answer your question, regardless of the type of system used, this sort of access control would be available and part of the application design. Based on what I have read so far, the artifact driven model would require this logic to be implemented in multiple places assuming you want the same control in multiple artifacts. Where as in a process driven architecture you would connect this logic to the process and then associate/check that process with multiple artifacts. Andrew On May 4, 2009, at 2:39 PM, Al Byers wrote: > Am I correct in thinking that artifact driven approach naturally > integrates > the concept of allowing inherited permission checking by roles, but > in the > process-driven approach we would have to use something like the > RoleCheckingDa API extension? So if I want to give an administrator > access > to all records in their district schools, but not to all records in > the > state, I would just have to attach that person (or their role?) to the > district and it would all be handled, but in the process-driven case > I would > have to make a call to perform that check? > > -Al > > > On Mon, May 4, 2009 at 12:35 AM, Adrian Crum <[hidden email]> > 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 <[hidden email]> >> wrote: >> >>> From: Andrew Zeneski <[hidden email]> >>> Subject: Re: Domain Based Security ( was re: Authz...) >>> To: [hidden email] >>> 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 >>> <[hidden email]> 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 >>>> >>>> >>>> >>>> >> >> >> >> |
Re: Domain Based Security ( was re: Authz...)
|
|
In reply to this post by byersa
In the artifact-driven approach, the inheritance is from higher level
artifacts to lower level artifacts. So if I assign a user permission to use a screen, that permission is inherited by all the artifacts the screen contains. Contained artifacts can optionally override the inherited permission. So, no - the inheritance is not in user roles. However, user role inheritance could be accommodated by the authentication mechanism. -Adrian Al Byers wrote: > Am I correct in thinking that artifact driven approach naturally integrates > the concept of allowing inherited permission checking by roles, but in the > process-driven approach we would have to use something like the > RoleCheckingDa API extension? So if I want to give an administrator access > to all records in their district schools, but not to all records in the > state, I would just have to attach that person (or their role?) to the > district and it would all be handled, but in the process-driven case I would > have to make a call to perform that check? > > -Al > > > On Mon, May 4, 2009 at 12:35 AM, Adrian Crum <[hidden email]> 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 <[hidden email]> wrote: >> >>> From: Andrew Zeneski <[hidden email]> >>> Subject: Re: Domain Based Security ( was re: Authz...) >>> To: [hidden email] >>> 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 >>> <[hidden email]> 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 >>>> >>>> >>>> >>>> >> >> >> > |
Re: Domain Based Security ( was re: Authz...)
|
|
We need to agree on terminology, authentication would refer to
confirming a subject is who they say they are (checking user's name/ password combination), where authorization would refer to granting access to something. What we having been discussing is re-designing the way ofbiz handles authorization. Authentication should be a completely different topic all together. On May 4, 2009, at 2:56 PM, Adrian Crum wrote: > So, no - the inheritance is not in user roles. However, user role > inheritance could be accommodated by the authentication mechanism. |
Re: Domain Based Security ( was re: Authz...)
|
|
Agreed!
-Adrian Andrew Zeneski wrote: > We need to agree on terminology, authentication would refer to > confirming a subject is who they say they are (checking user's > name/password combination), where authorization would refer to granting > access to something. > > What we having been discussing is re-designing the way ofbiz handles > authorization. Authentication should be a completely different topic all > together. > > On May 4, 2009, at 2:56 PM, Adrian Crum wrote: > >> So, no - the inheritance is not in user roles. However, user role >> inheritance could be accommodated by the authentication mechanism. > > |
Re: Domain Based Security ( was re: Authz...)
|
|
In reply to this post by Andrew Zeneski-2
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" <[hidden email]> To: [hidden email] Cc: "Anil Patel" <[hidden email]> 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/~jaz/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" <[hidden email]> > To: [hidden email] > Cc: "Anil Patel" <[hidden email]> > 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 <[hidden email]> >> wrote: >> >>> From: Andrew Zeneski <[hidden email]> >>> Subject: Re: Domain Based Security ( was re: Authz...) >>> To: [hidden email] >>> 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 >>> <[hidden email]> 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 >>>> >>>> >>>> >>>> >> >> >> > |
Re: Domain Based Security ( was re: Authz...)
|
|
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" <[hidden email]> > To: [hidden email] > Cc: "Anil Patel" <[hidden email]> > 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/~jaz/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" <[hidden email]> >> To: [hidden email] >> Cc: "Anil Patel" <[hidden email]> >> 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 <[hidden email]> >>> wrote: >>> >>>> From: Andrew Zeneski <[hidden email]> >>>> Subject: Re: Domain Based Security ( was re: Authz...) >>>> To: [hidden email] >>>> 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 >>>> <[hidden email]> 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 >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >> > |
Re: Domain Based Security ( was re: Authz...)
|
|
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 <[hidden email]>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" <[hidden email]> >> To: [hidden email] >> Cc: "Anil Patel" <[hidden email]> >> 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" <[hidden email]> >>> To: [hidden email] >>> Cc: "Anil Patel" <[hidden email]> >>> 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 <[hidden email]> >>>> wrote: >>>> >>>> From: Andrew Zeneski <[hidden email]> >>>>> Subject: Re: Domain Based Security ( was re: Authz...) >>>>> To: [hidden email] >>>>> 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 >>>>>> >>>>> <[hidden email]> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >> > |
Re: Domain Based Security ( was re: Authz...)
|
|
Harmeet Bedi wrote:
> Ofbiz has the graph metadata of artifacts but navigating graph to > dynamically determine will be expensive. It doesn't have to be. If we end up using the artifact info stuff for some kind of security administration screen, we can set up the artifact gathering code to go only as deep as what is currently being displayed. In other words, the artifact gathering could be more dynamic. As the user navigates farther down the graph, additional parsing is done. This would eliminate the need to graph all artifacts in one step. I agree with David that storing the graph in the database is a bad idea. -Adrian |
Re: Domain Based Security ( was re: Authz...)
|
|
In reply to this post by Andrew Zeneski-2
If goal is to change security without changing code or XML configuration.. the configuration has to reside somewhere. db seemed like a spot.
UI would needs to show the artifacts and permission and configure groups on them. I had SecurityPermission entity extended to have SecurityResource(Artifact) and SecurityActionType(e.g. access) If the issue is that should there be no static check and collect resources to seed db, instead to it dynamically it would be fine. It would make things dynamic and configuration friendly while still taking config out of xml. Harmeet ----- Original Message ----- From: "Adrian Crum" <[hidden email]> To: [hidden email] Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern Subject: Re: Domain Based Security ( was re: Authz...) Harmeet Bedi wrote: > Ofbiz has the graph metadata of artifacts but navigating graph to > dynamically determine will be expensive. It doesn't have to be. If we end up using the artifact info stuff for some kind of security administration screen, we can set up the artifact gathering code to go only as deep as what is currently being displayed. In other words, the artifact gathering could be more dynamic. As the user navigates farther down the graph, additional parsing is done. This would eliminate the need to graph all artifacts in one step. I agree with David that storing the graph in the database is a bad idea. -Adrian |
Re: Domain Based Security ( was re: Authz...)
|
|
In the design I proposed, the configuration resides in the artifacts
themselves. -Adrian Harmeet Bedi wrote: > If goal is to change security without changing code or XML configuration.. the configuration has to reside somewhere. db seemed like a spot. > UI would needs to show the artifacts and permission and configure groups on them. > I had SecurityPermission entity extended to have SecurityResource(Artifact) and SecurityActionType(e.g. access) > > If the issue is that should there be no static check and collect resources to seed db, instead to it dynamically it would be fine. It would make things dynamic and configuration friendly while still taking config out of xml. > > Harmeet > ----- Original Message ----- > From: "Adrian Crum" <[hidden email]> > To: [hidden email] > Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern > Subject: Re: Domain Based Security ( was re: Authz...) > > Harmeet Bedi wrote: >> Ofbiz has the graph metadata of artifacts but navigating graph to >> dynamically determine will be expensive. > > It doesn't have to be. If we end up using the artifact info stuff for > some kind of security administration screen, we can set up the artifact > gathering code to go only as deep as what is currently being displayed. > In other words, the artifact gathering could be more dynamic. As the > user navigates farther down the graph, additional parsing is done. > > This would eliminate the need to graph all artifacts in one step. > > I agree with David that storing the graph in the database is a bad idea. > > -Adrian > |
Re: Domain Based Security ( was re: Authz...)
|
|
To me this sounds like the security information is being spread out in
ever more places, not consolidated. If I need to customize the authorization logic, I would much rather it be centralized and NOT in the artifacts. If it was in the artifacts, much like it is today, then customizing would require modifications to the OOTB artifacts. Which is exactly what we should be avoiding. Andrew On May 5, 2009, at 11:42 AM, Adrian Crum wrote: > In the design I proposed, the configuration resides in the artifacts > themselves. > > -Adrian > > Harmeet Bedi wrote: >> If goal is to change security without changing code or XML >> configuration.. the configuration has to reside somewhere. db >> seemed like a spot. >> UI would needs to show the artifacts and permission and configure >> groups on them. >> I had SecurityPermission entity extended to have >> SecurityResource(Artifact) and SecurityActionType(e.g. access) >> If the issue is that should there be no static check and collect >> resources to seed db, instead to it dynamically it would be fine. >> It would make things dynamic and configuration friendly while still >> taking config out of xml. >> Harmeet >> ----- Original Message ----- >> From: "Adrian Crum" <[hidden email]> >> To: [hidden email] >> Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern >> Subject: Re: Domain Based Security ( was re: Authz...) >> Harmeet Bedi wrote: >>> Ofbiz has the graph metadata of artifacts but navigating graph to >>> dynamically determine will be expensive. >> It doesn't have to be. If we end up using the artifact info stuff >> for some kind of security administration screen, we can set up the >> artifact gathering code to go only as deep as what is currently >> being displayed. In other words, the artifact gathering could be >> more dynamic. As the user navigates farther down the graph, >> additional parsing is done. >> This would eliminate the need to graph all artifacts in one step. >> I agree with David that storing the graph in the database is a bad >> idea. >> -Adrian |
Re: Domain Based Security ( was re: Authz...)
|
|
I'm working on a design document, and when it is finished I will make it
available. When you review it, you will understand better how the design works. -Adrian Andrew Zeneski wrote: > To me this sounds like the security information is being spread out in > ever more places, not consolidated. If I need to customize the > authorization logic, I would much rather it be centralized and NOT in > the artifacts. If it was in the artifacts, much like it is today, then > customizing would require modifications to the OOTB artifacts. Which is > exactly what we should be avoiding. > > Andrew > > On May 5, 2009, at 11:42 AM, Adrian Crum wrote: > >> In the design I proposed, the configuration resides in the artifacts >> themselves. >> >> -Adrian >> >> Harmeet Bedi wrote: >>> If goal is to change security without changing code or XML >>> configuration.. the configuration has to reside somewhere. db seemed >>> like a spot. >>> UI would needs to show the artifacts and permission and configure >>> groups on them. >>> I had SecurityPermission entity extended to have >>> SecurityResource(Artifact) and SecurityActionType(e.g. access) >>> If the issue is that should there be no static check and collect >>> resources to seed db, instead to it dynamically it would be fine. It >>> would make things dynamic and configuration friendly while still >>> taking config out of xml. >>> Harmeet >>> ----- Original Message ----- >>> From: "Adrian Crum" <[hidden email]> >>> To: [hidden email] >>> Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern >>> Subject: Re: Domain Based Security ( was re: Authz...) >>> Harmeet Bedi wrote: >>>> Ofbiz has the graph metadata of artifacts but navigating graph to >>>> dynamically determine will be expensive. >>> It doesn't have to be. If we end up using the artifact info stuff for >>> some kind of security administration screen, we can set up the >>> artifact gathering code to go only as deep as what is currently being >>> displayed. In other words, the artifact gathering could be more >>> dynamic. As the user navigates farther down the graph, additional >>> parsing is done. >>> This would eliminate the need to graph all artifacts in one step. >>> I agree with David that storing the graph in the database is a bad idea. >>> -Adrian > > |
Re: Domain Based Security ( was re: Authz...)
|
|
In reply to this post by Andrew Zeneski-2
Adrian,
While this is fine when a artifact handles a specific "process" but what about when a screen (for example) like EditExample would be used for different processes? Often the same screen/form is used for create vs update; and even more often a user will have access to create but not update [everything]. Also, an artifact (such as a screen) could contain multiple processes. A list screen for example may also include a delete button. However, with no explicit permission checks, the delete button will display for all users who have access to this artifact. So, you would still need to have explicit permission checks to see if the user has access to the delete button in this artifact. Andrew >> Permissions are hierarchical - each artifact inherits permissions >> from the artifact above it. This is very similar to what Andrew is >> trying to achieve, but it's different because the artifacts >> themselves control the security - there is no call to a permission >> service with a permission string. >> >> Here's what it might look like in ExampleScreens.xml: >> >> <screens xmlns:xsi="..."> >> <security domain="framework:example:screen"/> >> >> <screen name="EditExample"> >> <security domain="EditExample"/> >> ... >> </screen> >> >> </screens> >> >> Notice there are no explicit permission checks. Instead, each >> artifact has identified itself in the security domain. > |
Re: Domain Based Security ( was re: Authz...)
|
|
I should also note that in the process based system I have been
talking about we can easily follow similar patterns Adrian has recommended. Service artifacts are one thing, as they usually only relate to a single process. But in screens and other artifacts we could "register" them with a process: <screen ...> <security process="party:contact" check="update/> </screen> This would populate a list of permissions available to the current user for the process within that artifact and require the user to be able to update in order for the screen to render. Then if we were displaying a delete button another check could be run <security check="delete"> to see if the delete button should be rendered. This is technically no different than doing has-permission checks, just doing so in a different XML format and instead of calling has- permission many times it just gathers all permissions at once and then permission checking is just handled from the screen's context. I never even considered such a thing when I started working on the process based designs because I was taking ease of migration into consideration. Changing from plain permission checks to a more process based permission string was large enough. However, my point is that if we are considering ways to change all the artifacts in OFBiz and how they deal with security it can be done with either of the two proposals. With the process based designs it could just be done at a later time. Andrew On May 5, 2009, at 2:04 PM, Andrew Zeneski wrote: > Adrian, > > While this is fine when a artifact handles a specific "process" but > what about when a screen (for example) like EditExample would be > used for different processes? Often the same screen/form is used for > create vs update; and even more often a user will have access to > create but not update [everything]. > > Also, an artifact (such as a screen) could contain multiple > processes. A list screen for example may also include a delete > button. However, with no explicit permission checks, the delete > button will display for all users who have access to this artifact. > So, you would still need to have explicit permission checks to see > if the user has access to the delete button in this artifact. > > Andrew > >>> Permissions are hierarchical - each artifact inherits permissions >>> from the artifact above it. This is very similar to what Andrew is >>> trying to achieve, but it's different because the artifacts >>> themselves control the security - there is no call to a permission >>> service with a permission string. >>> >>> Here's what it might look like in ExampleScreens.xml: >>> >>> <screens xmlns:xsi="..."> >>> <security domain="framework:example:screen"/> >>> >>> <screen name="EditExample"> >>> <security domain="EditExample"/> >>> ... >>> </screen> >>> >>> </screens> >>> >>> Notice there are no explicit permission checks. Instead, each >>> artifact has identified itself in the security domain. >> > |
Re: Domain Based Security ( was re: Authz...)
|
|
Andrew Zeneski wrote:
> I never even considered such a thing when I started working on the > process based designs because I was taking ease of migration into > consideration. Changing from plain permission checks to a more process > based permission string was large enough. However, my point is that if > we are considering ways to change all the artifacts in OFBiz and how > they deal with security it can be done with either of the two proposals. I think the current feeling is, a completely different approach would be acceptable if there is significant advantage to it. And if we do settle on something completely different, then a migration service would be mandatory. -Adrian |
Re: Domain Based Security ( was re: Authz...)
|
|
In reply to this post by Harmeet Bedi
The configuration of permissions/etc would be in the database, but the point is that we don't need (or want) records for each artifact in the database. With the ArtifactInfo stuff we can get all artifact data, and then refer to those by their location and/or name. During execution the various framework tools only need to see if the artifact they are running has permissions associated with them, and it would look them up by these very things, ie the location and/or name (depending on the artifact). -David On May 5, 2009, at 9:21 AM, Harmeet Bedi wrote: > If goal is to change security without changing code or XML > configuration.. the configuration has to reside somewhere. db seemed > like a spot. > UI would needs to show the artifacts and permission and configure > groups on them. > I had SecurityPermission entity extended to have > SecurityResource(Artifact) and SecurityActionType(e.g. access) > > If the issue is that should there be no static check and collect > resources to seed db, instead to it dynamically it would be fine. It > would make things dynamic and configuration friendly while still > taking config out of xml. > > Harmeet > ----- Original Message ----- > From: "Adrian Crum" <[hidden email]> > To: [hidden email] > Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern > Subject: Re: Domain Based Security ( was re: Authz...) > > Harmeet Bedi wrote: >> Ofbiz has the graph metadata of artifacts but navigating graph to >> dynamically determine will be expensive. > > It doesn't have to be. If we end up using the artifact info stuff for > some kind of security administration screen, we can set up the > artifact > gathering code to go only as deep as what is currently being > displayed. > In other words, the artifact gathering could be more dynamic. As the > user navigates farther down the graph, additional parsing is done. > > This would eliminate the need to graph all artifacts in one step. > > I agree with David that storing the graph in the database is a bad > idea. > > -Adrian |
Re: Domain Based Security ( was re: Authz...)
|
|
In reply to this post by Andrew Zeneski-2
Exactly, I like this direction a lot better too... ie don't have the permissions in the artifacts but have them all in a separate place that refers back to the artifacts (and other things) as needed. With it outside the artifacts and centralized in database driven configuration, it would be a LOT easier for end-users to have control and configure things in a wide variety of ways, without needing a programmer and without changing any XML, Java, groovy or anything. -David On May 5, 2009, at 11:43 AM, Andrew Zeneski wrote: > To me this sounds like the security information is being spread out > in ever more places, not consolidated. If I need to customize the > authorization logic, I would much rather it be centralized and NOT > in the artifacts. If it was in the artifacts, much like it is today, > then customizing would require modifications to the OOTB artifacts. > Which is exactly what we should be avoiding. > > Andrew > > On May 5, 2009, at 11:42 AM, Adrian Crum wrote: > >> In the design I proposed, the configuration resides in the >> artifacts themselves. >> >> -Adrian >> >> Harmeet Bedi wrote: >>> If goal is to change security without changing code or XML >>> configuration.. the configuration has to reside somewhere. db >>> seemed like a spot. >>> UI would needs to show the artifacts and permission and configure >>> groups on them. >>> I had SecurityPermission entity extended to have >>> SecurityResource(Artifact) and SecurityActionType(e.g. access) >>> If the issue is that should there be no static check and collect >>> resources to seed db, instead to it dynamically it would be fine. >>> It would make things dynamic and configuration friendly while >>> still taking config out of xml. >>> Harmeet >>> ----- Original Message ----- >>> From: "Adrian Crum" <[hidden email]> >>> To: [hidden email] >>> Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern >>> Subject: Re: Domain Based Security ( was re: Authz...) >>> Harmeet Bedi wrote: >>>> Ofbiz has the graph metadata of artifacts but navigating graph to >>>> dynamically determine will be expensive. >>> It doesn't have to be. If we end up using the artifact info stuff >>> for some kind of security administration screen, we can set up the >>> artifact gathering code to go only as deep as what is currently >>> being displayed. In other words, the artifact gathering could be >>> more dynamic. As the user navigates farther down the graph, >>> additional parsing is done. >>> This would eliminate the need to graph all artifacts in one step. >>> I agree with David that storing the graph in the database is a bad >>> idea. >>> -Adrian > |
Re: Domain Based Security ( was re: Authz...)
|
|
Well, this is starting to sound exactly like what I proposed, with the
exception that in my proposal everything would be tied to a "process" rather than an artifact. The process of "updating a party record" is attached to the artifacts which are involved in the process, then permission logic is attached (by database configuration) to that very same process. To me a process driven model is far more comprehendible to an average application administrator, where an artifact based would be way more technical. An administrator would need to understand all the artifacts in the application in order to configure things properly. Where in a process model, the admin only needs to understand the process involved and the artifacts are associated to the process during development. Defining the processes involved in an application is something which should be done during design. During implementation, all that needs to be addressed is associating the artifacts to the correct process. In my opinion security should be thought of as a business level requirement, putting it on the artifact is too technical. Andrew On May 5, 2009, at 3:59 PM, David E Jones wrote: > > Exactly, I like this direction a lot better too... ie don't have the > permissions in the artifacts but have them all in a separate place > that refers back to the artifacts (and other things) as needed. > > With it outside the artifacts and centralized in database driven > configuration, it would be a LOT easier for end-users to have > control and configure things in a wide variety of ways, without > needing a programmer and without changing any XML, Java, groovy or > anything. > > -David > > > On May 5, 2009, at 11:43 AM, Andrew Zeneski wrote: > >> To me this sounds like the security information is being spread out >> in ever more places, not consolidated. If I need to customize the >> authorization logic, I would much rather it be centralized and NOT >> in the artifacts. If it was in the artifacts, much like it is >> today, then customizing would require modifications to the OOTB >> artifacts. Which is exactly what we should be avoiding. >> >> Andrew >> >> On May 5, 2009, at 11:42 AM, Adrian Crum wrote: >> >>> In the design I proposed, the configuration resides in the >>> artifacts themselves. >>> >>> -Adrian >>> >>> Harmeet Bedi wrote: >>>> If goal is to change security without changing code or XML >>>> configuration.. the configuration has to reside somewhere. db >>>> seemed like a spot. >>>> UI would needs to show the artifacts and permission and configure >>>> groups on them. >>>> I had SecurityPermission entity extended to have >>>> SecurityResource(Artifact) and SecurityActionType(e.g. access) >>>> If the issue is that should there be no static check and collect >>>> resources to seed db, instead to it dynamically it would be fine. >>>> It would make things dynamic and configuration friendly while >>>> still taking config out of xml. >>>> Harmeet >>>> ----- Original Message ----- >>>> From: "Adrian Crum" <[hidden email]> >>>> To: [hidden email] >>>> Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern >>>> Subject: Re: Domain Based Security ( was re: Authz...) >>>> Harmeet Bedi wrote: >>>>> Ofbiz has the graph metadata of artifacts but navigating graph to >>>>> dynamically determine will be expensive. >>>> It doesn't have to be. If we end up using the artifact info stuff >>>> for some kind of security administration screen, we can set up >>>> the artifact gathering code to go only as deep as what is >>>> currently being displayed. In other words, the artifact gathering >>>> could be more dynamic. As the user navigates farther down the >>>> graph, additional parsing is done. >>>> This would eliminate the need to graph all artifacts in one step. >>>> I agree with David that storing the graph in the database is a >>>> bad idea. >>>> -Adrian >> > |
Re: Domain Based Security ( was re: Authz...)
|
|
Andrew Zeneski wrote:
> To me a process driven model is far more comprehendible to an average > application administrator, where an artifact based would be way more > technical. An administrator would need to understand all the artifacts > in the application in order to configure things properly. Where in a > process model, the admin only needs to understand the process involved > and the artifacts are associated to the process during development. That's a very good point. The design I proposed was based on network administration - where every network resource can have permissions attached to it and there is a great level of control. So yes, it is technical. -Adrian |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |