Of course he can also just use BASIC Auth and do request.getRemoteUser() and do whatever he wants with that. No realms needed there. The original question was why was he setting up BASIC Auth programatically when he can specify it in web.xml. It sounds like he uses some custom authentication stuff anyway, so realms aren't really the question. It is simply the BASIC Auth that he can set up in web.xml which is what I was getting at.

Jake

At 11:31 PM 5/25/2004 -0700, you wrote:

"SH Solutions" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi
>
> > Can you explain yourself here?  It is not obvious to me.  How does the
> number of users make any difference here.  Just set up BASIC Auth in
> web.xml.  You don't have to define your users and roles in web.xml, if
> that's what you are implying.
>
> Alright, that is what I was thinking.
> So, is it possible, to use web.xml security together with our own login
> handler?
> Especially with certificates?
>

Tomcat's MemoryRealm and UserDatabaseRealm work with CLIENT-CERT auth-type,
as long as you don't need anything fancy (The user name is the cert
Subject).  You could also create your own Realm that would allow you to
authenticate any way you like.  Of course, this means that your app would
now depend on Tomcat, and so would be less portable.

To do programatic security, the easiest is to set 'clientAuth="true"' on the
Connector (Tomcat 5) or the Factory (Tomcat 4).  This forces the browser to
send the cert on all SSL requests.  In newer Tomcat 5 versions (and JDK
1.4+), you can also specify 'clientAuth="want"' to simply ask nicely :).  Of
course, this assumes that you are using the HTTP/1.1 Connector.  For the JK
Connector, you would configure this on Apache/IIS/SunOne.

If this isn't good enough for you, then there is always the Tomcat-specific:
  request.getAttribute("org.apache.coyote.request.X509Certificate");
which will re-negotiate the connection if necessary to get the client to
send the cert.  This works for the Coyote-HTTP/1.1 in TC 4.1.x and TC 5.0.x.
However, I'd really like to drop this "feature" in 5.1.x.

> Regards,
>   Steffen




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to