- Zope-Dev - Zope lists

Re: [Zope-dev] Enhancing Zope's security model
by David Jacobs 07 Jul '99

07 Jul '99

Hi Christopher! Nice to meet you. I hope I can be helpful to you. See responses below. ----- Original Message ----- From: Christopher Petrilli <petrilli(a)digicool.com> > Yes, that's my bag-o-tricks, and probably a big chunk of why I'm here... I > left Xcert's PKI consulting group to come to Digital Creations. I'll try > and make a broad stroke at some of the ideas that I've been thinking > about---it just takes time (or money). With respect to time, I have a day a week for the next 9 to 12 months to dedicate to the problem. I am pursuing my dissertation (course work is done :-) on creating a security model for web based applications and my company has given me a day off a week to work on it. Zope seemed the farthest along in providing the rest of the infrastructure a web based security model would require. I have a 20 year background in object oriented programming (mostly C++) and security but have not done much in Python. > Traditional web servers have no security MODEL :-) having said that, I can > only agree whole-heartedly here. One of the things I'm working on slowly > is creating a full UML model of the security model implemented in Zope. > Then we can better discuss changes to the model. I'm a big believer in > formalization of the security model, as opposed to the purely textual "well, > we check X here". What tool are you using for your UML modeling? I must admit I have not kept up with UML. The last time I was heavy into case tools was back in 1992 using Rational Rose when Booch and Co. where still duking it out over the icons and fomalisms. I would love to see what you have so far or even any notes you have electronically. > This is a good thing, it also is necessary as we begin to integrate some of > the concepts introduced in the PKI world. We've already started to work on > how do you define roles and fit anonymous users into them. Also, how do you > separate the identification stage from the authentication stage. For > example, the path of a user through the security model: > > 1. 100% anonymous, unknown person > 2. Identifiable anonymous person (same person, but not sure who) > 3. Identified person, but not authenticated > 4. I&A person, but not authorized > 5. Authorized > > At any point, you should be able to bind that "individual" to a role. I would add their location and the kind of authentication is also important. For example many sites, especially digital library sites use the user's ip domain to determine what role they are assigned to. You might also want to assign different roles based on whether they have authenticated with a password in the clear or a password over SSL or a client certificate (not sure if this is useful). > Now, as you talk about being able to define a "permission" that has > intelligence to it, and I'm not sure how to do that without having a huge > impact on performance, but it is an interesting idea, especially as you try > and translate X.509 certificate information (i.e. DN + LDAP) into a set of > Roles. I'm not sure which concept you were referring to here :-). > > Provide for resolution rules for when positive and negative authorization > > conflict. > > * (e.g. lower in the object hierarchy overrides inherited auths, negative > > overrides positive, order dependent) > > First glance says this is 1) largely accomplished by acquisition as it is, > 2) too complex if it isn't as it introduces yet another concept that the > user must grasp. I agree the utility versus complexity is pretty low. At most it might be useful to offer a couple of predefined resolution modes with hooks to allow people to put in their own if they really want it. > The single largest flaw with many security solutions is they aren't obvious, > and in their obtuosity they only create more problems. Perhaps I'm simply > not understanding this. Want to write some pseudo code, er... Python? I agree whole heartedly. If you read the literature, people have come up with some amazing languages for expressing authorizations in an object oriented fashion, but god help the poor user who has to actually write real world authorizations in those languages. My desire is to try and bring some of these concepts "down to earth" and make them useful. > > Allow time restrictions on user/role associations or method/role > > associations (duration or cyclical restrictions) > > * This would allow you to say Joe is a Manager from June 1 to June 30th. > > I can imagine this being useful. More importantly, Joe is only a manager > from 8am-5pm M-F. This is a very common thing. > > > * This would allow you to say the Pay Payroll method can only be run on > > Friday's. > > This is probably best enforced at the "application" layer as opposed to the > framework layer. But perhaps there should be a way to have a separation of > the security "check" from the DTML itself. I think we will find that many of the features we think up may not have broad appeal. While that may be reason enough not to make them a "standard" feature, I agree that the framwork should still support plugging in the functionality via an API or standard security "check" concept that you brought up. > > Allow actions to be associated with an authorization event. > > * on success (e.g. write audit entry in log) > > * on failure (e.g. write audit entry in log and call routine that checks for > > excessive failures and pages sys admin if over the threshold.send email) > > Perhaps exposure of the new ZLOG framework at the DTML level would be > useful? Simply use a <dtml-call "auditme('information here')"> ? Upon further reflection, I would change this a little. Instead of allowing arbitrary actions, I would restrict it to just auditing events. I still think it would be useful to abstract it out of the DTML level though. Wouldn't it be nice to be able to log SQLMethod's and other zope objects?. All analysis of the events would be the responsability of a process outside of Zope such as an intrusion/fraud detection system. > > Allow expressions that include object values to play in the authorization > > decision. > > * Given an expense voucher (EV) object, a 1st Level Manager can 'sign' (an > > EV method) if the EV.amount is less than $2500 and the EV.author is not the > > AUTHENTICATED_USER. > > Scared :-) Again, perhaps an abstract concept of a property on an object > that can on the *rare* occasion that it is needed could be called? Yes this is scary :-). It is also one of the most powerful. When you consider supporting almost any workflow based application, this becomes a necessity. This is because the state of an object often directly affects what and who can act on it. Thanks again for your response! David

1 0

Enhancing Zope's security model
by David Jacobs 07 Jul '99

07 Jul '99

Is anyone currently working on enhancing Zope's security model? Traditional web servers have horrible security model's for the application designer. They leave almost all the security work to be done by the application itself. With Zope abstracting all access into a nice object oriented fashion, much more powerful models are possible. What you guys have done with users, permissions and roles is already far ahead of other web servers. I am interested in taking it a step further to remove even more security code that currently resides in dtml scripts. My vision is to provide the following capabilities. Provide for positive and negative authorizations. * We may want to give a role Employees access to a method, but not if the user is also in the role Bad Boys. Provide for resolution rules for when positive and negative authorization conflict. * (e.g. lower in the object hierarchy overrides inherited auths, negative overrides positive, order dependent) Allow time restrictions on user/role associations or method/role associations (duration or cyclical restrictions) * This would allow you to say Joe is a Manager from June 1 to June 30th. * This would allow you to say the Pay Payroll method can only be run on Friday's. * This is useful in that you don't have to remember to remove Joe from the role. It also helps when looking at audit logs you can see that he was authorized to perform those functions during that time. Allow actions to be associated with an authorization event. * on success (e.g. write audit entry in log) * on failure (e.g. write audit entry in log and call routine that checks for excessive failures and pages sys admin if over the threshold.send email) Allow expressions that include object values to play in the authorization decision. * Given an expense voucher (EV) object, a 1st Level Manager can 'sign' (an EV method) if the EV.amount is less than $2500 and the EV.author is not the AUTHENTICATED_USER. What do people think? Does this functionality sound useful? Do certain features call louder than others. I believe these features will make Zope MUCH more attractive for developing intranet applications, which typically have much more complex security requirements than public web sites do. I realize that most if not all of these features can be accomplished by coding in dtml. I would like to see much of that abstracted out into the security interface so that security policies can be more easily changed. I also realize that besides implementation, there is also the problem of coming up with a reasonable user interface that does not swamp the average person with possibilities. Good default behavior is necessary, with the full complexity of options only showing if the application designer asks for it. I've started familiarizing myself with the source code but have a ways to go. Obviously I would be making lots of changes in the access control directory, but it looks like a lot of the security framework is also embedded into the Zope objects like Folder and Document Objects. Any tips on code to pay special attention to or code that I can safely ignore would be greatly appreciated. Thanks in advance for any comments. David Jacobs MITRE Corporation

2 2

Re: [Zope-dev] Enhancing Zope's security model
by Christopher Petrilli 07 Jul '99

07 Jul '99

> Is anyone currently working on enhancing Zope's security model? Yes, that's my bag-o-tricks, and probably a big chunk of why I'm here... I left Xcert's PKI consulting group to come to Digital Creations. I'll try and make a broad stroke at some of the ideas that I've been thinking about---it just takes time (or money). > Traditional web servers have horrible security model's for the application > designer. They leave almost all the security work to be done by the > application itself. With Zope abstracting all access into a nice object > oriented fashion, much more powerful models are possible. Traditional web servers have no security MODEL :-) having said that, I can only agree whole-heartedly here. One of the things I'm working on slowly is creating a full UML model of the security model implemented in Zope. Then we can better discuss changes to the model. I'm a big believer in formalization of the security model, as opposed to the purely textual "well, we check X here". > What you guys have done with users, permissions and roles is already far > ahead of other web servers. I am interested in taking it a step further to > remove even more security code that currently resides in dtml scripts. This is a good thing, it also is necessary as we begin to integrate some of the concepts introduced in the PKI world. We've already started to work on how do you define roles and fit anonymous users into them. Also, how do you separate the identification stage from the authentication stage. For example, the path of a user through the security model: 1. 100% anonymous, unknown person 2. Identifiable anonymous person (same person, but not sure who) 3. Identified person, but not authenticated 4. I&A person, but not authorized 5. Authorized At any point, you should be able to bind that "individual" to a role. > Provide for positive and negative authorizations. > * We may want to give a role Employees access to a method, but not if the > user is also in the role Bad Boys. This is something I miss too... it would be nice to be able to "allow/deny" permissions overriding acquisition through this... so each setting would have three possible positions: * On (allow) * Off (deny) * Acquire Now, as you talk about being able to define a "permission" that has intelligence to it, and I'm not sure how to do that without having a huge impact on performance, but it is an interesting idea, especially as you try and translate X.509 certificate information (i.e. DN + LDAP) into a set of Roles. > Provide for resolution rules for when positive and negative authorization > conflict. > * (e.g. lower in the object hierarchy overrides inherited auths, negative > overrides positive, order dependent) First glance says this is 1) largely accomplished by acquisition as it is, 2) too complex if it isn't as it introduces yet another concept that the user must grasp. The single largest flaw with many security solutions is they aren't obvious, and in their obtuosity they only create more problems. Perhaps I'm simply not understanding this. Want to write some pseudo code, er... Python? > Allow time restrictions on user/role associations or method/role > associations (duration or cyclical restrictions) > * This would allow you to say Joe is a Manager from June 1 to June 30th. I can imagine this being useful. More importantly, Joe is only a manager from 8am-5pm M-F. This is a very common thing. > * This would allow you to say the Pay Payroll method can only be run on > Friday's. This is probably best enforced at the "application" layer as opposed to the framework layer. But perhaps there should be a way to have a separation of the security "check" from the DTML itself. > * This is useful in that you don't have to remember to remove Joe from the > role. It also helps when looking at audit logs you can see that he was > authorized to perform those functions during that time. No disagreement, but we have to balance power and speed and usability. > Allow actions to be associated with an authorization event. > * on success (e.g. write audit entry in log) > * on failure (e.g. write audit entry in log and call routine that checks for > excessive failures and pages sys admin if over the threshold.send email) Perhaps exposure of the new ZLOG framework at the DTML level would be useful? Simply use a <dtml-call "auditme('information here')"> ? > Allow expressions that include object values to play in the authorization > decision. > * Given an expense voucher (EV) object, a 1st Level Manager can 'sign' (an > EV method) if the EV.amount is less than $2500 and the EV.author is not the > AUTHENTICATED_USER. Scared :-) Again, perhaps an abstract concept of a property on an object that can on the *rare* occasion that it is needed could be called? You bring up some good ideas, discussion is good on this. Christopher -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0

Zope Creation Time
by Jason Spisak 07 Jul '99

07 Jul '99

Zopsters, I know that there is a bobobase_modification_time attribute. Does anyone know of a bobobase_create_date/time attribute, or if Zope stores such information? On a completely separate note, twice the ZODB has told me that a property name was in use when it was no where else, and then gave me key errors on that object for a period of about 5 minutes, or until I clicked on the right compination, I guess. It seemed like a thread issue. I am the only one using Zope, but since it wen a away and let me enter it eventually I am spooked out. Anybody experience this? A temporary KeyError? CVS sheckedout and recompiled as of 9:00 am PST 07/06/1999 All my best, Jason Spisak webmaster(a)mtear.com

2 1

RE: [Zope-dev] New ZPublisher Types
by Alexander Staubo 07 Jul '99

07 Jul '99

Also there are some gross HTML errors (check out the font size/type for last 2/3 of the document, starting at "Here is the HTML input form"). -- Alexander Staubo http://www.mop.no/~alex/ "What the hell, he thought, you're only young once, and threw himself out of the window. That would at least keep the element of surprise on his side." --Douglas Adams, _The Hitchhiker's Guide to the Galaxy_ >-----Original Message----- >From: zope-dev-admin(a)zope.org [mailto:zope-dev-admin@zope.org]On Behalf >Of Martijn Pieters >Sent: 7. juli 1999 04:08 >To: Pam Crosby; Cathi Davey; 'zope-dev(a)zope.org' >Subject: RE: [Zope-dev] New ZPublisher Types > > >At 20:08 05/07/99 , Pam Crosby wrote: >>Cathi, >>Your documentation has been added to the Trinkets Tutorial online at >>http://www.zope.org/Documentation/Reference/Trinkets/index_html > >Very nice! > >These changes are only available in the latest CVS release, >however. How >will a new developer be able to detect this from the documentation? > >Some errors: > >-- >RECORD > ><INPUT TYPE="text" NAME="person.name:record" SIZE="30"> > >The input tag for the name field is named >person.name:record:ignore_empty. The >:record part of the name indicates to Zope that the field should be >converted to a record before passing it to the published >method. A record >variable will be created called person and it will have an >attribute called >name. > >- Either: The first line should read: .. is named >person.name:record. The .. >- Or: the NAME field of the INPUT tag should read: >person.name:record:ignore_empty > >-- >RECORDS > >The records method is implemented: > > <P><H2>Member #1<H2></P><br> > <P>lease enter your name:<BR> > <INPUT TYPE="text" NAME="member.name:records:ignore_empty" >SIZE="30"><BR> > your email:<BR> > <INPUT TYPE="text" NAME="member.email:records:ignore_empty" >SIZE="30"><BR> > your age:<BR> > <INPUT TYPE="hidden" >NAME="myname.age:int:records:default" Value="0"<BR> > <INPUT TYPE="text" >NAME="member.age:int:records:ignore_empty"></P><BR> > <P><H2>Member #2</H2></P><BR> > <P>Please enter your name:<BR> > <INPUT TYPE="text" NAME="member.name:records:ignore_empty" >SIZE="30"><BR> > your email:<BR> > <INPUT TYPE="text" NAME="member.email:records:ignore_empty" >SIZE="30"><BR> > your age:<BR> > <INPUT TYPE="text" NAME="member.age:int:records:ignore_empty<a >href="records"">></P> > >In this sample the form asks for a name and age for two >different members >of a club. The part appears in each input tag. This type will >create a list >called members that will hold records (in this case it will hold two >records). Each record can have the attributes name and age. > >- The hidden field should read: .. >NAME="member.age:int:records:default" .. >- A newline before the line 'Member #2' would increase readability. > >-- > > > >-- >Martijn Pieters, Web Developer >| Antraciet http://www.antraciet.nl >| Tel: +31-35-7502100 Fax: +31-35-7502111 >| mailto:mj@antraciet.nl http://www.antraciet.nl/~mj >| PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------ _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org http://www.zope.org/mailman/listinfo/zope-dev (For non-developer, user-level issues, use the companion list, zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope )

1 0

New ZClass based on Users
by Jason Spisak 07 Jul '99

07 Jul '99

Zopists, Has anyone tried to create a new ZClass based on User Folder, and then put a class based on Users in it? I would like to give the users of my site some properties other than Roles, and Domain., etc... I know that this is what the ZPTK is all about. Just wondering if anyone's had any luck so that I don't have to start from sratch. All my best, Jason Spisak webmaster(a)mtear.com

1 0

Re: ZClass "delete" and Catalog disk tuning
by Jason Spisak 06 Jul '99

06 Jul '99

An Update to the latest CVS and a recompile fixed the KeyError "delete". I don't even know what it might have been. The glory of CVS :) >searching an index is much faster, That is all we will be doing. >incrimental indexing is much more efficient because it typically only wakes up a portion of the index. I will be setting up indexes for each findable property separately, and in regards to MetaData, very few actual items will get returned. Mostly the search results will point you to the actual items to keep it lightweight. After all, it's only a click away :) Oh, in regards to reads and writes to disk, mostly would you say Zope does non-sequencial reads and writes? (ie from a lot of various places, where disk I/O would be a primary bottleneck) Jason Spisak webmaster(a)mtear.com

1 0

RE: [Zope-dev] Re: ZODB3 Database question/server tuning
by Michel Pelletier 06 Jul '99

06 Jul '99

> -----Original Message----- > From: Jason Spisak [mailto:webmaster@mtear.com] > Sent: Tuesday, July 06, 1999 12:44 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Re: ZODB3 Database question/server tuning > > > Zopists, > > I'm not sure who to ask this to so I'll throw it out and see > if anybody > knows. > > As far as disk/server performance and the Data.bbb file, it's > not like a > traditional RDB as far as disk performance and speed goes right? > Assuming I'm not connecting to any backend DB's, is it just one large > file always in the same place? With the advent of ZODB3 how does Zope > handle many people asking for different protions of the database? > > (I don't think my question is clear yet, I'll keep trying:) > > Does Zope store the entire Data.bbb file into memory if it can? Zope stores recently accessed objects in memory. It deactivates them according to how you tune the cache in the Control Panel. > In > which case lots od RAM matters and hard disk speed doesn't accept for > start-up. Are there lots of random reads/writes to disk if > say 150 are > all creating records at the same time and searching, etc...? > Or are the > writes to disk sequencial because it's only one file (Data.bbb)? All writes to the Data.bbb file are appended onto the end of the file. Note that even though Zope 'writes' something 'out to file' the OS may in fact be buffering large amounts of the reads and writes in memory. Linux, for example, will use as much available RAM as it can for file buffers and caches. Other UNIXish OSes probably behave similarly. The more RAM you have, the less actual disk reading and writing goes on. Finding and searching a catalog are two different access paterns. Finding walks down the Zope tree examining objects for certain attributes. This is similar to the UNIX 'find' utility. It is slow and rather expensive. searching an index is much faster, but possible more memory comsuming. searching involves pre-indexing a bunch of data ito a very fast binary tree. Only the portions of the index that are being searched are activated in memory, and unused portions are deactivated. This is why mass-indexing makes the Zope process grow so large. Because almost the entire index is activated to index everything in your site, the whole thing is in memory. incrimental indexing is much more efficient because it typically only wakes up a portion of the index. We are working on more and more optimizations for indexing, including pre-sorting the indexed information in tmp files, so that various portions of the index can be woken up and put to sleep in an orderly fasion, instead of randomly as it is now (requiring the consumption of large amounts of memory). -Michel > > I'm sure this is quite confusing. Sorry. I'm trying to see what the > best server tuning would be for Zope. Thanks for your patience. > > All my best, > > Jason Spisak > webmaster(a)mtear.com > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (For non-developer, user-level issues, use the companion list, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

1 0

Re: ZODB3 Database question/server tuning
by Jason Spisak 06 Jul '99

06 Jul '99

Zopists, I'm not sure who to ask this to so I'll throw it out and see if anybody knows. As far as disk/server performance and the Data.bbb file, it's not like a traditional RDB as far as disk performance and speed goes right? Assuming I'm not connecting to any backend DB's, is it just one large file always in the same place? With the advent of ZODB3 how does Zope handle many people asking for different protions of the database? (I don't think my question is clear yet, I'll keep trying:) Does Zope store the entire Data.bbb file into memory if it can? In which case lots od RAM matters and hard disk speed doesn't accept for start-up. Are there lots of random reads/writes to disk if say 150 are all creating records at the same time and searching, etc...? Or are the writes to disk sequencial because it's only one file (Data.bbb)? I'm sure this is quite confusing. Sorry. I'm trying to see what the best server tuning would be for Zope. Thanks for your patience. All my best, Jason Spisak webmaster(a)mtear.com

1 0

RE: [Zope-dev] Catalog aware ZClass
by Michel Pelletier 06 Jul '99

06 Jul '99

> -----Original Message----- > From: Jason Spisak [mailto:webmaster@mtear.com] > Sent: Monday, July 05, 1999 6:31 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Catalog aware ZClass > > > Michel: > > Thanks for the Findable base class ideas. I attempted to create a > Findable class and made a small mistake. I named the method > to perform > deletion "delete" Of course now anyhting to do with that object > produces a KeyError. I can't delete it, or look inside it. Just a > heads up on the taboo name "delete" in ZClasses. Is there any other > taboo names I should be aware of? > Hmm. I'm a little lost here, you created a Findable ZClass with a delete method, and that broke? I'm not sure how, I don't think 'delete' is a special word of any kind. Just for safties sake however, you might want to come up with more obfusicated nameds. > Also you mentioned add, delete and findable methods for this > base class. > Doesn't adding something to the Catalog automatically render it > findable? > Yep, 'Findable' is just a handy name for a base class that defines the attributes you want to find. It is possible for you to add indexes that don't correlate with the Findable class, and conversely it is possible for Findable to define attributes that the catalog doesn't look for. The two are unconnected, it's just handy to keep all of your 'Findables' in one base class, that way lots of different kinds of ZClasses can subclass Findable and thus work seamlessly with your existing catalogs. -Michel PS Catalog beta is around the corner, expect it with the next Zope alpha. > All my best, > > -- > Jason Spisak > webmaster(a)mtear.com > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (For non-developer, user-level issues, use the companion list, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

1 0