Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/

[Andrew Zeneski-2]

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

[David E Jones-3]

On May 5, 2009, at 2:11 PM, Andrew Zeneski 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.

> 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.

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).

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 like the Seam "conversation" scope.

Anyway, I don't know if you intended to go to that extend and I think  
that considering a "process" as another type of artifact group would  
handle what you're thinking of, but I'm really not sure.

On a side note, related to the "Brainstorming: Security Requirements/
Scenarios" thread discussion we had, I haven't heard back from you  
about additional statements to add to the list. I think that relates  
to this discussion though, so I'm mentioning it just case something  
relevant needs to be added there.

-David

> On May 5, 2009, at 3:59 PM, David E Jones wrote:
>
>>
>> Exactly, I like this direction a lot better too... ie don't have  
>> the permissions in the artifacts but have them all in a separate  
>> place that refers back to the artifacts (and other things) as needed.
>>
>> With it outside the artifacts and centralized in database driven  
>> configuration, it would be a LOT easier for end-users to have  
>> control and configure things in a wide variety of ways, without  
>> needing a programmer and without changing any XML, Java, groovy or  
>> anything.
>>
>> -David
>>
>>
>> On May 5, 2009, at 11:43 AM, Andrew Zeneski wrote:
>>
>>> To me this sounds like the security information is being spread  
>>> out in ever more places, not consolidated. If I need to customize  
>>> the authorization logic, I would much rather it be centralized and  
>>> NOT in the artifacts. If it was in the artifacts, much like it is  
>>> today, then customizing would require modifications to the OOTB  
>>> artifacts. Which is exactly what we should be avoiding.
>>>
>>> Andrew
>>>
>>> On May 5, 2009, at 11:42 AM, Adrian Crum wrote:
>>>
>>>> In the design I proposed, the configuration resides in the  
>>>> artifacts themselves.
>>>>
>>>> -Adrian
>>>>
>>>> Harmeet Bedi wrote:
>>>>> If goal is to change security without changing code or XML  
>>>>> configuration.. the configuration has to reside somewhere. db  
>>>>> seemed like a spot.
>>>>> UI would needs to show the artifacts and permission and  
>>>>> configure groups on them.
>>>>> I had SecurityPermission entity extended to have  
>>>>> SecurityResource(Artifact) and SecurityActionType(e.g. access)
>>>>> If the issue is that should there be no static check and collect  
>>>>> resources to seed db, instead to it dynamically it would be  
>>>>> fine. It would make things dynamic and configuration friendly  
>>>>> while still taking config out of xml.
>>>>> Harmeet
>>>>> ----- Original Message -----
>>>>> From: "Adrian Crum" <[hidden email]>
>>>>> To: [hidden email]
>>>>> Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada  
>>>>> Eastern
>>>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>>>> Harmeet Bedi wrote:
>>>>>> Ofbiz has the graph metadata of artifacts but navigating graph to
>>>>>> dynamically determine will be expensive.
>>>>> It doesn't have to be. If we end up using the artifact info  
>>>>> stuff for some kind of security administration screen, we can  
>>>>> set up the artifact gathering code to go only as deep as what is  
>>>>> currently being displayed. In other words, the artifact  
>>>>> gathering could be more dynamic. As the user navigates farther  
>>>>> down the graph, additional parsing is done.
>>>>> This would eliminate the need to graph all artifacts in one step.
>>>>> I agree with David that storing the graph in the database is a  
>>>>> bad idea.
>>>>> -Adrian
>>>
>>
>

[Adrian Crum]

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
>
>

[Adrian Crum]

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" <[hidden email]>
>>>> To: [hidden email]
>>>> Sent: Tuesday, May 5, 2009 10:41:57 AM GMT -05:00 US/Canada Eastern
>>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>>> Harmeet Bedi wrote:
>>>>> Ofbiz has the graph metadata of artifacts but navigating graph to
>>>>> dynamically determine will be expensive.
>>>> It doesn't have to be. If we end up using the artifact info stuff
>>>> for some kind of security administration screen, we can set up the
>>>> artifact gathering code to go only as deep as what is currently
>>>> being displayed. In other words, the artifact gathering could be
>>>> more dynamic. As the user navigates farther down the graph,
>>>> additional parsing is done.
>>>> This would eliminate the need to graph all artifacts in one step.
>>>> I agree with David that storing the graph in the database is a bad
>>>> idea.
>>>> -Adrian
>>
>
>

[Andrew Zeneski-2]

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 like the Seam "conversation" scope.

This may be something to consider, and very much like how the auto-
grant functionality works in the prototype I committed, once a user is  
granted permission to a specific process, permissions to other  
processes are granted for the duration of that request. This is so  
when a user is granted permission to update a lead in the SFA  
application, the user is also granted permission to update the party  
record for that lead. This is all scoped for just the duration of the  
request.

[Andrew Zeneski-2]

David,

I would like to publicly apologize for my behavior this past weekend.  
While I do not believe you (or anyone else) has the right to revert  
any commit which does not directly effect the build or ability to run  
the trunk without first discussing with the author and giving them a  
chance to correct/revert the changes themselves; I also do not believe  
I should have responded to you the way I did. For that I wish to offer  
you my sincerest apology.

I do not believe your actions were a direct attack on me personally, I  
responded abruptly in the heat of the moment. Having worked together  
on OFBiz for the last 8 years we both should have been able to rectify  
any differences without offending one another. Again, I apologize or  
not acting appropriately.


Andrew

On May 3, 2009, at 4:00 PM, Andrew Zeneski wrote:

> Inline...
>
>>
>> Please don't revert the rest of the code. The point is that this  
>> needs time to mature, so it should stay in there but not become the  
>> default... not YET anyway.
>
> I will leave the what was implemented alone for the time being.
>
>>
>> Also, please don't be personally offended by this. Just because  
>> there are comments and feedback doesn't mean something has no  
>> merit, it just means that some adjustments to it might be able to  
>> improve it. That's what collaboration is all about, and I guess if  
>> you'd rather not do it than have other people comments on it and  
>> make changes to it then collaboration will be difficult.
>
> I am not offended by any comments or feedback, I was only offended  
> by your actions. Reverting the example was nothing more than a power  
> move by you. You can argue this if you wish, but the fact is nothing  
> else except for an example was effected, and there has been no  
> discussion by anyone to revert anything yet. If you did feel that it  
> was problematic, it should have been brought up if not to the  
> community then at least to me personally.
>
>>
>> Just to clear that up... are you saying you would rather not do any  
>> of this than make some changes and refinements to it based on  
>> feedback? I hope that's not the case. My intent with this, as I  
>> explained in my email, is to make a compromise and allow  
>> development and improvement on this to continue without impact on  
>> other parts of the project until it is more ready for that.
>
> Your assumptions (as assumptions often are) completely wrong. Even  
> though say now you hope this isn't the case, you have publicly  
> accused me of this in your Notes On Security Changes document. What  
> have I been doing for the past week? It surely wasn't moving ahead  
> and checking in changes to all the applications to use a new  
> authorization pattern. What I have been doing is acquiring  
> additional needs/requirements comparing them to what I have planned  
> and trying to discuss with the community these changes. Refining the  
> API and including the requirements which I have gathered.
>
> You keep claiming that this new pattern is less flexible. While that  
> may (but I don't agree) be true to a certain extent, is it also far  
> MORE flexible when it comes to creating custom implementations for  
> vertical, custom or customized applications.
>
> Andrew
>

[David E Jones-3]

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 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 like the Seam  
>> "conversation" scope.
>
> This may be something to consider, and very much like how the auto-
> grant functionality works in the prototype I committed, once a user  
> is granted permission to a specific process, permissions to other  
> processes are granted for the duration of that request. This is so  
> when a user is granted permission to update a lead in the SFA  
> application, the user is also granted permission to update the party  
> record for that lead. This is all scoped for just the duration of  
> the request.

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.

-David

[Shi Yusen]

在 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.

[Jacques Le Roux]

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" <[hidden email]>

> 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
>

[Adrian Crum]

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

[David E Jones-3]

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

[Adrian Crum]

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

[David E Jones-3]

Thank you Andrew. I appreciate this. It helps smooth things out, but  
don't feel like you have to apologize for my sake. This sort of  
interaction (both from me to you and back) seems to be a common thing  
in these discussions. We all care about the things we work on  
including specific things we design or create and things we use on a  
regular basis, so it seems like over the years these things happen a  
lot. The conversation carries on regardless and eventually we all  
settle down and discuss things at least somewhat rationally... it's  
just a matter of not giving up and I really appreciate that you have  
not given up on this security topic.

It's wonderful that OFBiz is so big these days and has so many people  
actively involved. It is a log different from the early days when  
writing and committing stuff was exactly what was done... usually  
because nothing existed before or no one else was working on or  
interested in working on a specific area. Also, if we changed  
something that required a migration it didn't cause too much pain  
because there weren't too many people using the stuff (and there  
weren't many other users trying to keep up with the project, now there  
are a lot).

Unfortunately this means that changes are much more carefully  
monitored and have a much bigger impact so a lot more discussion is  
required and things are a LOT more complicated. Personally I've given  
up on the idea that I am even capable of designing and implementing  
major changes by myself. I know that a certain level of research and  
planning is necessary to be able to even present ideas, and  
fortunately often other people do that too, and after I get involved  
in those things I've been impressed by how much the collaboration  
helps result in a cleaner and more effective solution. The security  
stuff I did earlier this year was a great example, and that was all  
started by someone (Michele) who had much more experience than me, and  
then after researching and presenting possible solutions for OFBiz I  
also got good feedback and was able to implement better things. I've  
also been VERY fortunate in having other people participate in  
implementation based on these efforts, which has seen the efforts  
through with a LOT less of my own time required.

I guess in other words, overall I like it and it's great to have so  
many good people involved. On that note, it's great that you're  
getting much more involved again and that you're pushing all of us to  
improve this messy part of OFBiz, ie the access control aspect of  
security.

-David


On May 5, 2009, at 5:24 PM, Andrew Zeneski wrote:

> David,
>
> I would like to publicly apologize for my behavior this past  
> weekend. While I do not believe you (or anyone else) has the right  
> to revert any commit which does not directly effect the build or  
> ability to run the trunk without first discussing with the author  
> and giving them a chance to correct/revert the changes themselves; I  
> also do not believe I should have responded to you the way I did.  
> For that I wish to offer you my sincerest apology.
>
> I do not believe your actions were a direct attack on me personally,  
> I responded abruptly in the heat of the moment. Having worked  
> together on OFBiz for the last 8 years we both should have been able  
> to rectify any differences without offending one another. Again, I  
> apologize or not acting appropriately.
>
>
> Andrew
>
> On May 3, 2009, at 4:00 PM, Andrew Zeneski wrote:
>
>> Inline...
>>
>>>
>>> Please don't revert the rest of the code. The point is that this  
>>> needs time to mature, so it should stay in there but not become  
>>> the default... not YET anyway.
>>
>> I will leave the what was implemented alone for the time being.
>>
>>>
>>> Also, please don't be personally offended by this. Just because  
>>> there are comments and feedback doesn't mean something has no  
>>> merit, it just means that some adjustments to it might be able to  
>>> improve it. That's what collaboration is all about, and I guess if  
>>> you'd rather not do it than have other people comments on it and  
>>> make changes to it then collaboration will be difficult.
>>
>> I am not offended by any comments or feedback, I was only offended  
>> by your actions. Reverting the example was nothing more than a  
>> power move by you. You can argue this if you wish, but the fact is  
>> nothing else except for an example was effected, and there has been  
>> no discussion by anyone to revert anything yet. If you did feel  
>> that it was problematic, it should have been brought up if not to  
>> the community then at least to me personally.
>>
>>>
>>> Just to clear that up... are you saying you would rather not do  
>>> any of this than make some changes and refinements to it based on  
>>> feedback? I hope that's not the case. My intent with this, as I  
>>> explained in my email, is to make a compromise and allow  
>>> development and improvement on this to continue without impact on  
>>> other parts of the project until it is more ready for that.
>>
>> Your assumptions (as assumptions often are) completely wrong. Even  
>> though say now you hope this isn't the case, you have publicly  
>> accused me of this in your Notes On Security Changes document. What  
>> have I been doing for the past week? It surely wasn't moving ahead  
>> and checking in changes to all the applications to use a new  
>> authorization pattern. What I have been doing is acquiring  
>> additional needs/requirements comparing them to what I have planned  
>> and trying to discuss with the community these changes. Refining  
>> the API and including the requirements which I have gathered.
>>
>> You keep claiming that this new pattern is less flexible. While  
>> that may (but I don't agree) be true to a certain extent, is it  
>> also far MORE flexible when it comes to creating custom  
>> implementations for vertical, custom or customized applications.
>>
>> Andrew
>>
>