Basic and Form Authentication

[Anthony Jay <an...@fastmail.fm>]

Hi,
  Is is possible to have an application that serves content protected by
  BASIC and FORM based auth?
i.e.
JSP protected by FORM
Servlets that process XML use http BASIC?

I could deploy seperate apps for each type but I would then lose access
to application specific information e.g. Singletons and Statics, which
will cause big problems.

Any words of wisdom?

Tony

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Basic and Form Authentication

[André Warnier <aw...@ice-sa.com>]

Anthony Jay wrote:
> Hi,
>   Is is possible to have an application that serves content protected by
>   BASIC and FORM based auth?
> i.e.
> JSP protected by FORM
> Servlets that process XML use http BASIC?
> 
There is a rather extensive description available here :
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html

and it also points you to the relevant section of the Servlet 
Specification (2.4 or 2.5), section SRV 12.1 and following.

 From reading it in diagonals, to me it seems possible to do that, if 
the URLs for the two types of "servlets" above can be distinguished.
But you may want to wait for a more authoritative answer than mine.

The above is all about container-based security.
There is another "philosophy" available, namely servlet-filter based 
security, which may do what you want.
The expert on that is Christopher, who will be having a look here in a 
few hours.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Basic and Form Authentication

[Mark Thomas <ma...@apache.org>]

Anthony Jay wrote:
> Hi,
>   Is is possible to have an application that serves content protected by
>   BASIC and FORM based auth?
> i.e.
> JSP protected by FORM
> Servlets that process XML use http BASIC?

The Servlet spec does not support this. There is a maximum of one login
method allowed per web app. That doesn't you doing more, but you have to
provide all of the authentication plumbing yourself.

Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Basic and Form Authentication

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony,

On 11/30/2009 4:53 AM, Anthony Jay wrote:
>   Is is possible to have an application that serves content protected by
>   BASIC and FORM based auth?

As Mark points out, the servlet spec says "not in the same webapp."
Tomcat implements the servlet specification and no more, so you are out
of luck, there.

> I could deploy seperate apps for each type but I would then lose access
> to application specific information e.g. Singletons and Statics, which
> will cause big problems.

I would strongly advise you to separate your webapps: one webapp for
your XML-based API and the other for human interaction. Don't forget
that your human UI could make use of the XML API behind the scenes. This
is typically called "drinking your own Cool-Aid".

If it's possible for you to do so, you could put your shared
singleton/static classes into a shared ClassLoader. What kinds of things
are you using that you would need to share across webapps? Could those
things be converted into services that both webapps could share?

Note that an XML service whose URL contains a jsessionid parameter will
be associated with the indicated session. You could use such a URL to
avoid the FORM authentication (but getting the session id is, of course,
an issue unresolved by this).

Finally, you could go out on your own and implement your own
authentication mechanism. Securityfilter is a simple, filter-based
authentication and authorization mechanism that you could hack-up to do
this type of thing. Actually, you could use it out-of-the-box and just
use a Filter configured /in front/ of it to trick sf into trusting a
Principal configured by your Filter (which comes from the request's HTTP
AUTH data).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksUHsEACgkQ9CaO5/Lv0PD/jACeKCyBSKRnZtnso5EzEPROUMXO
i74An09m3QZY0GTl47KplbdCSu/NG1wr
=t+z3
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org