You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ryan Rhodes <ry...@hotmail.com> on 2004/02/17 15:23:59 UTC
Can I chain authenticators?
I have a portal project. I need to allow users to navigate seamlessly from
the portal to a commercial product thats 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);
}
}
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?
Incidentally, I tried like hell to do this with a Valve. It seems like no
matter which container you put the Valve in the Basic Authenticator always
runs first and causes the login dialog to popup in the browser. It would be
great if anyone could confirm this or explain the ordering of valves and
authenticators to me a little better. Here is the code I used for the valve
approach:
if( req.getMethod().equals("POST") ) {
if( req.getParameter("username") != null && req.getParameter("password") !=
null ) {
String unencoded = req.getParameter("username") + ":" +
req.getParameter("password");
String encoded = new String(Base64.encode(unencoded.getBytes()));
HttpRequest hreq = (HttpRequest) request;
hreq.setMethod("GET");
hreq.addHeader("AUTHORIZATION", "BASIC " + encoded);
log("HTTP Basic Credentials: " + unencoded );
} }
Thanks for any help,
Ryan Rhodes
_________________________________________________________________
Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer!
http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Can I chain authenticators?
Posted by Bill Barker <wb...@wilshire.com>.
"Ryan Rhodes" <ry...@hotmail.com> wrote in message
news:Law12-F75kLwxTQTYkW0001d3f7@hotmail.com...
> 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);
> }
> }
>
> 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?
>
It has to be configured at the Context level if it implement Authenticator.
The same is true for your code above, since the Context isn't known until
then. For what you want, you could probably also use a non-Authenticator
valve, and call request.setUserPrincipal with the Principal that is returned
by the Realm. Then BasicAuthenticator will think that you are already
authenticated, and let you through.
> Incidentally, I tried like hell to do this with a Valve. It seems like no
> matter which container you put the Valve in the Basic Authenticator always
> runs first and causes the login dialog to popup in the browser. It would
be
> great if anyone could confirm this or explain the ordering of valves and
> authenticators to me a little better. Here is the code I used for the
valve
> approach:
>
> if( req.getMethod().equals("POST") ) {
> if( req.getParameter("username") != null && req.getParameter("password")
!=
> null ) {
> String unencoded = req.getParameter("username") + ":" +
> req.getParameter("password");
> String encoded = new String(Base64.encode(unencoded.getBytes()));
> HttpRequest hreq = (HttpRequest) request;
> hreq.setMethod("GET");
> hreq.addHeader("AUTHORIZATION", "BASIC " + encoded);
> log("HTTP Basic Credentials: " + unencoded );
> } }
>
> Thanks for any help,
>
> Ryan Rhodes
>
> _________________________________________________________________
> Get fast, reliable access with MSN 9 Dial-up. Click here for Special
Offer!
> http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Can I chain authenticators?
Posted by Nikola Milutinovic <Ni...@ev.co.yu>.
> > Why would you "chain" authenticators?
>
> Well, i have chained SSL and BASIC authenticators.
That's not exactly "chaining". In SASL, SSL is called "EXTERNAL"
authentication. You just have two independant mechanisms, one of which is
solely for authentication (HTTP Basic) and the other can authenticate, but
doesn't have to (SSL).
Nix.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Can I chain authenticators?
Posted by Mario Ivankovits <ma...@ops.co.at>.
> Why would you "chain" authenticators?
Well, i have chained SSL and BASIC authenticators.
I the users have some "well known" certificate installed (checked agains
LDAP) they do not have to enter some user/password, else a BASIC
authenticator (via https) is presented.
So it is possible to use the application from within the company or at
home without login, if the user needs access to the application from
some internet-cafe a login screen will be presented.
Ciao,
Mario
Re: Can I chain authenticators?
Posted by Nikola Milutinovic <Ni...@ev.co.yu>.
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.
> 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org