I have a portal project. I need to allow users to navigate seamlessly from the portal to a commercial product that’s based on Tomcat 4.1 and uses Basic Authentication. To get around this, I hacked BasicAuthenticator and added some code to get the credentials from the request body:
if( hreq.getMethod().toUpperCase().equals("POST") && hreq.getParameter("username") != null && hreq.getParameter("password") != null ) { username = hreq.getParameter("username"); password = hreq.getParameter("password");
principal = context.getRealm().authenticate(username,password);
if (principal != null) {
register(request, response, principal, Constants.BASIC_METHOD,
username, password);
return (true);
}
}
Why is this any better than "Basic Authentication"? If every request has to be acompanied by user/pass in request, it can also be done via regular HTTP headers. You are not gaining any additional security this way. As for portals, the most important thing about them is not authentication (it is left to the web server; be it Tomcat or Apache), but authorization and presentation.
Authenticationg is easy, you can choose:
- HTTP Basic (totally unsafe, but if going over SSL it doesn't matter) - HTTP Digest (there were client problems in the past) - HTTP SPNEGO (Microsoft's implementation of GSS-API/Kerberos5 over HTTP)
Basic works with all browsers, but is unsecure, unless ran over HTTPS. Digest had problems on the client side in the past and I don't know which clients support it reliably. SPNEGO is great if you have Kerberos framework in place (MIT or Heimdal on UNIX or Active Directory on Win2k/2003/XP). Also only Mozilla 1.5/1.6 and IE6 support it on the client side. On the server side, you need either IIS or Apache + mod_spnego/mod_gssapi as front-end. Coyote connector doesn't have that feature yet.
I read in the lists somewhere that if I add a custom Authenticator it will disable the Basic Authenticator. Can I separate this code out and chain the Authenticators together? What level should I configure the Valve at for the Authenticator?
Why would you "chain" authenticators?
Authentication is a go/no-go module. It either succeeds or fails. There is no "second try" or "auxiliary machanism". What would you do if the client supplies both your custom user/pass and HTTP Basic user/pass (not unthinkable)?
Save yourself a maintainance nightmare and think your security model throughly, then implement what you feel is right for you.
Nixie.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
