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

[Jacques Le Roux]

From: "Andrew Zeneski" <[hidden email]>
...snip...
> The new authz implementation handles all of this for us. First we  define the permissions, access:example, update:example and
> delete:example as seed data. These are also attached to the example  admin user's security group.
>
> We will give all users  access:example permission so they can access  the application, but only give admins the update and delete
> permissions.
...snip...

Andrew,

I'm stil thinking at my question about read and access differences. Why are you using access above, and in which cases read would be
used ? I have the feeling that we don't need access (or read maybe)

Here is a link to your answer http://docs.ofbiz.org/display/~jaz/OFBiz+Security+Refactor#comment-7705 and the
difference it's still not totally clear to me. Is *read for services* and *access for UI only* ?

Jacques
PS : Ha, I did not had a look at the example component yet, I better understand now, acces looks like the old OFBTOOLS... But could
you please explain more how read will be used ?

[Andrew Zeneski-2]

Jacques,

Honestly, in my initial plan I only had 4 permissions  
create,read,update and delete. Then after thinking about it, access  
seemed to be a nice extra permission to limit access to applications.  
Read is nothing more than what view is today, the only reason for  
using the name "read" instead of "view" is because we can call them  
CRUD permissions or ACRUD permissions if we keep access.

So, access was added only for granting access to the application. In  
most cases this is the only permission a user would need to access an  
app. Let's use Project Manger as an example for this:

access:project would be the permission required to access the  
application. All users of the app would have this permission. The  
create:project permission would be given to a administrator, so new  
projects could be created same with create:project:task. However,  
create:project:task would have some dynamic access logic associated  
which would allow users to create tasks as long as they were  
associated with a project in certain role(s).  The read:project  
permission could be used to restrict viewing details of a project,  
task, etc.

This is just how I have been thinking of it, read could also be used  
in replace of access, I just thought it would be more flexible to have  
the extra permission. Mainly because I believe that most users only  
need a permission to access the application, the other permissions  
would be handled in a dynamic way based on how the user is associated  
in the application.

Does this make any sense? Let me know if I am just confusing you more  
and I'll try again.

Andrew

On May 2, 2009, at 1:25 PM, Jacques Le Roux wrote:

> From: "Andrew Zeneski" <[hidden email]>
> ...snip...
>> The new authz implementation handles all of this for us. First we  
>> define the permissions, access:example, update:example and
>> delete:example as seed data. These are also attached to the  
>> example  admin user's security group.
>>
>> We will give all users  access:example permission so they can  
>> access  the application, but only give admins the update and delete
>> permissions.
> ...snip...
>
> Andrew,
>
> I'm stil thinking at my question about read and access differences.  
> Why are you using access above, and in which cases read would be
> used ? I have the feeling that we don't need access (or read maybe)
>
> Here is a link to your answer http://docs.ofbiz.org/display/~jaz/ 
> OFBiz+Security+Refactor#comment-7705 and the
> difference it's still not totally clear to me. Is *read for  
> services* and *access for UI only* ?
>
> Jacques
> PS : Ha, I did not had a look at the example component yet, I better  
> understand now, acces looks like the old OFBTOOLS... But could you  
> please explain more how read will be used ?
>
>
>
>

[Jacques Le Roux]

Hi Andrew,

inline...

From: "Andrew Zeneski" <[hidden email]>
> Jacques,
>
> Honestly, in my initial plan I only had 4 permissions  create,read,update and delete. Then after thinking about it, access  seemed
> to be a nice extra permission to limit access to applications.  Read is nothing more than what view is today, the only reason for
> using the name "read" instead of "view" is because we can call them  CRUD permissions or ACRUD permissions if we keep access.

Yes I see, we need something like OFBTOOLS was used for.
But can't we use simply read for that. It seems to me that access introduce redudancy.
What would be the differences between, for instance
access:sfa vs read:sfa
access:sfa:lead vs read:sfa:lead
access:sfa:opportunity vs read:sfa:opportunity
etc.


> So, access was added only for granting access to the application. In  most cases this is the only permission a user would need to
> access an  app. Let's use Project Manger as an example for this:
>
> access:project would be the permission required to access the  application. All users of the app would have this permission. The
> create:project permission would be given to a administrator, so new  projects could be created same with create:project:task.
> However,  create:project:task would have some dynamic access logic associated  which would allow users to create tasks as long as
> they were  associated with a project in certain role(s).  The read:project  permission could be used to restrict viewing details
> of a project,  task, etc.

But could we not use read:project instead of access:project, and then keep only the CRUD permissions ?
What we will be missing if we remove access ?

> This is just how I have been thinking of it, read could also be used  in replace of access, I just thought it would be more
> flexible to have  the extra permission. Mainly because I believe that most users only  need a permission to access the
> application, the other permissions  would be handled in a dynamic way based on how the user is associated  in the application.

Could you please elaborate on the extra permission and why it's needed ?

Thanks

Jacques

> Does this make any sense? Let me know if I am just confusing you more  and I'll try again.
>
> Andrew
>
> On May 2, 2009, at 1:25 PM, Jacques Le Roux wrote:
>
>> From: "Andrew Zeneski" <[hidden email]>
>> ...snip...
>>> The new authz implementation handles all of this for us. First we   define the permissions, access:example, update:example and
>>> delete:example as seed data. These are also attached to the  example  admin user's security group.
>>>
>>> We will give all users  access:example permission so they can  access  the application, but only give admins the update and
>>> delete
>>> permissions.
>> ...snip...
>>
>> Andrew,
>>
>> I'm stil thinking at my question about read and access differences.  Why are you using access above, and in which cases read
>> would be
>> used ? I have the feeling that we don't need access (or read maybe)
>>
>> Here is a link to your answer http://docs.ofbiz.org/display/~jaz/ OFBiz+Security+Refactor#comment-7705 and the
>> difference it's still not totally clear to me. Is *read for  services* and *access for UI only* ?
>>
>> Jacques
>> PS : Ha, I did not had a look at the example component yet, I better  understand now, acces looks like the old OFBTOOLS... But
>> could you  please explain more how read will be used ?
>>
>>
>>
>>
>

[Andrew Zeneski-2]

Jacques,

Thanks for your questions. I will address each one inline...

>> Honestly, in my initial plan I only had 4 permissions  
>> create,read,update and delete. Then after thinking about it,  
>> access  seemed
>> to be a nice extra permission to limit access to applications.  
>> Read is nothing more than what view is today, the only reason for
>> using the name "read" instead of "view" is because we can call  
>> them  CRUD permissions or ACRUD permissions if we keep access.
>
> Yes I see, we need something like OFBTOOLS was used for.
> But can't we use simply read for that. It seems to me that access  
> introduce redudancy.
> What would be the differences between, for instance
> access:sfa vs read:sfa
> access:sfa:lead vs read:sfa:lead
> access:sfa:opportunity vs read:sfa:opportunity
> etc.
>

access:sfa would mean that the user can simply access the application.  
Where read:sfa would mean, the user can read anything in the SFA  
application. A better example of this would be the order manager,  
where access:order would allow the user to login, but read:order would  
allow the user to view any order/request/etc in the application. A  
more granular permission of read:order:orderdetail:10000 would limit  
the user to only reading the specific order without granting  
permission to the rest of orders/requests/etc.

I would not recommend creating granular permissions for access, unless  
we wanted to limit the access of specific "tabs" or areas in an  
application. If we wanted to restrict access to leads in sfa, then we  
might create an access:sfa:lead process/permission which can then be  
used to restrict access to the leads section of the app. Where as  
read:sfa:lead would mean the user can view any lead.

>
>> So, access was added only for granting access to the application.  
>> In  most cases this is the only permission a user would need to
>> access an  app. Let's use Project Manger as an example for this:
>>
>> access:project would be the permission required to access the  
>> application. All users of the app would have this permission. The
>> create:project permission would be given to a administrator, so  
>> new  projects could be created same with create:project:task.
>> However,  create:project:task would have some dynamic access logic  
>> associated  which would allow users to create tasks as long as
>> they were  associated with a project in certain role(s).  The  
>> read:project  permission could be used to restrict viewing details
>> of a project,  task, etc.
>
> But could we not use read:project instead of access:project, and  
> then keep only the CRUD permissions ?
> What we will be missing if we remove access ?

I don't think so. Because read:project would grant the user global  
read access to all projects. Instead, when displaying a project we  
might want to attach the process of read:project:10000 to the UI, to  
verify the user is indeed allow to read that project. Where  
access:project would just simply allow the user to login to the tool.

>
>> This is just how I have been thinking of it, read could also be  
>> used  in replace of access, I just thought it would be more
>> flexible to have  the extra permission. Mainly because I believe  
>> that most users only  need a permission to access the
>> application, the other permissions  would be handled in a dynamic  
>> way based on how the user is associated  in the application.
>
> Could you please elaborate on the extra permission and why it's  
> needed ?
>

I think I elaborated in the above two comments, so if this is still  
vague please let me know and I will try to explain it again in a  
different way.

Thanks again for your questions!

Andrew

[Jacques Le Roux]

Hi Andrew,

Thanks for your answer and your time on this important subject that should benefit to all the community!

I had not much time these last days to follow, and I'm still have to read some messages (notably the couple of threads David opened
lastly).
Thanks to everybody's explanations, my understanding is really better now.
So from you explanation below I understand that, as I supposed at the beginning, it's a kind of OFBTOOLS.
Not exactly since you need to have OFBTOOLS to gain access to a component while you don't need to have access. On the other hand if
you have access you have access to this component.

Though at this time I did not have a very good understanding (and I'm sure I still miss some points, but hopefully not about access
;o), I have discussed about access a bit with a client.
Of course everybody using the ERP side of OFBiz is *very interested* by access auth. and by all possible improvments of this central
feature.
He gave me an idea, while we were discussing about possible reason of the access introduction.
As he knew even less than me his interpretation was not right (I was already able to explain why) but his conclusion is interesting.
He suggested that this may be used to grant all other rights (CRUD ones). So it would allow to quicly set all other permissions

What do you think about such a possibility ? A kind of ADMIN stuff. We could call it "All".

Also he wondered why we would differentiate create from update. I gave him some examples (like an automatic task able to create but
not to change) but he was not very convinced.
I then said that this is used by Unix file systems too. It's subjective but when you refer to Unix/Linux file systems it helps
people to "understand".
Afterward I thought that maybe we could also have a look at how access control is managed there. After all files are kind of
artifacts, and  Linux files systems are known as efficient...
Of course the problematic for files access is far less complex and I don't say it's a paradigm, but we may find some ideas (if we
need ones at some point).
For instance, it's pretty clear that all files store their own permissions and all have a combination of them. But I feel anyway
that this is a bit out of topic :/
Though Adrian is drawing his proposal by looking at Novel Netware, IRRW.

Jacques

From: "Andrew Zeneski" <[hidden email]>

> Jacques,
>
> Thanks for your questions. I will address each one inline...
>
>>> Honestly, in my initial plan I only had 4 permissions   create,read,update and delete. Then after thinking about it,  access
>>> seemed
>>> to be a nice extra permission to limit access to applications.   Read is nothing more than what view is today, the only reason
>>> for
>>> using the name "read" instead of "view" is because we can call  them  CRUD permissions or ACRUD permissions if we keep access.
>>
>> Yes I see, we need something like OFBTOOLS was used for.
>> But can't we use simply read for that. It seems to me that access  introduce redudancy.
>> What would be the differences between, for instance
>> access:sfa vs read:sfa
>> access:sfa:lead vs read:sfa:lead
>> access:sfa:opportunity vs read:sfa:opportunity
>> etc.
>>
>
> access:sfa would mean that the user can simply access the application.  Where read:sfa would mean, the user can read anything in
> the SFA  application. A better example of this would be the order manager,  where access:order would allow the user to login, but
> read:order would  allow the user to view any order/request/etc in the application. A  more granular permission of
> read:order:orderdetail:10000 would limit  the user to only reading the specific order without granting  permission to the rest of
> orders/requests/etc.
>
> I would not recommend creating granular permissions for access, unless  we wanted to limit the access of specific "tabs" or areas
> in an  application. If we wanted to restrict access to leads in sfa, then we  might create an access:sfa:lead process/permission
> which can then be  used to restrict access to the leads section of the app. Where as  read:sfa:lead would mean the user can view
> any lead.
>
>
>>
>>> So, access was added only for granting access to the application.  In  most cases this is the only permission a user would need
>>> to
>>> access an  app. Let's use Project Manger as an example for this:
>>>
>>> access:project would be the permission required to access the   application. All users of the app would have this permission.
>>> The
>>> create:project permission would be given to a administrator, so  new  projects could be created same with create:project:task.
>>> However,  create:project:task would have some dynamic access logic  associated  which would allow users to create tasks as long
>>> as
>>> they were  associated with a project in certain role(s).  The  read:project  permission could be used to restrict viewing
>>> details
>>> of a project,  task, etc.
>>
>> But could we not use read:project instead of access:project, and  then keep only the CRUD permissions ?
>> What we will be missing if we remove access ?
>
> I don't think so. Because read:project would grant the user global  read access to all projects. Instead, when displaying a
> project we  might want to attach the process of read:project:10000 to the UI, to  verify the user is indeed allow to read that
> project. Where  access:project would just simply allow the user to login to the tool.
>
>>
>>> This is just how I have been thinking of it, read could also be  used  in replace of access, I just thought it would be more
>>> flexible to have  the extra permission. Mainly because I believe  that most users only  need a permission to access the
>>> application, the other permissions  would be handled in a dynamic  way based on how the user is associated  in the application.
>>
>> Could you please elaborate on the extra permission and why it's  needed ?
>>
>
> I think I elaborated in the above two comments, so if this is still  vague please let me know and I will try to explain it again
> in a  different way.
>
> Thanks again for your questions!
>
> Andrew
>

[Tim Ruppert]

Bump - looks like we let this get away from us as a discussion.  We can all agree that the current security system that is in place has some definite areas for improvement - and I think we're getting some where with this discussion - but I don't want it to lose steam in the community since there's a definite deficiency that needs to be address.

I'm hoping to see a bit more action on this front from everyone since there was so much discussion about it.  I know that Adrian's working on his design thoughts, Andrew's obviously already put his up there for discussion, David started a couple of threads to elicit information from more people about requirements, and Adam / Jacques / Anil / etc participated in the discussion.  

Let's get back to this - the system needs it!

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

----- "Jacques Le Roux" <[hidden email]> wrote:

> Hi Andrew,
>
> Thanks for your answer and your time on this important subject that
> should benefit to all the community!
>
> I had not much time these last days to follow, and I'm still have to
> read some messages (notably the couple of threads David opened
> lastly).
> Thanks to everybody's explanations, my understanding is really better
> now.
> So from you explanation below I understand that, as I supposed at the
> beginning, it's a kind of OFBTOOLS.
> Not exactly since you need to have OFBTOOLS to gain access to a
> component while you don't need to have access. On the other hand if
> you have access you have access to this component.
>
> Though at this time I did not have a very good understanding (and I'm
> sure I still miss some points, but hopefully not about access
> ;o), I have discussed about access a bit with a client.
> Of course everybody using the ERP side of OFBiz is *very interested*
> by access auth. and by all possible improvments of this central
> feature.
> He gave me an idea, while we were discussing about possible reason of
> the access introduction.
> As he knew even less than me his interpretation was not right (I was
> already able to explain why) but his conclusion is interesting.
> He suggested that this may be used to grant all other rights (CRUD
> ones). So it would allow to quicly set all other permissions
>
> What do you think about such a possibility ? A kind of ADMIN stuff. We
> could call it "All".
>
> Also he wondered why we would differentiate create from update. I gave
> him some examples (like an automatic task able to create but
> not to change) but he was not very convinced.
> I then said that this is used by Unix file systems too. It's
> subjective but when you refer to Unix/Linux file systems it helps
> people to "understand".
> Afterward I thought that maybe we could also have a look at how access
> control is managed there. After all files are kind of
> artifacts, and  Linux files systems are known as efficient...
> Of course the problematic for files access is far less complex and I
> don't say it's a paradigm, but we may find some ideas (if we
> need ones at some point).
> For instance, it's pretty clear that all files store their own
> permissions and all have a combination of them. But I feel anyway
> that this is a bit out of topic :/
> Though Adrian is drawing his proposal by looking at Novel Netware,
> IRRW.
>
> Jacques
>
> From: "Andrew Zeneski" <[hidden email]>
> > Jacques,
> >
> > Thanks for your questions. I will address each one inline...
> >
> >>> Honestly, in my initial plan I only had 4 permissions  
> create,read,update and delete. Then after thinking about it,  access
> >>> seemed
> >>> to be a nice extra permission to limit access to applications.  
> Read is nothing more than what view is today, the only reason
> >>> for
> >>> using the name "read" instead of "view" is because we can call
> them  CRUD permissions or ACRUD permissions if we keep access.
> >>
> >> Yes I see, we need something like OFBTOOLS was used for.
> >> But can't we use simply read for that. It seems to me that access
> introduce redudancy.
> >> What would be the differences between, for instance
> >> access:sfa vs read:sfa
> >> access:sfa:lead vs read:sfa:lead
> >> access:sfa:opportunity vs read:sfa:opportunity
> >> etc.
> >>
> >
> > access:sfa would mean that the user can simply access the
> application.  Where read:sfa would mean, the user can read anything
> in
> > the SFA  application. A better example of this would be the order
> manager,  where access:order would allow the user to login, but
> > read:order would  allow the user to view any order/request/etc in
> the application. A  more granular permission of
> > read:order:orderdetail:10000 would limit  the user to only reading
> the specific order without granting  permission to the rest of
> > orders/requests/etc.
> >
> > I would not recommend creating granular permissions for access,
> unless  we wanted to limit the access of specific "tabs" or areas
> > in an  application. If we wanted to restrict access to leads in sfa,
> then we  might create an access:sfa:lead process/permission
> > which can then be  used to restrict access to the leads section of
> the app. Where as  read:sfa:lead would mean the user can view
> > any lead.
> >
> >
> >>
> >>> So, access was added only for granting access to the application.
> In  most cases this is the only permission a user would need
> >>> to
> >>> access an  app. Let's use Project Manger as an example for this:
> >>>
> >>> access:project would be the permission required to access the  
> application. All users of the app would have this permission.
> >>> The
> >>> create:project permission would be given to a administrator, so
> new  projects could be created same with create:project:task.
> >>> However,  create:project:task would have some dynamic access logic
>  associated  which would allow users to create tasks as long
> >>> as
> >>> they were  associated with a project in certain role(s).  The
> read:project  permission could be used to restrict viewing
> >>> details
> >>> of a project,  task, etc.
> >>
> >> But could we not use read:project instead of access:project, and
> then keep only the CRUD permissions ?
> >> What we will be missing if we remove access ?
> >
> > I don't think so. Because read:project would grant the user global
> read access to all projects. Instead, when displaying a
> > project we  might want to attach the process of read:project:10000
> to the UI, to  verify the user is indeed allow to read that
> > project. Where  access:project would just simply allow the user to
> login to the tool.
> >
> >>
> >>> This is just how I have been thinking of it, read could also be
> used  in replace of access, I just thought it would be more
> >>> flexible to have  the extra permission. Mainly because I believe
> that most users only  need a permission to access the
> >>> application, the other permissions  would be handled in a dynamic
> way based on how the user is associated  in the application.
> >>
> >> Could you please elaborate on the extra permission and why it's
> needed ?
> >>
> >
> > I think I elaborated in the above two comments, so if this is still
> vague please let me know and I will try to explain it again
> > in a  different way.
> >
> > Thanks again for your questions!
> >
> > Andrew
> >

[Adrian Crum-2]

My design document is nearly complete. I just need to finish the artifact reuse section.

-Adrian


--- On Sun, 5/10/09, Tim Ruppert <[hidden email]> wrote:

> From: Tim Ruppert <[hidden email]>
> Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> To: [hidden email]
> Date: Sunday, May 10, 2009, 1:19 PM
> Bump - looks like we let this get away from us as a
> discussion.  We can all agree that the current security
> system that is in place has some definite areas for
> improvement - and I think we're getting some where with
> this discussion - but I don't want it to lose steam in
> the community since there's a definite deficiency that
> needs to be address.
>
> I'm hoping to see a bit more action on this front from
> everyone since there was so much discussion about it.  I
> know that Adrian's working on his design thoughts,
> Andrew's obviously already put his up there for
> discussion, David started a couple of threads to elicit
> information from more people about requirements, and Adam /
> Jacques / Anil / etc participated in the discussion.  
>
> Let's get back to this - the system needs it!
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> ----- "Jacques Le Roux"
> <[hidden email]> wrote:
>
> > Hi Andrew,
> >
> > Thanks for your answer and your time on this important
> subject that
> > should benefit to all the community!
> >
> > I had not much time these last days to follow, and
> I'm still have to
> > read some messages (notably the couple of threads
> David opened
> > lastly).
> > Thanks to everybody's explanations, my
> understanding is really better
> > now.
> > So from you explanation below I understand that, as I
> supposed at the
> > beginning, it's a kind of OFBTOOLS.
> > Not exactly since you need to have OFBTOOLS to gain
> access to a
> > component while you don't need to have access. On
> the other hand if
> > you have access you have access to this component.
> >
> > Though at this time I did not have a very good
> understanding (and I'm
> > sure I still miss some points, but hopefully not about
> access
> > ;o), I have discussed about access a bit with a
> client.
> > Of course everybody using the ERP side of OFBiz is
> *very interested*
> > by access auth. and by all possible improvments of
> this central
> > feature.
> > He gave me an idea, while we were discussing about
> possible reason of
> > the access introduction.
> > As he knew even less than me his interpretation was
> not right (I was
> > already able to explain why) but his conclusion is
> interesting.
> > He suggested that this may be used to grant all other
> rights (CRUD
> > ones). So it would allow to quicly set all other
> permissions
> >
> > What do you think about such a possibility ? A kind of
> ADMIN stuff. We
> > could call it "All".
> >
> > Also he wondered why we would differentiate create
> from update. I gave
> > him some examples (like an automatic task able to
> create but
> > not to change) but he was not very convinced.
> > I then said that this is used by Unix file systems
> too. It's
> > subjective but when you refer to Unix/Linux file
> systems it helps
> > people to "understand".
> > Afterward I thought that maybe we could also have a
> look at how access
> > control is managed there. After all files are kind of
> > artifacts, and  Linux files systems are known as
> efficient...
> > Of course the problematic for files access is far less
> complex and I
> > don't say it's a paradigm, but we may find
> some ideas (if we
> > need ones at some point).
> > For instance, it's pretty clear that all files
> store their own
> > permissions and all have a combination of them. But I
> feel anyway
> > that this is a bit out of topic :/
> > Though Adrian is drawing his proposal by looking at
> Novel Netware,
> > IRRW.
> >
> > Jacques
> >
> > From: "Andrew Zeneski"
> <[hidden email]>
> > > Jacques,
> > >
> > > Thanks for your questions. I will address each
> one inline...
> > >
> > >>> Honestly, in my initial plan I only had 4
> permissions  
> > create,read,update and delete. Then after thinking
> about it,  access
> > >>> seemed
> > >>> to be a nice extra permission to limit
> access to applications.  
> > Read is nothing more than what view is today, the only
> reason
> > >>> for
> > >>> using the name "read" instead
> of "view" is because we can call
> > them  CRUD permissions or ACRUD permissions if we keep
> access.
> > >>
> > >> Yes I see, we need something like OFBTOOLS
> was used for.
> > >> But can't we use simply read for that. It
> seems to me that access
> > introduce redudancy.
> > >> What would be the differences between, for
> instance
> > >> access:sfa vs read:sfa
> > >> access:sfa:lead vs read:sfa:lead
> > >> access:sfa:opportunity vs
> read:sfa:opportunity
> > >> etc.
> > >>
> > >
> > > access:sfa would mean that the user can simply
> access the
> > application.  Where read:sfa would mean, the user can
> read anything
> > in
> > > the SFA  application. A better example of this
> would be the order
> > manager,  where access:order would allow the user to
> login, but
> > > read:order would  allow the user to view any
> order/request/etc in
> > the application. A  more granular permission of
> > > read:order:orderdetail:10000 would limit  the
> user to only reading
> > the specific order without granting  permission to the
> rest of
> > > orders/requests/etc.
> > >
> > > I would not recommend creating granular
> permissions for access,
> > unless  we wanted to limit the access of specific
> "tabs" or areas
> > > in an  application. If we wanted to restrict
> access to leads in sfa,
> > then we  might create an access:sfa:lead
> process/permission
> > > which can then be  used to restrict access to the
> leads section of
> > the app. Where as  read:sfa:lead would mean the user
> can view
> > > any lead.
> > >
> > >
> > >>
> > >>> So, access was added only for granting
> access to the application.
> > In  most cases this is the only permission a user
> would need
> > >>> to
> > >>> access an  app. Let's use Project
> Manger as an example for this:
> > >>>
> > >>> access:project would be the permission
> required to access the  
> > application. All users of the app would have this
> permission.
> > >>> The
> > >>> create:project permission would be given
> to a administrator, so
> > new  projects could be created same with
> create:project:task.
> > >>> However,  create:project:task would have
> some dynamic access logic
> >  associated  which would allow users to create tasks
> as long
> > >>> as
> > >>> they were  associated with a project in
> certain role(s).  The
> > read:project  permission could be used to restrict
> viewing
> > >>> details
> > >>> of a project,  task, etc.
> > >>
> > >> But could we not use read:project instead of
> access:project, and
> > then keep only the CRUD permissions ?
> > >> What we will be missing if we remove access ?
> > >
> > > I don't think so. Because read:project would
> grant the user global
> > read access to all projects. Instead, when displaying
> a
> > > project we  might want to attach the process of
> read:project:10000
> > to the UI, to  verify the user is indeed allow to read
> that
> > > project. Where  access:project would just simply
> allow the user to
> > login to the tool.
> > >
> > >>
> > >>> This is just how I have been thinking of
> it, read could also be
> > used  in replace of access, I just thought it would be
> more
> > >>> flexible to have  the extra permission.
> Mainly because I believe
> > that most users only  need a permission to access the
> > >>> application, the other permissions  would
> be handled in a dynamic
> > way based on how the user is associated  in the
> application.
> > >>
> > >> Could you please elaborate on the extra
> permission and why it's
> > needed ?
> > >>
> > >
> > > I think I elaborated in the above two comments,
> so if this is still
> > vague please let me know and I will try to explain it
> again
> > > in a  different way.
> > >
> > > Thanks again for your questions!
> > >
> > > Andrew
> > >

     

[Tim Ruppert]

That's great news Adrian - looking forward to it!

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

----- "Adrian Crum" <[hidden email]> wrote:

> My design document is nearly complete. I just need to finish the
> artifact reuse section.
>
> -Adrian
>
>
> --- On Sun, 5/10/09, Tim Ruppert <[hidden email]> wrote:
>
> > From: Tim Ruppert <[hidden email]>
> > Subject: Re: Authz API Discussion (was re: svn commit: r770084)
> > To: [hidden email]
> > Date: Sunday, May 10, 2009, 1:19 PM
> > Bump - looks like we let this get away from us as a
> > discussion.  We can all agree that the current security
> > system that is in place has some definite areas for
> > improvement - and I think we're getting some where with
> > this discussion - but I don't want it to lose steam in
> > the community since there's a definite deficiency that
> > needs to be address.
> >
> > I'm hoping to see a bit more action on this front from
> > everyone since there was so much discussion about it.  I
> > know that Adrian's working on his design thoughts,
> > Andrew's obviously already put his up there for
> > discussion, David started a couple of threads to elicit
> > information from more people about requirements, and Adam /
> > Jacques / Anil / etc participated in the discussion.  
> >
> > Let's get back to this - the system needs it!
> >
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> >
> > o:801.649.6594
> > f:801.649.6595
> >
> > ----- "Jacques Le Roux"
> > <[hidden email]> wrote:
> >
> > > Hi Andrew,
> > >
> > > Thanks for your answer and your time on this important
> > subject that
> > > should benefit to all the community!
> > >
> > > I had not much time these last days to follow, and
> > I'm still have to
> > > read some messages (notably the couple of threads
> > David opened
> > > lastly).
> > > Thanks to everybody's explanations, my
> > understanding is really better
> > > now.
> > > So from you explanation below I understand that, as I
> > supposed at the
> > > beginning, it's a kind of OFBTOOLS.
> > > Not exactly since you need to have OFBTOOLS to gain
> > access to a
> > > component while you don't need to have access. On
> > the other hand if
> > > you have access you have access to this component.
> > >
> > > Though at this time I did not have a very good
> > understanding (and I'm
> > > sure I still miss some points, but hopefully not about
> > access
> > > ;o), I have discussed about access a bit with a
> > client.
> > > Of course everybody using the ERP side of OFBiz is
> > *very interested*
> > > by access auth. and by all possible improvments of
> > this central
> > > feature.
> > > He gave me an idea, while we were discussing about
> > possible reason of
> > > the access introduction.
> > > As he knew even less than me his interpretation was
> > not right (I was
> > > already able to explain why) but his conclusion is
> > interesting.
> > > He suggested that this may be used to grant all other
> > rights (CRUD
> > > ones). So it would allow to quicly set all other
> > permissions
> > >
> > > What do you think about such a possibility ? A kind of
> > ADMIN stuff. We
> > > could call it "All".
> > >
> > > Also he wondered why we would differentiate create
> > from update. I gave
> > > him some examples (like an automatic task able to
> > create but
> > > not to change) but he was not very convinced.
> > > I then said that this is used by Unix file systems
> > too. It's
> > > subjective but when you refer to Unix/Linux file
> > systems it helps
> > > people to "understand".
> > > Afterward I thought that maybe we could also have a
> > look at how access
> > > control is managed there. After all files are kind of
> > > artifacts, and  Linux files systems are known as
> > efficient...
> > > Of course the problematic for files access is far less
> > complex and I
> > > don't say it's a paradigm, but we may find
> > some ideas (if we
> > > need ones at some point).
> > > For instance, it's pretty clear that all files
> > store their own
> > > permissions and all have a combination of them. But I
> > feel anyway
> > > that this is a bit out of topic :/
> > > Though Adrian is drawing his proposal by looking at
> > Novel Netware,
> > > IRRW.
> > >
> > > Jacques
> > >
> > > From: "Andrew Zeneski"
> > <[hidden email]>
> > > > Jacques,
> > > >
> > > > Thanks for your questions. I will address each
> > one inline...
> > > >
> > > >>> Honestly, in my initial plan I only had 4
> > permissions  
> > > create,read,update and delete. Then after thinking
> > about it,  access
> > > >>> seemed
> > > >>> to be a nice extra permission to limit
> > access to applications.  
> > > Read is nothing more than what view is today, the only
> > reason
> > > >>> for
> > > >>> using the name "read" instead
> > of "view" is because we can call
> > > them  CRUD permissions or ACRUD permissions if we keep
> > access.
> > > >>
> > > >> Yes I see, we need something like OFBTOOLS
> > was used for.
> > > >> But can't we use simply read for that. It
> > seems to me that access
> > > introduce redudancy.
> > > >> What would be the differences between, for
> > instance
> > > >> access:sfa vs read:sfa
> > > >> access:sfa:lead vs read:sfa:lead
> > > >> access:sfa:opportunity vs
> > read:sfa:opportunity
> > > >> etc.
> > > >>
> > > >
> > > > access:sfa would mean that the user can simply
> > access the
> > > application.  Where read:sfa would mean, the user can
> > read anything
> > > in
> > > > the SFA  application. A better example of this
> > would be the order
> > > manager,  where access:order would allow the user to
> > login, but
> > > > read:order would  allow the user to view any
> > order/request/etc in
> > > the application. A  more granular permission of
> > > > read:order:orderdetail:10000 would limit  the
> > user to only reading
> > > the specific order without granting  permission to the
> > rest of
> > > > orders/requests/etc.
> > > >
> > > > I would not recommend creating granular
> > permissions for access,
> > > unless  we wanted to limit the access of specific
> > "tabs" or areas
> > > > in an  application. If we wanted to restrict
> > access to leads in sfa,
> > > then we  might create an access:sfa:lead
> > process/permission
> > > > which can then be  used to restrict access to the
> > leads section of
> > > the app. Where as  read:sfa:lead would mean the user
> > can view
> > > > any lead.
> > > >
> > > >
> > > >>
> > > >>> So, access was added only for granting
> > access to the application.
> > > In  most cases this is the only permission a user
> > would need
> > > >>> to
> > > >>> access an  app. Let's use Project
> > Manger as an example for this:
> > > >>>
> > > >>> access:project would be the permission
> > required to access the  
> > > application. All users of the app would have this
> > permission.
> > > >>> The
> > > >>> create:project permission would be given
> > to a administrator, so
> > > new  projects could be created same with
> > create:project:task.
> > > >>> However,  create:project:task would have
> > some dynamic access logic
> > >  associated  which would allow users to create tasks
> > as long
> > > >>> as
> > > >>> they were  associated with a project in
> > certain role(s).  The
> > > read:project  permission could be used to restrict
> > viewing
> > > >>> details
> > > >>> of a project,  task, etc.
> > > >>
> > > >> But could we not use read:project instead of
> > access:project, and
> > > then keep only the CRUD permissions ?
> > > >> What we will be missing if we remove access ?
> > > >
> > > > I don't think so. Because read:project would
> > grant the user global
> > > read access to all projects. Instead, when displaying
> > a
> > > > project we  might want to attach the process of
> > read:project:10000
> > > to the UI, to  verify the user is indeed allow to read
> > that
> > > > project. Where  access:project would just simply
> > allow the user to
> > > login to the tool.
> > > >
> > > >>
> > > >>> This is just how I have been thinking of
> > it, read could also be
> > > used  in replace of access, I just thought it would be
> > more
> > > >>> flexible to have  the extra permission.
> > Mainly because I believe
> > > that most users only  need a permission to access the
> > > >>> application, the other permissions  would
> > be handled in a dynamic
> > > way based on how the user is associated  in the
> > application.
> > > >>
> > > >> Could you please elaborate on the extra
> > permission and why it's
> > > needed ?
> > > >>
> > > >
> > > > I think I elaborated in the above two comments,
> > so if this is still
> > > vague please let me know and I will try to explain it
> > again
> > > > in a  different way.
> > > >
> > > > Thanks again for your questions!
> > > >
> > > > Andrew
> > > >