Re: Domain Based Security ( was re: Authz...)
David E Jones wrote: In the design I'm working on, permissions can be granted to any artifact that has a security element. Artifacts that don't have a security element inherit permissions from artifacts higher up in the hierarchy that do have a security element. This eliminates having to name *everything* and instead you just name important security points. What if a user finds their own "important security points" that we have not already setup? Actually, I would argue that over time with enough use nearly every screen, form, form field, service, and perhaps other things would be designated as security points. Why not just default to having anything and everything being a potential security point and use tools and conventions to make it easier to handle... but still totally flexible to configure externally (ie without changing the code or configuration files, and without restarting the system). Those are good points. I'll update my document. -Adrian
Re: Domain Based Security ( was re: Authz...)
On May 6, 2009, at 11:07 AM, Adrian Crum wrote: David E Jones wrote: What I'm leaning towards above would be kind of like the auto-grant stuff if there was one permission for each artifact. The idea is to default to the level of full granularity (each artifact's name being the permission) and then make sure we have tools and conventions to make it easy (and even possible!) to deal with them. In the design I'm working on, permissions can be granted to any artifact that has a security element. Artifacts that don't have a security element inherit permissions from artifacts higher up in the hierarchy that do have a security element. This eliminates having to name *everything* and instead you just name important security points. What if a user finds their own "important security points" that we have not already setup? Actually, I would argue that over time with enough use nearly every screen, form, form field, service, and perhaps other things would be designated as security points. Why not just default to having anything and everything being a potential security point and use tools and conventions to make it easier to handle... but still totally flexible to configure externally (ie without changing the code or configuration files, and without restarting the system). The security element has an identifier attribute that is used to identify the artifact. I thought it would be simpler to just use the artifact's name, but not all artifacts have names. Then there is the case where an artifact might have a name, but it wouldn't make any sense to an administrator, or it could be better described for an administrator. (One example that Andrew pointed out is the EditExample screen. It is used for creating and editing Examples. So, from a security administration standpoint, CreateOrEditExample would be a better name.) Plus, it would be helpful to format artifact names in an authorization service friendly way. Is it really worth all the effort to do so? Consider that one of the nice things about using the actual/natural names and locations is that for the most part we have been consistent in naming things so that from the request name (in a URL) you can easily lookup screens and forms and things, although the worst case scenario is that they have to find the actual request in the ArtifactInfo stuff and then trace down to the artifact they are looking for. In general I am very against assigning additional and artificial names to things... it just creates a level of confusion because people see things referred to by different names and it's hard for experienced people to keep track of which is which and what it's for... for more casual users I suspect it would be a constant problem. Also, which artifacts don't have any sort of name or identifier (sorry, I can't think of any right now...)? About EditExample, it could be "CreateOrUpdateExample" but the point of using the word "Edit" was to avoid using the term "Create" or "Update" and not imply that it was exclusive to one or the other. In the case where a service calls other services, the called services inherit the permissions of the original service call. Yes, we can certainly have rules like this that help us deal with the large number of artifacts. -David
Re: Domain Based Security ( was re: Authz...)
David E Jones wrote: What I'm leaning towards above would be kind of like the auto-grant stuff if there was one permission for each artifact. The idea is to default to the level of full granularity (each artifact's name being the permission) and then make sure we have tools and conventions to make it easy (and even possible!) to deal with them. In the design I'm working on, permissions can be granted to any artifact that has a security element. Artifacts that don't have a security element inherit permissions from artifacts higher up in the hierarchy that do have a security element. This eliminates having to name *everything* and instead you just name important security points. The security element has an identifier attribute that is used to identify the artifact. I thought it would be simpler to just use the artifact's name, but not all artifacts have names. Then there is the case where an artifact might have a name, but it wouldn't make any sense to an administrator, or it could be better described for an administrator. (One example that Andrew pointed out is the EditExample screen. It is used for creating and editing Examples. So, from a security administration standpoint, CreateOrEditExample would be a better name.) Plus, it would be helpful to format artifact names in an authorization service friendly way. In the case where a service calls other services, the called services inherit the permissions of the original service call. -Adrian
Re: Domain Based Security ( was re: Authz...)
This seems a good idea to me. And we could even has it in the current artifact info screen to speed and focus the (1st) mining process. I also agree that having things statically in DB is not an option, at least for OFBiz OOTB. Jacques From: "Adrian Crum" 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...)
在 2009-05-05二的 11:21 -0400，Harmeet Bedi写道： > If goal is to change security without changing code or XML configuration.. > the configuration has to reside somewhere. db seemed like a spot. I think it's convenient during developing to set the securities in XML configuration and override DB data when every restart. When deploying in production environment, the configuration can be changed to keep DB data unchanged when restart. This is what JBoss Portal does.
Re: Domain Based Security ( was re: Authz...)
On May 5, 2009, at 4:57 PM, Andrew Zeneski wrote: On May 5, 2009, at 5:24 PM, David E Jones wrote: 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. I'm not sure what you mean by this... which proposal are you referring to? If it is the main one you documented and implemented I think there are some big differences here, mainly that the artifacts themselves do not have anything in them for configuring access control (permissions, etc), not even specifying a "process" that they are part of, and instead the external stuff where access control is configured refers to the artifacts. Yes, the same proposal I have been talking about from the beginning. While you are correct that the current implementation and proposal does not have a specific method of "registering" artifacts with the process, instead it is using the current patterns to check access to for the process within the artifact. In the end, this is all exactly the same thing, registering an artifact and adding authorization logic to the artifact's framework or calling the same functionality from within the artifact is all really just a matter of aesthetics. So, this is something which could be added to any system which is developed. Yeah, they can both serve the same purpose. What I'm thinking is that for end users it will be a lot easier to go through a UI and change something in the database than it will be to change the XML files for the applications. This means it will also be possible to do general reconfiguration without any redeployment. 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. Screens and forms are very much business level artifacts in my opinion, and it does seem like for the most part when people ask about configuring access control they have specific screens, forms, form fields, etc in mind. I agree that a rendered screen or form is a business level artifact, but a screen definition or form definition is no more a business level artifact than a Java class, XML file or JSP would be. These are very technical artifacts IMO. I think I see what you mean... like from an end-user perspective. That is basically what I have in mind with my comment above. On a side note, usually when I say "business-level artifact" I mean in contrast to framework-level artifacts, so a business-level artifact would be anything in the ofbiz/applications or ofbiz/specialpurpose directories, or perhaps better put anything that is not in the ofbiz/ framework directory. Whatever tool is used to write it, it is business logic (or business presentation or whatever) as opposed to purely technical enablement. As for a process... what is that anyway (I mean on a conceptual level, putting it in terms that should be understandable by someone not familiar with what you're working on, and not even familiar with OFBiz)? Is it a way of grouping screens or other artifacts? If so, that's fine, in fact that's great, and it's one of many ways of grouping artifacts to help deal with the fact that at that level of granularity there are a lot of options to deal with (people usually ask for it before realizing how many options there really are). I gave an example of a process at the top of my message. Another example would be "update a party's email address". In this process there is a service (usually one, but not always) a screen, a form, some fields, etc. In the current authz implementation these artifacts would call their respected methods of checking access to that process, however as I mentioned above this could easily be changed to be part of the artifact's framework, so that an artifact would then register itself with the process. Again, this really won't effectively be much different than calling the existing has- permission method(s). So, while yes I guess it is a way of grouping artifacts, I never considered it as such. I've alwa
Re: Domain Based Security ( was re: Authz...)
On May 5, 2009, at 5:24 PM, David E Jones wrote: 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. I'm not sure what you mean by this... which proposal are you referring to? If it is the main one you documented and implemented I think there are some big differences here, mainly that the artifacts themselves do not have anything in them for configuring access control (permissions, etc), not even specifying a "process" that they are part of, and instead the external stuff where access control is configured refers to the artifacts. Yes, the same proposal I have been talking about from the beginning. While you are correct that the current implementation and proposal does not have a specific method of "registering" artifacts with the process, instead it is using the current patterns to check access to for the process within the artifact. In the end, this is all exactly the same thing, registering an artifact and adding authorization logic to the artifact's framework or calling the same functionality from within the artifact is all really just a matter of aesthetics. So, this is something which could be added to any system which is developed. 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. Screens and forms are very much business level artifacts in my opinion, and it does seem like for the most part when people ask about configuring access control they have specific screens, forms, form fields, etc in mind. I agree that a rendered screen or form is a business level artifact, but a screen definition or form definition is no more a business level artifact than a Java class, XML file or JSP would be. These are very technical artifacts IMO. As for a process... what is that anyway (I mean on a conceptual level, putting it in terms that should be understandable by someone not familiar with what you're working on, and not even familiar with OFBiz)? Is it a way of grouping screens or other artifacts? If so, that's fine, in fact that's great, and it's one of many ways of grouping artifacts to help deal with the fact that at that level of granularity there are a lot of options to deal with (people usually ask for it before realizing how many options there really are). I gave an example of a process at the top of my message. Another example would be "update a party's email address". In this process there is a service (usually one, but not always) a screen, a form, some fields, etc. In the current authz implementation these artifacts would call their respected methods of checking access to that process, however as I mentioned above this could easily be changed to be part of the artifact's framework, so that an artifact would then register itself with the process. Again, this really won't effectively be much different than calling the existing has-permission method(s). So, while yes I guess it is a way of grouping artifacts, I never considered it as such. I've always thought of it simply as the artifacts are all used in a specific process (or processes). Anyway, to explore the "process" concept further in general a single artifact (such as a screen) is typically used in more than one business process. All that means is that a single artifact can be a member of more than one artifact group and if the user has access to any of those artifact groups they have access to that screen. On the other hand, if that is too liberal (which it seems to me, ie it might allow access where it isn't intended) then we may need to restrict it more. What I mean by that is the term "process" to me might mean that they can use a certain screen (or other artifact) as part of that process, but not as part of any other process or for any other reason. If that's the case then we need something else in the project to keep track of which "process" the user is currently in... and that would be kind of lik
Re: Domain Based Security ( was re: Authz...)
In the design I'm working on, the artifacts query an "authorization manager" - so that the details of permissions management are kept in a different location. When an artifact is used, it supplies the authorization manager with the artifact's unique ID and the user's UserLogin GenericValue, and the authorization manager returns a list of permissions granted to the user for that artifact. Like you said, the permissions are not kept in the artifacts themselves. Having a separate authorization manager not only relieves the artifacts of permission management details, but the manager itself could delegate those details to a third party (a network OS or a security policy manager). -Adrian 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" To: dev@ofbiz.apache.org 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...)
No, you're not forced to implement security on a fine level of granularity. Lower level (or more granular) artifacts inherit permissions from higher level artifacts. You could assign permissions to a form field (or menu item) if you want to. But you don't *have* to. The form field would normally inherit permissions from the form, or the screen, or the component. I don't want to go into much detail right now, but I can see you're not going to wait for me to get the design document done. ;-) -Adrian Andrew Zeneski wrote: The problem I see with this is that in an artifact based system we are forced to implement security on that fine level of granularity. Where in a process based system, the process can be defined as granular as necessary for the application. Only when very fine level of granularity is needed would it be necessary. The level of control in a process model is as great as the application needs but is much easier to understand for administration and configuration. Andrew On May 5, 2009, at 4:28 PM, Adrian Crum wrote: 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
Re: Domain Based Security ( was re: Authz...)
ng. 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" To: dev@ofbiz.apache.org 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...)
The problem I see with this is that in an artifact based system we are forced to implement security on that fine level of granularity. Where in a process based system, the process can be defined as granular as necessary for the application. Only when very fine level of granularity is needed would it be necessary. The level of control in a process model is as great as the application needs but is much easier to understand for administration and configuration. Andrew On May 5, 2009, at 4:28 PM, Adrian Crum wrote: 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
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
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" To: dev@ofbiz.apache.org 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...)
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" To: dev@ofbiz.apache.org 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...)
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" To: dev@ofbiz.apache.org 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: 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...)
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: 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: ... Notice there are no explicit permission checks. Instead, each artifact has identified itself in the security domain.
Re: Domain Based Security ( was re: Authz...)
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: ... 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'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" To: dev@ofbiz.apache.org 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" To: dev@ofbiz.apache.org 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" To: dev@ofbiz.apache.org 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...)
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" To: dev@ofbiz.apache.org 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...)
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...)
void renderWidget(Appendable writer, Map> Object> context, R renderer)
>>throws GeneralException, IOException;
>> ...
>> }
>>
>> ModelScreen::renderScreenString changed to ModelScreen::renderWidget
>>
>> ModelScreen has this:
>>
>> public class ModelScreen extends ModelWidget
>> implements Serializable {
>> ..
>> @Override
>> protected void renderWidget(Appendable writer, Map
>> 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"
>> To: dev@ofbiz.apache.org
>> Cc: "Anil Patel"
>> 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"
>>> To: dev@ofbiz.apache.org
>>> Cc: "Anil Patel"
>>> 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 inhere
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)
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
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 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 context, R renderer)
throws GeneralException, IOException;
...
}
ModelScreen::renderScreenString changed to ModelScreen::renderWidget
ModelScreen has this:
public class ModelScreen extends ModelWidget
implements Serializable {
..
@Override
protected void renderWidget(Appendable writer, MapObject> 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"
To: dev@ofbiz.apache.org
Cc: "Anil Patel"
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 Messa
Re: Domain Based Security ( was re: Authz...)
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)
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 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
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
context, R renderer)
throws GeneralException, IOException;
...
}
ModelScreen::renderScreenString changed to ModelScreen::renderWidget
ModelScreen has this:
public class ModelScreen extends ModelWidget implements
Serializable {
..
@Override
protected void renderWidget(Appendable writer, Map 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"
To: dev@ofbiz.apache.org
Cc: "Anil Patel"
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"
> To: dev@ofbiz.apache.org
> Cc: "Anil Patel"
> 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 s
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...)
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 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 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 wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org 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 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 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 wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org 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 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...)
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 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 wrote: > > > From: Andrew Zeneski > > Subject: Re: Domain Based Security ( was re: Authz...) > > To: dev@ofbiz.apache.org > > 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 > > 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...)
No you misunderstood me. I was referring to us agreeing in a previous email that "it was a fair assessment". Hence the smiley. I think your comparison here is correct. In the process driven model, the logic is attached to the process, and the process is attached to various artifacts. The "gatekeeper" indeed is the central holder of information. However, I do believe your analogy is slightly off. Its more like "Adrian wishes to start car X" the gatekeeper takes the information from Adrian's "key" and says "Ok" or "Not Ok". The process is "start car X", the credentials are the "ignition key". Andrew 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 wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org 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 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...)
David E Jones wrote: If I understand right where Adrian is going with this thread it is to just start with wanting to granular for flexibility r reasons and instead of having permissions that each screen/sevice/etc checks just have each screen/service/etc BE a permission of sorts. We wouldn't have any permission related configuration or code in the screens/services/etc except for a single attribute to flag whether permission is required or not (ie a require-permission flag), which we would want to be true by default. Now that the granularity issue is taken care of the next step is to build stuff on top of it to help manage the thousands of permissions that are now in the project... and THAT is where things get fun an interesting. That's a close summary, but you forgot one thing - permission inheritance. There won't be thousands of permissions - thanks to inheritance. As far as I can tell, OFBiz out of the box wouldn't have any more permissions than it has now. -Adrian
Re: Domain Based Security ( was re: Authz...)
Sam, That's an interesting article, and very relevant for some security related changes we've done in recent months. I was going to say that this discussion about a new security approach doesn't have much to do with that article since this discussion is really just all about how to configure and/or program access control to different parts of the system and the intent is to improve ease of use rather than tightness or thoroughness of security. However, thinking about it more there are certain things that may actually lead to tighter and more thorough security. For example, the discussion about "Domain-Based Security" is heading in the direction of externalizing 99% of the security configuration from the code. This is an idea that has been discussed a few times over the year and I've always found it interesting, but we really haven't had super-critical issues with the permission configuration and code stuff so not much has been done about it. If I understand right where Adrian is going with this thread it is to just start with wanting to granular for flexibility r reasons and instead of having permissions that each screen/sevice/etc checks just have each screen/service/etc BE a permission of sorts. We wouldn't have any permission related configuration or code in the screens/ services/etc except for a single attribute to flag whether permission is required or not (ie a require-permission flag), which we would want to be true by default. Now that the granularity issue is taken care of the next step is to build stuff on top of it to help manage the thousands of permissions that are now in the project... and THAT is where things get fun an interesting. Anyway, I'm planning to write-up more of this as soon as I get the time... hopefully in the next couple of days because I think this is important... but I'm behind enough that people are actually writing me directly and complaining that I haven't reviewed their stuff... in other words it seems there are expectations about related to what they think I should be doing and I haven't lived up to their dreams. Oh, back to the first point: this approach might actually increase the tightness and thoroughness of security because the default constraint will change from allowing anything unless the screen/service/etc checks for a permission, to allowing nothing unless the person creating the screen/service/etc designates that no permission is required, or the user has permission for that artifact (either to use in general, or to use for a specific set of records). So yes, this article IS actually relevant to the discussion. -David On May 4, 2009, at 5:35 AM, Sam Hamilton wrote: Not to get in the middle of this as to be honest I don't know enough for most of this thread to make sense but when I saw this article http://www.readwriteweb.com/archives/mcafee_enabling_malware_distribution_and_fraud.php it made me remember why everyone should be passionate about security On 04/05/2009 14:35, "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 wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org 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 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 pro
Re: Domain Based Security ( was re: Authz...)
Do you really think the intent of the people discussing this is to confuse people, or even to convince people? Let's be realistic about this... the subject here is a complicated one and there are lots of different issues related to it. Some points are coming up but I don't think we've even scratched the surface yet. Heck, I don't think there has even been enough time for some people to get over this enough personally and emotionally so that a totally objective and rational conversation can even happen. If you're wanting to use something then the best thing to do is write up what you're wanting to do with it, and what you'd like to see in the security functionality in OFBiz. Back to the being realistic thing... again I don't think ANY of us has thought this through thoroughly enough, including brainstorming to explore options and then decision making to decide on it. Keep in mind that if we choose something in a hasty way, it'll just not live as long in the project. In other words, if there are still major issues we'll all be wanting something different in the near future again anyway. For example, I still haven't had a chance to write up some security related things that are related to this and that have been discussed over the years and that I think are important if we're going to have an approach to security that will really meet the needs and wants of users. I'm guessing there are others in the same boat. I agree with Adam on this one, I don't think it's wise to expect the conversation to settle down or for any of us to have a good thorough chance to think it through in less than 2-4 weeks. -David On May 4, 2009, at 7:00 AM, Anil Patel wrote: 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 wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org 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 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...)
What I see so far is what the new system will do. that is good what I don't see is an equivalent document on how the old system handles or does not handle the same situations. This would tie in with why the need for the new system. I also don't see, since this is a security system, any consideration both for the old and new system as to its possible vulnerabilities to hackers. How the new system will be better than the old system, doing the job of keeping people out of areas that should not be in. If there is going to be a honest to goodness review process, I believe the above documents should be included. Anil Patel sent the following on 5/4/2009 6:19 AM: > 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" >> To: dev@ofbiz.apache.org >> Cc: "Anil Patel" >> 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 >>> wrote: >>> >>>> From: Andrew Zeneski >>>> Subject: Re: Domain Based Security ( was re: Authz...) >>>> To: dev@ofbiz.apache.org >>>> 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 >>>> 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, artif
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" To: dev@ofbiz.apache.org Cc: "Anil Patel" 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 wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org 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 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...)
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" To: dev@ofbiz.apache.org Cc: "Anil Patel" 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 > wrote: > >> From: Andrew Zeneski >> Subject: Re: Domain Based Security ( was re: Authz...) >> To: dev@ofbiz.apache.org >> 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 >> 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...)
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 wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org 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 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...)
Not to get in the middle of this as to be honest I don't know enough for most of this thread to make sense but when I saw this article http://www.readwriteweb.com/archives/mcafee_enabling_malware_distribution_and_fraud.php it made me remember why everyone should be passionate about security On 04/05/2009 14:35, "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 wrote: > From: Andrew Zeneski > Subject: Re: Domain Based Security ( was re: Authz...) > To: dev@ofbiz.apache.org > 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 > 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 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 wrote: > From: Andrew Zeneski > Subject: Re: Domain Based Security ( was re: Authz...) > To: dev@ofbiz.apache.org > 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 > 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 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 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...)
--- On Sun, 5/3/09, Andrew Zeneski 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...)
Okay, so it seems that Adrian and I have a very similar idea. The only major difference I see is one is artifact based and the other is process based. In the artifact based system, each artifact needs to register itself, and somehow the framework needs to know how to process access control for each artifact. Each artifact still has permissions, so it will check to see if the user has specific permission(s) for the artifact. Access control logic is still required, and the system will need to know how to process this for each artifact. I'm not clear yet what that would look like, but so far it doesn't sound much different. In the process based system, instead of registering artifacts, the developer registers process based strings with the system (in the designs this is handled by seed data). Logic is attached to each process string (or parent process string when parent/child share the same logic). Authorization is handled per process by checking to see if the user has "permission" to perform that process. Processes are hierarchical (it appears the domain based system is as well) where a user with access to the higher level of the hierarchy has implied access to all the lower levels. 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? Andrew On May 3, 2009, at 10:22 PM, Adrian Crum wrote: Understood. If there is any interest in the design, and we start to flesh it out, I'm sure those scenarios could be presented and addressed. -Adrian --- On Sun, 5/3/09, Andrew Zeneski wrote: From: Andrew Zeneski Subject: Re: Domain Based Security ( was re: Authz...) To: dev@ofbiz.apache.org Date: Sunday, May 3, 2009, 7:11 PM Because no matter how we design security for the default implementation in OFBiz there will always be some industry, or business requirement that is not covered, there is no way we can plan for every possible scenario. Thus, we need to make sure there are simple ways to modify the default behavior without having to intrude into the low level functionality. This is one of the key issues I have been trying to solve. On May 3, 2009, at 7:26 PM, Adrian Crum wrote: My followup question will be, how do I customize the access logic for a specific client so that I can maintain my own logic in a private component and avoid problems when updating applications? Why would you want to do that? I can't think of a reason why a security system would need to be changed.
Re: Domain Based Security ( was re: Authz...)
Understood. If there is any interest in the design, and we start to flesh it out, I'm sure those scenarios could be presented and addressed. -Adrian --- On Sun, 5/3/09, Andrew Zeneski wrote: > From: Andrew Zeneski > Subject: Re: Domain Based Security ( was re: Authz...) > To: dev@ofbiz.apache.org > Date: Sunday, May 3, 2009, 7:11 PM > Because no matter how we design security for the default > implementation in OFBiz there will always be some industry, > or business requirement that is not covered, there is no way > we can plan for every possible scenario. Thus, we need to > make sure there are simple ways to modify the default > behavior without having to intrude into the low level > functionality. This is one of the key issues I have been > trying to solve. > > On May 3, 2009, at 7:26 PM, Adrian Crum wrote: > > >> > >> My followup question will be, how do I customize > the access > >> logic for a specific client so that I can maintain > my own > >> logic in a private component and avoid problems > when > >> updating applications? > > > > Why would you want to do that? I can't think of a > reason why a security system would need to be changed.
Re: Domain Based Security ( was re: Authz...)
Because no matter how we design security for the default implementation in OFBiz there will always be some industry, or business requirement that is not covered, there is no way we can plan for every possible scenario. Thus, we need to make sure there are simple ways to modify the default behavior without having to intrude into the low level functionality. This is one of the key issues I have been trying to solve. On May 3, 2009, at 7:26 PM, Adrian Crum wrote: My followup question will be, how do I customize the access logic for a specific client so that I can maintain my own logic in a private component and avoid problems when updating applications? Why would you want to do that? I can't think of a reason why a security system would need to be changed.
Re: Domain Based Security ( was re: Authz...)
--- On Sun, 5/3/09, Andrew Zeneski wrote: > What you are describing here is very similar to the > process-based authorization system which I proposed, the > main differences is in my proposal everything is defined in > a process [permission] string where this is based on > artifacts. I think I need to understand this more, as I > don't really see yet how it would work. > > You mention there is no permission-checking code, but you > also mention that if the user has a specific permission then > the screen is displayed. This is the confusing part to me > right now. How does the "domain" know if a user > has permission if there is no permission checking code? I could have been more detailed in my description, so I apologize for the confusion. As far as implementation details are concerned, I intentionally left those out. The idea is to come up with a design for security first. Once that design is finalized, we can start working on implementation. The security domain is just a representation of how OFBiz artifacts are laid out. It's like a picture of a car. You can't drive the picture, but you can drive the car. Each artifact registers itself in the domain. I gave an example using a element. Following the picture analogy, each element adds something to the picture. When a user attempts to access the artifact, the artifact takes its location in the security domain, and the user login (or whatever) and passes that information to an authentication mechanism. The authentication mechanism returns a set of permissions (create, update, delete, view, etc). The artifact takes those permissions and uses them accordingly (display a screen or return a permission error, display form data as text, or display form data as input fields). To continue with the picture analogy, when the user enters the picture there will be artifacts there he/she can interact with. Let's say the picture includes a car, a boat, and lawn mower. The user's ability to start the engine on the car, boat, or lawn mower depends upon their "start engine" permission for each. In other words, the car says to the authentication mechanism, "I am a car. Give me the car permissions for user Adrian." The authentication mechanism returns a list of permissions. If one of those permissions is "start engine" I am able to start the car. > Display a list of example records, for the records the user > can update display the update button, for the records the > user can delete show the delete button. For the records > which the user does not have these permissions don't > display the button. Entities are no different than any other OFBiz artifact - they register themselves in the security domain. Entities could extend the element with additional elements and attributes that define user permission on each record. > When delete is pressed, we need to make sure the user > really does have access to delete this record, how can we > verify this? The Delete button would know to appear only when the user has delete permission. If the permission doesn't exist, then the button doesn't appear. > My followup question will be, how do I customize the access > logic for a specific client so that I can maintain my own > logic in a private component and avoid problems when > updating applications? Why would you want to do that? I can't think of a reason why a security system would need to be changed. > For me these are the most important requirements (very > granular control and ease of customizing without modifying > files in the application). I'm confident it will meet most security needs. The concept is not mine - it's modeled after Novell Netware's security (probably Windows too). I have yet to find a limitation in the ability to control user access to network resources. -Adrian
