You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@yahoo.com> on 2009/05/04 01:26:59 UTC
Re: Domain Based Security ( was re: Authz...)
--- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> 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 <security> element. Following the picture analogy, each <security> 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 <security> 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
Re: Domain Based Security ( was re: Authz...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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 <ad...@yahoo.com>
> 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 <an...@hotwaxmedia.com>
>> wrote:
>>
>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>> 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
>>> <an...@hotwaxmedia.com> 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...)
Posted by Adrian Crum <ad...@hlmksw.com>.
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...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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...)
Posted by Adrian Crum <ad...@hlmksw.com>.
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 <ad...@yahoo.com> 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 <an...@hotwaxmedia.com> wrote:
>>
>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>> 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
>>> <an...@hotwaxmedia.com> 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...)
Posted by Al Byers <by...@automationgroups.com>.
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 <ad...@yahoo.com> 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 <an...@hotwaxmedia.com> wrote:
>
> > From: Andrew Zeneski <an...@hotwaxmedia.com>
> > 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
> > <an...@hotwaxmedia.com> 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...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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 <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> 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
>> <an...@hotwaxmedia.com> 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...)
Posted by David E Jones <da...@hotwaxmedia.com>.
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 <an...@hotwaxmedia.com>
>> wrote:
>>
>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>> 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
>>> <an...@hotwaxmedia.com> 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...)
Posted by Anil Patel <an...@hotwaxmedia.com>.
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" <an...@hotwaxmedia.com>
> To: dev@ofbiz.apache.org
> Cc: "Anil Patel" <An...@hotwaxmedia.com>
> 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 <an...@hotwaxmedia.com>
>> wrote:
>>
>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>> 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
>>> <an...@hotwaxmedia.com> 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...)
Posted by BJ Freeman <bj...@free-man.net>.
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" <an...@hotwaxmedia.com>
>> To: dev@ofbiz.apache.org
>> Cc: "Anil Patel" <An...@hotwaxmedia.com>
>> 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 <an...@hotwaxmedia.com>
>>> wrote:
>>>
>>>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>>>> 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
>>>> <an...@hotwaxmedia.com> 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.
Re: Domain Based Security ( was re: Authz...)
Posted by Vince Clark <vc...@globalera.com>.
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" <an...@hotwaxmedia.com>
To: dev@ofbiz.apache.org
Cc: "Anil Patel" <An...@hotwaxmedia.com>
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 <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> 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
>> <an...@hotwaxmedia.com> 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...)
Posted by Anil Patel <an...@hotwaxmedia.com>.
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 <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> 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
>> <an...@hotwaxmedia.com> 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...)
Posted by Adrian Crum <ad...@hlmksw.com>.
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...)
Posted by David E Jones <da...@hotwaxmedia.com>.
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" <ad...@yahoo.com> 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 <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> 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
>> <an...@hotwaxmedia.com> 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...)
Posted by Sam Hamilton <sa...@virtualvillage.com>.
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" <ad...@yahoo.com> 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 <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> 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
> <an...@hotwaxmedia.com> 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...)
Posted by Adrian Crum <ad...@yahoo.com>.
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 <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> 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
> <an...@hotwaxmedia.com> 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...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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 <an...@hotwaxmedia.com>
> 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...)
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sun, 5/3/09, Andrew Zeneski <an...@hotwaxmedia.com> 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...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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 <an...@hotwaxmedia.com>
> wrote:
>
>> From: Andrew Zeneski <an...@hotwaxmedia.com>
>> 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...)
Posted by Adrian Crum <ad...@yahoo.com>.
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 <an...@hotwaxmedia.com> wrote:
> From: Andrew Zeneski <an...@hotwaxmedia.com>
> 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...)
Posted by Andrew Zeneski <an...@hotwaxmedia.com>.
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.