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). > > <map:match src=”app/**” permission=”internet”> > <map:generate/> > <map:serialize/> > </map:match> > > Permissions are sitemap-defined: > > <map:permissions> > <map:permission name=”internet” validate=”user”> > <map:user>anonymous</map:user> > <map:group>anonymous</map:group> > </map:permission> > <map:permission name=”intranet” validate=”database”> > <map:group>company</map:group> > </map:permission> > <map:permission name=”admin” validate=”database”> > <map:group>managers</map:group> > </map:permission> > <map:permission name=”mydepartment” validate=”ip”/> > </map:permissions> > > Permissions can thus be heirarchical: > > <map:permission name=”mydepartment” validate=”ip”> > <map:parameter name=”address” value=”149.142.22.x”/> > <map:permission validate=”database”> > <map:group>company</map:group> > </map:permission> > </map:permission> > > 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. > <map:validators> > <map:validator type=”user” src=”FileBasedUserValidator.java”> > <scope>Request</scope><!-- or Sesison, Schecoon, etc. --> > </map:validator> > <map:validator type=”ntuser” src=”NTMappedValidator.java”/> > <map:validator type=”db” src=”DatabaseValidator.java”/> > <map:validator type=”ip” src=”IPBasedValidator.java”/> > <map:validator type=”http” src=”HTTPChallengeValidator.java”.> > </map:validators> 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: > > <map:handle-error type=”access-denied”> > <!-- add your custom login page, a standard message, what have you --> > </map:handle-error> > > So how does this monster behave? Take this sitemap example: > > <map:match src=”admin/**” permission=”admin”> > <map:generate/> > <map:serialize/> > </map:match> > > 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! <snip/> /Daniel Fagerstrom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
