Re: [Repoze-dev] Model-based vs. view-based security
Hi Tim, |--== On Thu, 29 Jul 2010 07:36:57 +0800, Tim Hoffman zutes...@gmail.com said: TH Hi 2) With the security proxy machinery I can have a view that conditionally displays certain HTML elements (like form fields) depending on the permissions that the accessing user has on the context object. TH I too came to bfg from zope2 and zope 3 and was used to model based TH security, TH however the complete disconnection of forms from models in bfg is just TH fantastic ;-) Yeah, I'm fascinated by that as well, and I'm trying to understand how it could fit the requirements I need to meet. TH I always found that whilst forms tied to the model was nice for simple TH things (ala basic crud) the minute TH you had complex forms (aggregate forms, forms with no model etc) that the TH tight binding of model and form was TH a big pain. Separating form from model has been a real godsend for some of TH my latest projects. I agree that model objects and forms are not generally tight together, even though I'd argue that virtually every web application will need basic CRUD for the core entities. TH I use a UML modeling tool to generate all my models and form schemas so I TH tend not to write much code in these entities. That's interesting, any pointer/link for this specific tool? TH I personally think the form schema is much more about the view than the TH model. Sure, however I believe the issue I was raising is orthogonal to this one. Regardless how tight or loosely the form schema is bound to the model, the authorization for a view in Repoze.bfg can effectively be only True or False, which is simple and nice, but sometimes doesn't fit what you need to do. Let's make an example. You have a web application for sharing drawings, you can upload drawings and for each drawing decide which other users you want to share that drawing with. If you share a drawing with another person, that other person can perform the same operations as you on it, like tagging it or removing it. Now let's say that you have views that act on collections of drawings, like you could have a view for handling an HTTP request for tagging a certain group of drawings or deleting them. The HTTP request for those views would typically have a parameter holding a list for drawing IDs to act on. How do you define the permission on those views? With a model-based permissions system, you would simply make the view public and let the model raise Unauthorized if you attempt to do something on a drawing you don't have access too. However with a view-based permission system you need to use some other pattern, and I'm not sure what would be best. Cheers, Free ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Model-based vs. view-based security
Hi Chris, |--== On Wed, 28 Jul 2010 12:38:30 -0400, Chris McDonough chr...@plope.com said: CM Thanks for asking this question, by the way, I have added it (and a CM variation on my answer) to the design defense documentation that is CM present in BFG: CM http://lists.repoze.org/pipermail/repoze-checkins/2010-July/009583.html CM (The rendered version, which doesn't yet include the above addition is CM available at http://docs.repoze.org/bfg/1.3/designdefense.html). That's great to have it there, I hope others will benefit from that reading. As a side node, I really appreciate the documentation effort in Repoze.bfg. Cheers, Free ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Model-based vs. view-based security
Am 29.07.2010, 10:25 Uhr, schrieb Free Ekanayaka free.ekanay...@gmail.com: I agree that model objects and forms are not generally tight together, even though I'd argue that virtually every web application will need basic CRUD for the core entities. Form inference via schema adapter should be possible but I think there is consensus that interfaces that are schemas can cause more problems than they solve. Convenience versus overhead and confusion. TH I use a UML modeling tool to generate all my models and form schemas so I TH tend not to write much code in these entities. That's interesting, any pointer/link for this specific tool? TH I personally think the form schema is much more about the view than the TH model. Sure, however I believe the issue I was raising is orthogonal to this one. Regardless how tight or loosely the form schema is bound to the model, the authorization for a view in Repoze.bfg can effectively be only True or False, which is simple and nice, but sometimes doesn't fit what you need to do. In those cases you are free to add more to it such as, as Chris said, security proxies. Making this standard adds a lot of overhead to cases where it is totally irrelevant. NB. BFG's openness with regard to storage means you have to think about non-ZODB environments if you wish to have object-level security. Let's make an example. You have a web application for sharing drawings, you can upload drawings and for each drawing decide which other users you want to share that drawing with. If you share a drawing with another person, that other person can perform the same operations as you on it, like tagging it or removing it. Now let's say that you have views that act on collections of drawings, like you could have a view for handling an HTTP request for tagging a certain group of drawings or deleting them. The HTTP request for those views would typically have a parameter holding a list for drawing IDs to act on. How do you define the permission on those views? With a model-based permissions system, you would simply make the view public and let the model raise Unauthorized if you attempt to do something on a drawing you don't have access too. However with a view-based permission system you need to use some other pattern, and I'm not sure what would be best. I would think you would need to add something to your application to handle this (something akin to workflow) but I don't see why you can't stick with security. BFG provides all the necessary hooks for fine-grained security. Regarding Maartijn's discussion of configuration close to the objects. Having grown up with Zope 2 I'm not keen to see declareProtected(), etc. return for this even if you have decorators. Much better, in my view, to have adapters and views implement behaviour and secure these. I guess the only thing that's missing is security aware form generation, ie. the ability to lock down parts of the form. With a form generation library such as deform this can be done at the view level, although it's not ideal. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Model-based vs. view-based security
Hi TH I use a UML modeling tool to generate all my models and form schemas so I TH tend not to write much code in these entities. That's interesting, any pointer/link for this specific tool? I am using enterprise architect. http://www.sparxsystems.com.au/ It can actually reverse engineer and generate python, but its code lifecycle tools really need some customising (in tool) for python. EE will also reverse engineer (with full roundtrip) from RDBMS, WSDL, C, Java, C++, . . So I am using a code generation tool that I have written over the last few years (for another customer, so at the moment I can't release it, but am planning to rewrite it to target both argouml and enterprise architect). I am currently able to generate from the xmi files the following storm schema from a reverse engineered rdbms. zope3 model and schema bobo view/routes/subroutes (and some viewlet equivalents - basic zope component multi adapter lookup of view fragments, based on context, request, user, view) bfg models formish form schema. postresql DDL. code generation templates are based on dtml. Conceptually its inspired by archgenxml but I found it too difficult to repurpose archgenxml for completely different purposes. Rgds T ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Model-based vs. view-based security
On Wed, 2010-07-28 at 16:58 +0200, Free Ekanayaka wrote: Hi, I'm starting to explore Repoze.bfg and I find it great. Thanks for letting us know! Reading the documentation I gather that the default security model is view-based, that means the authorization policy is basically defined and checked at the view level. If I understand it correctly, an __acl__ attribute on a context object is used to determine which permissions does a certain user or principal have on the object itself, and then a view for that context can define a permission which the user needs to have on the context object in order to access the view itself. I find it nice to have the authorization policy defined and checked at the view level. However comparing this approach with the model-based one of Zope 3 (that wraps context objects with a security proxy) I can see a few shortcomings that I'm not sure how to deal with: 1) Let's say that I want to also expose my model via a REST API, and I want to use Twisted Web for that. Though I can probably reuse the __acl__ attributes on the model objects, I have to implement a new set of view-level authorization definitions for the API. On the other side using Zope3's security proxy, I would enforce my authorization policy both on Repoze.bfg's views and in the Twisted-based API transparently and in the same way. 2) With the security proxy machinery I can have a view that conditionally displays certain HTML elements (like form fields) depending on the permissions that the accessing user has on the context object. 3) Similarly to 2) I can also have a single view that processes a request with parameters for performing a set of modifications on certain context object. It might be that the accessing user doesn't have all the necessary permissions to perform the requested modifications, and the security proxy machinery would raise an Unauthorized, however if the accessing user is effectively requesting only modifications for which he has permissions, the request would succeed. Now, what would be the recommended approach to deal with such use-cases in Repoze.bfg? BFG was developed by folks familiar with Zope2, which has a throwugh the web security model which was the precursor to Zope 3's security proxies. At the time I started to write BFG, I had created many Zope 2 sites (along with my partners at Agendaless, and before that at Zope Corp). Over time, as we created these sites, we found authorization checks during code interpretation useful in some projects. But much of the time, those authorization checks usually slowed down the development velocity of projects that had no delegation requirements. In particular, if we weren't allowing untrusted users to write arbitrary Python code to be executed by our application, the burden of through the web security checks proved too costly. I personally haven't written an application on top of which untrusted developers are allowed to write code in many years. And since we tend to use the same toolkit for all web applications, it's just never been a concern to be able to use the same set of restricted-execution code under two web different frameworks. Would it possibly make sense to implement some repoze.what plugin for supporting Zope 3's security proxies? In general, given that Zope 3 security proxies are viral, it is possible to override the BFG traverser (see http://docs.repoze.org/bfg/1.3/narr/hooks.html#changing-the-traverser), plugging in a different traverser which returns security-proxy-wrapped objects. This would have the effect of creating a more Zope3-like environment without much effort. repoze.what is unrelated to BFG. See the Warning near the top of http://docs.repoze.org/bfg/1.3/narr/security.html . Grok seems to have opted for a view-based security model as well, by default, an interesting reading that touches some of the concerns expressed above can be found here: http://faassen.n--tree.net/blog/view/weblog/2008/04/17/0 Cheers! Free ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Model-based vs. view-based security
Thanks for asking this question, by the way, I have added it (and a variation on my answer) to the design defense documentation that is present in BFG: http://lists.repoze.org/pipermail/repoze-checkins/2010-July/009583.html (The rendered version, which doesn't yet include the above addition is available at http://docs.repoze.org/bfg/1.3/designdefense.html). On Wed, 2010-07-28 at 12:09 -0400, Chris McDonough wrote: On Wed, 2010-07-28 at 16:58 +0200, Free Ekanayaka wrote: Hi, I'm starting to explore Repoze.bfg and I find it great. Thanks for letting us know! Reading the documentation I gather that the default security model is view-based, that means the authorization policy is basically defined and checked at the view level. If I understand it correctly, an __acl__ attribute on a context object is used to determine which permissions does a certain user or principal have on the object itself, and then a view for that context can define a permission which the user needs to have on the context object in order to access the view itself. I find it nice to have the authorization policy defined and checked at the view level. However comparing this approach with the model-based one of Zope 3 (that wraps context objects with a security proxy) I can see a few shortcomings that I'm not sure how to deal with: 1) Let's say that I want to also expose my model via a REST API, and I want to use Twisted Web for that. Though I can probably reuse the __acl__ attributes on the model objects, I have to implement a new set of view-level authorization definitions for the API. On the other side using Zope3's security proxy, I would enforce my authorization policy both on Repoze.bfg's views and in the Twisted-based API transparently and in the same way. 2) With the security proxy machinery I can have a view that conditionally displays certain HTML elements (like form fields) depending on the permissions that the accessing user has on the context object. 3) Similarly to 2) I can also have a single view that processes a request with parameters for performing a set of modifications on certain context object. It might be that the accessing user doesn't have all the necessary permissions to perform the requested modifications, and the security proxy machinery would raise an Unauthorized, however if the accessing user is effectively requesting only modifications for which he has permissions, the request would succeed. Now, what would be the recommended approach to deal with such use-cases in Repoze.bfg? BFG was developed by folks familiar with Zope2, which has a throwugh the web security model which was the precursor to Zope 3's security proxies. At the time I started to write BFG, I had created many Zope 2 sites (along with my partners at Agendaless, and before that at Zope Corp). Over time, as we created these sites, we found authorization checks during code interpretation useful in some projects. But much of the time, those authorization checks usually slowed down the development velocity of projects that had no delegation requirements. In particular, if we weren't allowing untrusted users to write arbitrary Python code to be executed by our application, the burden of through the web security checks proved too costly. I personally haven't written an application on top of which untrusted developers are allowed to write code in many years. And since we tend to use the same toolkit for all web applications, it's just never been a concern to be able to use the same set of restricted-execution code under two web different frameworks. Would it possibly make sense to implement some repoze.what plugin for supporting Zope 3's security proxies? In general, given that Zope 3 security proxies are viral, it is possible to override the BFG traverser (see http://docs.repoze.org/bfg/1.3/narr/hooks.html#changing-the-traverser), plugging in a different traverser which returns security-proxy-wrapped objects. This would have the effect of creating a more Zope3-like environment without much effort. repoze.what is unrelated to BFG. See the Warning near the top of http://docs.repoze.org/bfg/1.3/narr/security.html . Grok seems to have opted for a view-based security model as well, by default, an interesting reading that touches some of the concerns expressed above can be found here: http://faassen.n--tree.net/blog/view/weblog/2008/04/17/0 Cheers! Free ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org
Re: [Repoze-dev] Model-based vs. view-based security
Hi 2) With the security proxy machinery I can have a view that conditionally displays certain HTML elements (like form fields) depending on the permissions that the accessing user has on the context object. I too came to bfg from zope2 and zope 3 and was used to model based security, however the complete disconnection of forms from models in bfg is just fantastic ;-) I always found that whilst forms tied to the model was nice for simple things (ala basic crud) the minute you had complex forms (aggregate forms, forms with no model etc) that the tight binding of model and form was a big pain. Separating form from model has been a real godsend for some of my latest projects. I use a UML modeling tool to generate all my models and form schemas so I tend not to write much code in these entities. I personally think the form schema is much more about the view than the model. Rgds T ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
