OFBiz › OFBiz - Dev

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

153 messages Options

1 ... 345678

Andrew Zeneski-2

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 <[hidden email]>
> wrote:
>
>> From: Andrew Zeneski <[hidden email]>
>> Subject: Re: Domain Based Security ( was re: Authz...)
>> To: [hidden email]
>> 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.
>
>
>

Adrian Crum-2

Re: Domain Based Security ( was re: Authz...)

--- On Sun, 5/3/09, Andrew Zeneski <[hidden email]> wrote:

> The question I believe now is, which is better? I
> personally think in terms of processes which is why what I
> proposed was all process based. However, artifact based may
> be more granular, but possibly too granular. If I understand
> this right, artifact based we could potentially have
> different access requirements for every single
> form/screen/service/entity/etc; where in a process based
> system the developer would define the processes as part of
> the application and these processes could be shared across
> common artifacts (forms can share with screens that share
> with services, etc).
>
> Does this sound like a fair assessment?

Yes it is. It boils down to permission-driven permissions, versus artifact-driven permissions.

-Adrian

Andrew Zeneski-2

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 <[hidden email]>
> wrote:
>> The question I believe now is, which is better? I
>> personally think in terms of processes which is why what I
>> proposed was all process based. However, artifact based may
>> be more granular, but possibly too granular. If I understand
>> this right, artifact based we could potentially have
>> different access requirements for every single
>> form/screen/service/entity/etc; where in a process based
>> system the developer would define the processes as part of
>> the application and these processes could be shared across
>> common artifacts (forms can share with screens that share
>> with services, etc).
>>
>> Does this sound like a fair assessment?
>
> Yes it is. It boils down to permission-driven permissions, versus
> artifact-driven permissions.
>
> -Adrian
>
>
>
>

Adrian Crum-2

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

> From: Andrew Zeneski <[hidden email]>
> Subject: Re: Domain Based Security ( was re: Authz...)
> To: [hidden email]
> Date: Sunday, May 3, 2009, 11:00 PM
> I like to think of it more as process-driven permission vs
> artifact driven permissions, because the "permission
> string" is defined to match a specific process. Other
> than that I think we finally agreed on something.. Ha! :)
>
> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>
> >
> > --- On Sun, 5/3/09, Andrew Zeneski
> <[hidden email]> wrote:
> >> The question I believe now is, which is better? I
> >> personally think in terms of processes which is
> why what I
> >> proposed was all process based. However, artifact
> based may
> >> be more granular, but possibly too granular. If I
> understand
> >> this right, artifact based we could potentially
> have
> >> different access requirements for every single
> >> form/screen/service/entity/etc; where in a process
> based
> >> system the developer would define the processes as
> part of
> >> the application and these processes could be
> shared across
> >> common artifacts (forms can share with screens
> that share
> >> with services, etc).
> >>
> >> Does this sound like a fair assessment?
> >
> > Yes it is. It boils down to permission-driven
> permissions, versus artifact-driven permissions.
> >
> > -Adrian
> >
> >
> >
> >

porkiey

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

I don't see us agreeing on anything. I'm saying each artifact is responsible for its own security. You're saying security is defined by a process.

If you were to view a collection of artifacts - each responsible for its own security - defining some kind of process-driven security, then that might be true.

Applying your process-driven security design to the picture analogy (from what I have gathered so far from your design), it would be like there is a gatekeeper at the entrance to the picture. The gatekeeper says "Adrian intends to start the car, does he have permission to do that?" The car has no say in the matter. The gatekeeper controls everything.

The inherent limitation to that design is, the gatekeeper has to account for every motive I might have in interacting with every artifact in the picture. That gatekeeper has a lot on its hands!

I think it is simpler to have each artifact decide for itself what Adrian can or cannot do with it. I believe that was what David was trying to express when he said "it's the artifact we want the code attached to not the permission itself."

-Adrian

--- On Sun, 5/3/09, Andrew Zeneski <[hidden email]> wrote:

Anil Patel-3

Re: Domain Based Security ( was re: Authz...)

In reply to this post by Adrian Crum-2

Over last few days this discussion has changed subject few times. This
is going more on lines of "confuse them if you cannot convenience".

The new security system proposal document, implementation code and
code demonstrating its use, been out for more then week, All big names
in community have had chance to see it. I will rather discuss on list
of items that are so bad about new security system (which is now in
proposal status). If Andrew or others who like it cannot solve or
disprove them then either we will know that its bad and cannot be used.

I like the system and will like to use it.

Regards
Anil Patel

On May 4, 2009, at 2:35 AM, Adrian Crum wrote:

>
> I don't see us agreeing on anything. I'm saying each artifact is
> responsible for its own security. You're saying security is defined
> by a process.
>
> If you were to view a collection of artifacts - each responsible for
> its own security - defining some kind of process-driven security,
> then that might be true.
>
> Applying your process-driven security design to the picture analogy
> (from what I have gathered so far from your design), it would be
> like there is a gatekeeper at the entrance to the picture. The
> gatekeeper says "Adrian intends to start the car, does he have
> permission to do that?" The car has no say in the matter. The
> gatekeeper controls everything.
>
> The inherent limitation to that design is, the gatekeeper has to
> account for every motive I might have in interacting with every
> artifact in the picture. That gatekeeper has a lot on its hands!
>
> I think it is simpler to have each artifact decide for itself what
> Adrian can or cannot do with it. I believe that was what David was
> trying to express when he said "it's the artifact we want the code
> attached to not the permission itself."
>
> -Adrian
>
>
> --- On Sun, 5/3/09, Andrew Zeneski <[hidden email]>
> wrote:
>
>> From: Andrew Zeneski <[hidden email]>
>> Subject: Re: Domain Based Security ( was re: Authz...)
>> To: [hidden email]
>> Date: Sunday, May 3, 2009, 11:00 PM
>> I like to think of it more as process-driven permission vs
>> artifact driven permissions, because the "permission
>> string" is defined to match a specific process. Other
>> than that I think we finally agreed on something.. Ha! :)
>>
>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>
>>>
>>> --- On Sun, 5/3/09, Andrew Zeneski
>> <[hidden email]> wrote:
>>>> The question I believe now is, which is better? I
>>>> personally think in terms of processes which is
>> why what I
>>>> proposed was all process based. However, artifact
>> based may
>>>> be more granular, but possibly too granular. If I
>> understand
>>>> this right, artifact based we could potentially
>> have
>>>> different access requirements for every single
>>>> form/screen/service/entity/etc; where in a process
>> based
>>>> system the developer would define the processes as
>> part of
>>>> the application and these processes could be
>> shared across
>>>> common artifacts (forms can share with screens
>> that share
>>>> with services, etc).
>>>>
>>>> Does this sound like a fair assessment?
>>>
>>> Yes it is. It boils down to permission-driven
>> permissions, versus artifact-driven permissions.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>
>
>

Vince Clark

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" <[hidden email]>
To: [hidden email]
Cc: "Anil Patel" <[hidden email]>
Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain
Subject: Re: Domain Based Security ( was re: Authz...)

Over last few days this discussion has changed subject few times. This
is going more on lines of "confuse them if you cannot convenience".

The new security system proposal document, implementation code and
code demonstrating its use, been out for more then week, All big names
in community have had chance to see it. I will rather discuss on list
of items that are so bad about new security system (which is now in
proposal status). If Andrew or others who like it cannot solve or
disprove them then either we will know that its bad and cannot be used.

I like the system and will like to use it.

Regards
Anil Patel

On May 4, 2009, at 2:35 AM, Adrian Crum wrote:

BJ Freeman

Re: Authz API Discussion (was re: svn commit: r770084)

In reply to this post by Adrian Crum-2

I step back to this because I believe this is a good point.
Andy:
I did not become aware of your new security till last thur. I have been
wrapped up in other projects and have not paid much attention to the dev
list. my apologies.
so to me this has not been sitting in front of me for long.
Plus you have been very involved with this so it seems a no brainier.
I on the other hand have to first get my head around your concept.
then compare against the old way. That takes me at least a week or more
with everything else that is going on in my life.
I do believe in code review, seeing the weaknesses an strengths of both
systems. However that take a lot to cover this big a system.
So in my view, have a target of three months before implementing with
review as active as it is now would be what I consider normal.

My reason of not speaking up till now, I am still working this through
in my mind.\
I actually had some question that I wanted clarified. Till I saw the
discussion had turned in a none review vane.

I will post those under a separate email.

as a humorous side note you massive patch and the the revert got
rejected by my mail server which is set to reject in file 40K or more.

Andrew Zeneski sent the following on 5/1/2009 6:30 PM:

> I think everyone needs to step back just a bit. Yes, some code was
> written, but nothing that drastically changes anything. Actually, I paid
> very close attention to make sure that this could sit on the side lines
> so it could be evaluated. Very little effort has been put into the real
> work of migrating the applications, but that is going to change soon...
>
> So, instead of discussing what should or should not have been done, look
> at the fact that this entire effort is sitting in the community's lap
> right this minute. But instead of reviewing what is there, pointing out
> weaknesses offering suggestions or anything constructive at all, the
> discussion is solely around whether or not code should have been
> implemented or not. Let's face it, these documents have been in front of
> you for over a week, and there was not a single objection or concern
> raised until today. I have only a limited amount of free time, and if I
> am going to following this effort through to the end, it needs to have a
> steady progression. So to be frank, get over it.
>
> Code is being worked on actively for this effort, and I am expecting
> more involvement as soon as the API is finalized. That said, if you do
> have something to add, wish to see or just want to be involved, now is
> the time to be proactive! Otherwise the effort will push forward with
> the people who are indeed interested in improving security in OFBiz.
>
> Andrew
>
>
>
> On May 1, 2009, at 8:38 PM, Adrian Crum wrote:
>
>>
>> --- On Fri, 5/1/09, Scott Gray <[hidden email]> wrote:
>>> Some of these questions in the discussions so far give me
>>> the feeling that the write up Andrew put in confluence
>>> hasn't been read, is that the case?
>>>
>>> Anyway I'm a +1 for the new auth framework, I think it
>>> give us more power AND simplicity. Will it need improvement
>>> over time? of course it will but I think it's a much
>>> better base to work from.
>>
>> I don't know if you were around at the time, but I was. One of the
>> "weaknesses" Andrew is trying to fix with this latest effort is the
>> permissions services - another design he introduced a couple years
>> ago. Everyone went along with it and re-wrote code to use service
>> permissions. (I spent several weekends just converting the accounting
>> component over to the new security implementation). Now we're being
>> told "Oops, that design is limited, let me try again."
>>
>> Why would anyone have any objection to opening this up to the
>> community before we start writing code? Maybe there are others who see
>> weaknesses in the new design. Give them a chance to offer input.
>>
>> -Adrian
>>
>>
>>
>>
>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

Anil Patel-3

Re: Domain Based Security ( was re: Authz...)

In reply to this post by Vince Clark

Vince,
Here are the documents

http://docs.ofbiz.org/display/~jaz/OFBiz+Security+Refactor
http://docs.ofbiz.org/display/~jaz/Permissions+By+Application

Thanks for asking for the document. I have example on "How successful
people been in confusing the community".

Regards
Anil Patel

On May 4, 2009, at 9:11 AM, Vince Clark wrote:

> Anil, you mentioned a document. Can you send out the link? I'm sure
> it is in these threads somewhere but with all the traffic on this
> topic I cannot seem to find a link to the doc.
>
> ----- Original Message -----
> From: "Anil Patel" <[hidden email]>
> To: [hidden email]
> Cc: "Anil Patel" <[hidden email]>
> Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain
> Subject: Re: Domain Based Security ( was re: Authz...)
>
> Over last few days this discussion has changed subject few times. This
> is going more on lines of "confuse them if you cannot convenience".
>
> The new security system proposal document, implementation code and
> code demonstrating its use, been out for more then week, All big names
> in community have had chance to see it. I will rather discuss on list
> of items that are so bad about new security system (which is now in
> proposal status). If Andrew or others who like it cannot solve or
> disprove them then either we will know that its bad and cannot be
> used.
>
> I like the system and will like to use it.
>
> Regards
> Anil Patel
>
>
> On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
>
>>
>> I don't see us agreeing on anything. I'm saying each artifact is
>> responsible for its own security. You're saying security is defined
>> by a process.
>>
>> If you were to view a collection of artifacts - each responsible for
>> its own security - defining some kind of process-driven security,
>> then that might be true.
>>
>> Applying your process-driven security design to the picture analogy
>> (from what I have gathered so far from your design), it would be
>> like there is a gatekeeper at the entrance to the picture. The
>> gatekeeper says "Adrian intends to start the car, does he have
>> permission to do that?" The car has no say in the matter. The
>> gatekeeper controls everything.
>>
>> The inherent limitation to that design is, the gatekeeper has to
>> account for every motive I might have in interacting with every
>> artifact in the picture. That gatekeeper has a lot on its hands!
>>
>> I think it is simpler to have each artifact decide for itself what
>> Adrian can or cannot do with it. I believe that was what David was
>> trying to express when he said "it's the artifact we want the code
>> attached to not the permission itself."
>>
>> -Adrian
>>
>>
>> --- On Sun, 5/3/09, Andrew Zeneski <[hidden email]>
>> wrote:
>>
>>> From: Andrew Zeneski <[hidden email]>
>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>> To: [hidden email]
>>> Date: Sunday, May 3, 2009, 11:00 PM
>>> I like to think of it more as process-driven permission vs
>>> artifact driven permissions, because the "permission
>>> string" is defined to match a specific process. Other
>>> than that I think we finally agreed on something.. Ha! :)
>>>
>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>>
>>>>
>>>> --- On Sun, 5/3/09, Andrew Zeneski
>>> <[hidden email]> wrote:
>>>>> The question I believe now is, which is better? I
>>>>> personally think in terms of processes which is
>>> why what I
>>>>> proposed was all process based. However, artifact
>>> based may
>>>>> be more granular, but possibly too granular. If I
>>> understand
>>>>> this right, artifact based we could potentially
>>> have
>>>>> different access requirements for every single
>>>>> form/screen/service/entity/etc; where in a process
>>> based
>>>>> system the developer would define the processes as
>>> part of
>>>>> the application and these processes could be
>>> shared across
>>>>> common artifacts (forms can share with screens
>>> that share
>>>>> with services, etc).
>>>>>
>>>>> Does this sound like a fair assessment?
>>>>
>>>> Yes it is. It boils down to permission-driven
>>> permissions, versus artifact-driven permissions.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>

BJ Freeman

Re: Domain Based Security ( was re: Authz...)

In reply to this post by Vince Clark

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" <[hidden email]>
>> To: [hidden email]
>> Cc: "Anil Patel" <[hidden email]>
>> Sent: Monday, May 4, 2009 7:00:32 AM GMT -07:00 US/Canada Mountain
>> Subject: Re: Domain Based Security ( was re: Authz...)
>>
>> Over last few days this discussion has changed subject few times. This
>> is going more on lines of "confuse them if you cannot convenience".
>>
>> The new security system proposal document, implementation code and
>> code demonstrating its use, been out for more then week, All big names
>> in community have had chance to see it. I will rather discuss on list
>> of items that are so bad about new security system (which is now in
>> proposal status). If Andrew or others who like it cannot solve or
>> disprove them then either we will know that its bad and cannot be used.
>>
>> I like the system and will like to use it.
>>
>> Regards
>> Anil Patel
>>
>>
>> On May 4, 2009, at 2:35 AM, Adrian Crum wrote:
>>
>>>
>>> I don't see us agreeing on anything. I'm saying each artifact is
>>> responsible for its own security. You're saying security is defined
>>> by a process.
>>>
>>> If you were to view a collection of artifacts - each responsible for
>>> its own security - defining some kind of process-driven security,
>>> then that might be true.
>>>
>>> Applying your process-driven security design to the picture analogy
>>> (from what I have gathered so far from your design), it would be
>>> like there is a gatekeeper at the entrance to the picture. The
>>> gatekeeper says "Adrian intends to start the car, does he have
>>> permission to do that?" The car has no say in the matter. The
>>> gatekeeper controls everything.
>>>
>>> The inherent limitation to that design is, the gatekeeper has to
>>> account for every motive I might have in interacting with every
>>> artifact in the picture. That gatekeeper has a lot on its hands!
>>>
>>> I think it is simpler to have each artifact decide for itself what
>>> Adrian can or cannot do with it. I believe that was what David was
>>> trying to express when he said "it's the artifact we want the code
>>> attached to not the permission itself."
>>>
>>> -Adrian
>>>
>>>
>>> --- On Sun, 5/3/09, Andrew Zeneski <[hidden email]>
>>> wrote:
>>>
>>>> From: Andrew Zeneski <[hidden email]>
>>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>>> To: [hidden email]
>>>> Date: Sunday, May 3, 2009, 11:00 PM
>>>> I like to think of it more as process-driven permission vs
>>>> artifact driven permissions, because the "permission
>>>> string" is defined to match a specific process. Other
>>>> than that I think we finally agreed on something.. Ha! :)
>>>>
>>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>>>
>>>>>
>>>>> --- On Sun, 5/3/09, Andrew Zeneski
>>>> <[hidden email]> wrote:
>>>>>> The question I believe now is, which is better? I
>>>>>> personally think in terms of processes which is
>>>> why what I
>>>>>> proposed was all process based. However, artifact
>>>> based may
>>>>>> be more granular, but possibly too granular. If I
>>>> understand
>>>>>> this right, artifact based we could potentially
>>>> have
>>>>>> different access requirements for every single
>>>>>> form/screen/service/entity/etc; where in a process
>>>> based
>>>>>> system the developer would define the processes as
>>>> part of
>>>>>> the application and these processes could be
>>>> shared across
>>>>>> common artifacts (forms can share with screens
>>>> that share
>>>>>> with services, etc).
>>>>>>
>>>>>> Does this sound like a fair assessment?
>>>>>
>>>>> Yes it is. It boils down to permission-driven
>>>> permissions, versus artifact-driven permissions.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

BJ Freeman

Re:New Security system considerations

In reply to this post by jonesde

at this point I am neither for or against the new proposal.
after I get it under my belt I will offer my view.
However I do want to add more to the Access portion.
I would like to consider extending granularity of the permission to
include Menus and display of data.
the focus is that some menus should not be active till other processes
are accomplished. This include logging in, completing needed
information, like account information, or website.
Though this could be argued that it is not a security function, at
certain levels it is.
The menu activation could also be controlled by a entity similar to
validstatus change, but that is a different discussion.

>
> I'd be happy to discuss additional changes as well (which aren't yet
> documented) like adding support to check multiple permissions at once,
> returning a Map of results from that permission check. So, if you or
> anyone else has a wish list for security, let me know so I can get it
> all incorporated at the same time.
>
> Andrew
>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

David E Jones-3

Re: Domain Based Security ( was re: Authz...)

In reply to this post by Anil Patel-3

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 <[hidden email]>
>> wrote:
>>
>>> From: Andrew Zeneski <[hidden email]>
>>> Subject: Re: Domain Based Security ( was re: Authz...)
>>> To: [hidden email]
>>> Date: Sunday, May 3, 2009, 11:00 PM
>>> I like to think of it more as process-driven permission vs
>>> artifact driven permissions, because the "permission
>>> string" is defined to match a specific process. Other
>>> than that I think we finally agreed on something.. Ha! :)
>>>
>>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>>
>>>>
>>>> --- On Sun, 5/3/09, Andrew Zeneski
>>> <[hidden email]> wrote:
>>>>> The question I believe now is, which is better? I
>>>>> personally think in terms of processes which is
>>> why what I
>>>>> proposed was all process based. However, artifact
>>> based may
>>>>> be more granular, but possibly too granular. If I
>>> understand
>>>>> this right, artifact based we could potentially
>>> have
>>>>> different access requirements for every single
>>>>> form/screen/service/entity/etc; where in a process
>>> based
>>>>> system the developer would define the processes as
>>> part of
>>>>> the application and these processes could be
>>> shared across
>>>>> common artifacts (forms can share with screens
>>> that share
>>>>> with services, etc).
>>>>>
>>>>> Does this sound like a fair assessment?
>>>>
>>>> Yes it is. It boils down to permission-driven
>>> permissions, versus artifact-driven permissions.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>

David E Jones-3

Re: Domain Based Security ( was re: Authz...)

In reply to this post by porkiey

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" <[hidden email]> wrote:
>
>
>
> I don't see us agreeing on anything. I'm saying each artifact is
> responsible for its own security. You're saying security is defined
> by a process.
>
> If you were to view a collection of artifacts - each responsible for
> its own security - defining some kind of process-driven security,
> then that might be true.
>
> Applying your process-driven security design to the picture analogy
> (from what I have gathered so far from your design), it would be
> like there is a gatekeeper at the entrance to the picture. The
> gatekeeper says "Adrian intends to start the car, does he have
> permission to do that?" The car has no say in the matter. The
> gatekeeper controls everything.
>
> The inherent limitation to that design is, the gatekeeper has to
> account for every motive I might have in interacting with every
> artifact in the picture. That gatekeeper has a lot on its hands!
>
> I think it is simpler to have each artifact decide for itself what
> Adrian can or cannot do with it. I believe that was what David was
> trying to express when he said "it's the artifact we want the code
> attached to not the permission itself."
>
> -Adrian
>
>
> --- On Sun, 5/3/09, Andrew Zeneski <[hidden email]>
> wrote:
>
>> From: Andrew Zeneski <[hidden email]>
>> Subject: Re: Domain Based Security ( was re: Authz...)
>> To: [hidden email]
>> Date: Sunday, May 3, 2009, 11:00 PM
>> I like to think of it more as process-driven permission vs
>> artifact driven permissions, because the "permission
>> string" is defined to match a specific process. Other
>> than that I think we finally agreed on something.. Ha! :)
>>
>> On May 4, 2009, at 1:55 AM, Adrian Crum wrote:
>>
>>>
>>> --- On Sun, 5/3/09, Andrew Zeneski
>> <[hidden email]> wrote:
>>>> The question I believe now is, which is better? I
>>>> personally think in terms of processes which is
>> why what I
>>>> proposed was all process based. However, artifact
>> based may
>>>> be more granular, but possibly too granular. If I
>> understand
>>>> this right, artifact based we could potentially
>> have
>>>> different access requirements for every single
>>>> form/screen/service/entity/etc; where in a process
>> based
>>>> system the developer would define the processes as
>> part of
>>>> the application and these processes could be
>> shared across
>>>> common artifacts (forms can share with screens
>> that share
>>>> with services, etc).
>>>>
>>>> Does this sound like a fair assessment?
>>>
>>> Yes it is. It boils down to permission-driven
>> permissions, versus artifact-driven permissions.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>
>
>
>

Adrian Crum

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

Ean Schuessler

Re: Authz API Discussion (was re: svn commit: r770084)

In reply to this post by Andrew Zeneski-2

----- "Adam Heath" wrote:
> Adam Heath wrote:
> > Have you considered doing a git or mercurial branch of all these changes?
> hg clone http://hg.webslinger.org/hg/ofbiz.apache.org/

This situation underscores a discussion that David and I were having about distributed development. Andy's changes are a great example of the utility of the "pull" model implied by GIT and Hg. Andy could make all of his changes in some public "Andy" repo and then tell David to check them out. If David thinks the changes are ready then he can pull them into his repo. Even if David doesn't think they are ready, if some of us think Andy's patches are useful and want to play along then we can sync our repositories with his and use his code.

Now a completely separate issue is how we determine whether someone's changes are ready to go into the production repository. In a Linus style model, it would just be up to David and then maybe a lot of people would also follow Andy's branches closely (kind of like the Linux Realtime patch series). On the other hand, we could have some democratic +1 type thing going on about doing the merge.

In any case, the distributed model affords a lot of flexibility without people feeling like toes are getting stepped on.

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315

Christian Geisert

Re: Authz API Discussion (was re: svn commit: r770084)

Ean Schuessler schrieb:

[..]

> Now a completely separate issue is how we determine whether someone's changes are ready to go into the production repository. In a Linus style model, it would just be up to David and then maybe a lot of people would also follow Andy's branches closely (kind of like the Linux Realtime patch series). On the other hand, we could have some democratic +1 type thing going on about doing the merge.

Uh no, this isn't up for debate at the ASF ;-)
See http://www.apache.org/foundation/voting.html

--
Christian

BJ Freeman

Re: Authz API Discussion (was re: svn commit: r770084)

In reply to this post by Andrew Zeneski-2

I proposed the contributor model of branches in 2004, did not get much
support for it. someone can create their contribution for others to
evaluate when it is passed must they it can be voted on to be merged
with the trunk.
The value then, it would water down the trunk contributions.

Ean Schuessler sent the following on 5/4/2009 9:03 AM:

> ----- "Adam Heath" wrote:
>> Adam Heath wrote:
>>> Have you considered doing a git or mercurial branch of all these changes?
>> hg clone http://hg.webslinger.org/hg/ofbiz.apache.org/
>
> This situation underscores a discussion that David and I were having about distributed development. Andy's changes are a great example of the utility of the "pull" model implied by GIT and Hg. Andy could make all of his changes in some public "Andy" repo and then tell David to check them out. If David thinks the changes are ready then he can pull them into his repo. Even if David doesn't think they are ready, if some of us think Andy's patches are useful and want to play along then we can sync our repositories with his and use his code.
>
> Now a completely separate issue is how we determine whether someone's changes are ready to go into the production repository. In a Linus style model, it would just be up to David and then maybe a lot of people would also follow Andy's branches closely (kind of like the Linux Realtime patch series). On the other hand, we could have some democratic +1 type thing going on about doing the merge.
>
> In any case, the distributed model affords a lot of flexibility without people feeling like toes are getting stepped on.
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

David E Jones-3

Moderation and Sandboxing (was: Authz API Discussion)

In reply to this post by Christian Geisert

On May 4, 2009, at 10:53 AM, Christian Geisert wrote:

> Ean Schuessler schrieb:
>
> [..]
>
>> Now a completely separate issue is how we determine whether
>> someone's changes are ready to go into the production repository.
>> In a Linus style model, it would just be up to David and then maybe
>> a lot of people would also follow Andy's branches closely (kind of
>> like the Linux Realtime patch series). On the other hand, we could
>> have some democratic +1 type thing going on about doing the merge.
>
> Uh no, this isn't up for debate at the ASF ;-)
> See http://www.apache.org/foundation/voting.html

Just to be clear I'm not really interested in that sort of role either
way.

It's an interesting model for the Linux kernel where more moderation
is probably in order, but I'm not sure it would be best for OFBiz...
and if it were you'd have to find another volunteer. At the minute I'm
so swamped with requests for feedback and watching commits as much as
I can that I simply can't keep up. This is one of the reasons I've
been encouraging others to review commits more and basically look for
problems because pretty much every patch has them, and I'll admit I
usually don't say anything because it's not a big enough issue at the
time.

Anyway, I do think a more open model is better, especially for a
project like OFBiz. My personal preference is to lead by example (or
by exception to example to demonstrate BAD practices, like by recent
following suit for the security stuff and not discussing before
committing, ie in many cases Commit-Then-Review is an evil thing), and
by principle, which is why I wrote what I wrote in the committers
roles and responsibilities doc:

http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities

What I mean by that is the "first do no harm" and "read before you
write" recommendations. It's hard enough for all of us to get along,
and when those rules (or recommendations...) are not followed it
aggravates things a LOT.

Back to Ean's point though: there is NO reason to hurry most things,
especially big changes like that have an effect on the ENTIRE project
and involve non-backwards-compatible changes that force data migration
when updating. It's FAR better to develop it in a way that doesn't
affect or break anything but that allows other people to check it out
and offer feedback. If that can be done in the trunk then I think it's
fine (the worst case scenario is you have to remove it) otherwise a
branch in the SVN repository, a patch in a Jira issue, or something
like Mercurial or GIT repos are a great way to go.

-David

Andrew Zeneski-2

Re: Domain Based Security ( was re: Authz...)

In reply to this post by Adrian Crum-2

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:

Ean Schuessler

Re: Authz API Discussion (was re: svn commit: r770084)

In reply to this post by Andrew Zeneski-2

I don't think the ASF imposes any kind of "vote per trunk commit" model for revision control.

----- "Christian Geisert" wrote:
> Uh no, this isn't up for debate at the ASF ;-)
> See http://www.apache.org/foundation/voting.html

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315

1 ... 345678