On Saturday, Aug 23, 2003, at 14:17 Europe/Rome, Steven Noels wrote:


I still believe authentication code should be orthogonal to actual application logic, and rather be defined by the container.

Sure, too bad everybody has a different opinion on what the container is.


If you talk to os kernel folks, they think authentication should happen right at TCP/IP stack level, if you talk to httpd, they will give you an apache module, if you talk to servlet engine folks, they will give you a web.xml descriptor or, if you are lucky, a servlet filter, if you talk to sitemap lovers, they will give you an action.

And all of them will think they are doing it right and the one above them are just asking for trouble.

In this discussion, I think 'sitemap' == 'container'. Also, since authentication-requiring realms are a part of the overall URI namespace, when finding out which parts need authentication, I would check first with the container (web.xml) -> sitemap.xmap -> > flowscript.

well, follow the entire chain and you'll get down to IPSEC.


In fact, "in media stat virtus" (balance is in the middle, for the latin unsavy) and complex authentication/authorization schemes may well require several progressively refined steps, each happening in their own realm.

So, it might be useful to use a firewall at the kernel level to avoid DoS, then HTTPd SSL authentication and tunneling (in the web server for performance and scalability), then app-level authorization based on the SSL parameters passed on.

Not making authentication handling part of your application is one of the first things I learned over here, when greeting Giacomo at ApacheCon in London.

So, if you guys are talking about authentication with actions vs flowscript & interceptors, what are you talking about: doing the authentication, or checking authorization?

In the example I made, both authentication and authorization were done in the same interceptor (well, the authentication stage was handled by an external polymorphic component).


--
Stefano.



Reply via email to