cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Fagerstrom" <daniel.fagerst...@swipnet.se>
Subject RE: [RT] Access Control (was [RT] Cocoon as OS)
Date Wed, 06 Feb 2002 22:00:54 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message