Comments on: Servlet authentication woes http://boldlyopen.com/2005/04/27/servlet-authentication-woes/ To boldly muse about Open Source Wed, 07 Jan 2009 13:18:03 +0000 http://wordpress.org/?v=2.6 By: Ugo Cei http://boldlyopen.com/2005/04/27/servlet-authentication-woes/#comment-269 Ugo Cei Tue, 30 Nov 1999 00:00:00 +0000 http://www.rabellino.it/blog/2005/04/27/servlet-authentication-woes/#comment-269 One possibility would be to place a custom servlet filter that wraps requests to the REST URLs and implements BASIC auth by hand (shouldn't be hard). <br /> <br /> Another is to put an Apache httpd with mod_proxy in front and protect the REST URLs with Apache, leaving form-based auth to the servlet container. One possibility would be to place a custom servlet filter that wraps requests to the REST URLs and implements BASIC auth by hand (shouldn’t be hard).

Another is to put an Apache httpd with mod_proxy in front and protect the REST URLs with Apache, leaving form-based auth to the servlet container.

]]> By: Brian Ewins http://boldlyopen.com/2005/04/27/servlet-authentication-woes/#comment-270 Brian Ewins Tue, 30 Nov 1999 00:00:00 +0000 http://www.rabellino.it/blog/2005/04/27/servlet-authentication-woes/#comment-270 We went for the 'duplicate webapp' solution, its just a change to the build scripts. In fact if you have an XML/SOAP client, its better to have a separate webapp, or you'll get unwanted HTML responses for errors.<br /> <br /> My gripe with this stuff is more that it is still *impossible* to portably have container-managed SSO across servers going by the servlet spec. (ie things like CAS, Athens - the spec allows for SSO on a single container). This leaves the container not knowing the security context of servlet requests and a lot of work needs done to help integrate properly with other parts of the J2EE stack (where acegi comes in). <br /> <br /> If apps could just declare 'CONTAINER-MANAGED' authentication and leave the details until deployment time, life would be much better (wouldn't solve your problem though). We went for the ‘duplicate webapp’ solution, its just a change to the build scripts. In fact if you have an XML/SOAP client, its better to have a separate webapp, or you’ll get unwanted HTML responses for errors.

My gripe with this stuff is more that it is still *impossible* to portably have container-managed SSO across servers going by the servlet spec. (ie things like CAS, Athens - the spec allows for SSO on a single container). This leaves the container not knowing the security context of servlet requests and a lot of work needs done to help integrate properly with other parts of the J2EE stack (where acegi comes in).

If apps could just declare ‘CONTAINER-MANAGED’ authentication and leave the details until deployment time, life would be much better (wouldn’t solve your problem though).

]]> By: magomarcelo http://boldlyopen.com/2005/04/27/servlet-authentication-woes/#comment-271 magomarcelo Tue, 30 Nov 1999 00:00:00 +0000 http://www.rabellino.it/blog/2005/04/27/servlet-authentication-woes/#comment-271 I had the same problem and ended using BASIC auth for webservices (Hessian) and custom code for Form Authentication (admin app).<br /> I've also tried the SecurityFilter solution, trying to mix it with a Tomcat Realm at the Container level but didn't work, unfortunately SecurityFilter (even the latest 2.0) needs to create its own instance of a Tomcat Realm object and it seems to work only for JDBCRealm, not even DataSourceRealm, that needs a reference to the container to access the JNDI context.<br /> But after this experience now I would use two different webapp, maybe sharing some code in CATALINA_HOME/shared, at least it makes sense that sessions for webservices users and web users are separated... maybe the servlet spec was right?<br /> Looks like stuff for some next JUG meeting ;) I had the same problem and ended using BASIC auth for webservices (Hessian) and custom code for Form Authentication (admin app).
I’ve also tried the SecurityFilter solution, trying to mix it with a Tomcat Realm at the Container level but didn’t work, unfortunately SecurityFilter (even the latest 2.0) needs to create its own instance of a Tomcat Realm object and it seems to work only for JDBCRealm, not even DataSourceRealm, that needs a reference to the container to access the JNDI context.
But after this experience now I would use two different webapp, maybe sharing some code in CATALINA_HOME/shared, at least it makes sense that sessions for webservices users and web users are separated… maybe the servlet spec was right?
Looks like stuff for some next JUG meeting ;)

]]> By: Lars G. Svensson http://boldlyopen.com/2005/04/27/servlet-authentication-woes/#comment-272 Lars G. Svensson Tue, 30 Nov 1999 00:00:00 +0000 http://www.rabellino.it/blog/2005/04/27/servlet-authentication-woes/#comment-272 I had exactly the same problem, but managed to solve it with securityfilter (http://securityfilter.sourceforge.net/) I configured my web xml to run two instances of the filter with different configuration and then map the filters to differend url-patterns.<br /> Could that be a solution?<br /> <br /> Lars I had exactly the same problem, but managed to solve it with securityfilter (http://securityfilter.sourceforge.net/) I configured my web xml to run two instances of the filter with different configuration and then map the filters to differend url-patterns.
Could that be a solution?

Lars

]]> By: Vurti Galka http://boldlyopen.com/2005/04/27/servlet-authentication-woes/#comment-273 Vurti Galka Tue, 30 Nov 1999 00:00:00 +0000 http://www.rabellino.it/blog/2005/04/27/servlet-authentication-woes/#comment-273 Have a look at http://acegisecurity.sourceforge.net/ Have a look at http://acegisecurity.sourceforge.net/

]]> By: anon http://boldlyopen.com/2005/04/27/servlet-authentication-woes/#comment-274 anon Tue, 30 Nov 1999 00:00:00 +0000 http://www.rabellino.it/blog/2005/04/27/servlet-authentication-woes/#comment-274 try java OS single sign on<br /> http://www.josso.org/ try java OS single sign on
http://www.josso.org/

]]>