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. 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.
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 ):
<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>
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 would be a lot of added complexity, but then that’s an
implementation and customization issue. My sense is that resource-based access
control should be disabled by default; that customization should be available if
necessary, but in most cases it seems like overkill.
How does this work? I have to admit I’m not overly familiar with sitemap
internals, but my feeling is that these things should be this seemless to the
sitemap user/writer. Magic happens here. This becomes much easier when you’re
thinking about a Schecoon context, where you theoretically don’t have to think
about maintaining state across HTTP connections. We might need two branching
hierarchies of ACL handlers to handle both stateless and stateful web contexts.
That’s all I can muster for now. . .
Greg Weinger
UCLA Teleradiology
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
