From cocoon-dev-return-22372-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Wed Feb 06 23:31:38 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 39540 invoked by uid 500); 6 Feb 2002 23:31:37 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 88079 invoked from network); 6 Feb 2002 22:00:13 -0000 Reply-To: From: "Daniel Fagerstrom" To: Subject: RE: [RT] Access Control (was [RT] Cocoon as OS) Date: Wed, 6 Feb 2002 23:00:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3C5F0066.DE7A4778@itmedicine.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Greg Weinger wrote: > You beat me to the punch, dammit! ;-) Actually, I hadn’t thought of > resource-based security, an interesting concept. I strongly > feel that Cocoon > needs to make ACL functionality available, in a clean way. Why > does Tomcat > provide its own database security mechanism? They're trying to > fill a void I > personally would like my webapp framework to handle, for > portability. I don't > want to lose my ACL functionality when my client makes me switch > to WebSphere, or > vice versa. I agree. The servlet API is (AFAIU) based on an authorization model where the servlet container is suposed to take care about: * the HTTP authentication protocol (ftp://ftp.isi.edu/in-notes/rfc2617.txt) * user authorization (in practice: user and password DB) * role handling IMHO the first point is an appropriate concern for the servlet container while the rest of the points are application concerns. Of course I would like to have a nice standardized handling of users for all aplications. But in several projects that I have been involved in there have been legacy DB:s with user data that we had to use. So at least from my experience, user handling is a application concern. So AFAIU either one have to put all authorization in the servlet container, which for Tomcat often means that one have to write a custom realm (have done it and didn't like it). Or one have to let the application framework take care of it. I would prefer the later alternative and having all authorization taken care of from Cocoon, (but I do not volunteer to integrate the HTTP authentication protocol ;) ). > Here is how I’ve been thinking about security, which I think > maximizes puggability into existing ACL systems, and neatly seperates this > concern island from the others. > > I started with the User/Group based system, since it is > ubiquitous. (I think > Brian was touching on this earlier). To bring that to the > Cocoon/web world, we > need to assume that every URI request has a user, password, and a > group. If this > information does not exist in the standard places (Request, > Session, or a new > User object in the object model), than a default user, password, > and group is > assumed (anonymous). That means we’d have “special” request > parameters, a la > cocoon-action, cocoon-user, cocoon-pass, cocoon-group, which is > ugliness to be > sure, but ugliness that goes away with Schecoon. It seem a little bit complicated (and insecure) to make shure that the client send all this information, (but maybe I am missing something). Browsers know about the HTTP authentication protocol, and if you use that, they will send you username and password automatically. > A request URI can be protected by a permission (I suppose a > pipeline could, too, > but that could best be decided by others). It can also be left > unprotected > (everyone). > > > > > > > Permissions are sitemap-defined: > > > > anonymous > anonymous > > > company > > > managers > > > > > Permissions can thus be heirarchical: > > > > > company > > > > Permissions are validated by a set of validatior objects; we’d > supply the most > common ones (maybe authenticator is a better semantic ): I think that what you propose here can be handled with actions, so there is probably no need for new sitemap constructions, although they could be more conscise. > > > Request > > > > > > Yes, there is probably need for several different kinds of validators. > That way we can plug our authentication scheme into any number > of existing > methods, including the neat Slide-based scheme proposed by Daniel. > > The webapp writer or site administrator is responsible for > writing login pages to > supply user, pass, and group parameters, only once for Session scope, and > embedding it in pages if they want Request scope). > > The only other thing I think the sitemap developer should be > concerned with is > error-handling. What happens when access is denied? In both > static resource and > web application contexts, that behavior needs to be customized. Just use > handle-error: > > > > > > So how does this monster behave? Take this sitemap example: > > > > > > > If you have admin access, then everything is fine. If not, an > AccessException is > thrown, which either bubbles up to the top, or is handled by the > handle-error > defined in the sitemap. I don’t think that anything I’ve > proposed would be > incompatible with the Resource-based security, which is similar > to the pipeline > caching approach. That is a good parallell! /Daniel Fagerstrom --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org