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