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" <adrian.c...@yahoo.com> wrote: > My design document is nearly complete. I just need to finish the > artifact reuse section. > > -Adrian > > > --- On Sun, 5/10/09, Tim Ruppert <tim.rupp...@hotwaxmedia.com> wrote: > > > From: Tim Ruppert <tim.rupp...@hotwaxmedia.com> > > Subject: Re: Authz API Discussion (was re: svn commit: r770084) > > To: dev@ofbiz.apache.org > > 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" > > <jacques.le.r...@les7arts.com> 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" > > <andrew.zene...@hotwaxmedia.com> > > > > 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 > > > >
