From: Nikola Milutinovic <[EMAIL PROTECTED]> Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]> To: Tomcat Users List <[EMAIL PROTECTED]> Subject: Re: Can I chain authenticators? Date: Wed, 18 Feb 2004 12:38:13 +0100
Ryan Rhodes wrote:
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.
Let me explain my situation a little more clearly. I don't have a lot of control over the commercial product that I'm integrating with. It has it's own access control system, and it uses Basic Auth. Thats just what I have to work with. I'm not doing this to improve security. For one thing, this is just a prototype. If it were rolled out company-wide or for internet use then we would probably move to a centralized SSO solution. I just need to allow users to click hyperlinks from the portal that pass the user through to the commercial product without the Basic auth popup. I don't want to augment the commercial product with my own authorization system. I just want a valve to transfer the credentials from the body of a POST request to the HTTP headers the commercial product expects. The commercial product is based on Tomcat... so I can add valves if I need to, but I can't replace it's internal authentication because then I would lose it's authorization.
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.
You can call it chaining if you want, or you can call it a valve that preps things for the real authenticator. If the user presents credentials as a POST I take the post credentials. If they present Basic Auth creds I take those. Simple as that. I'm not sure I understand the go/no-go concept for Authenticators. With JAAS you can stack as many modules as you want. Any one of them could be sufficient or required.
Ryan
_________________________________________________________________
Store more e-mails with MSN Hotmail Extra Storage – 4 plans to choose from! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
