Re: Can I chain authenticators?

[Ryan Rhodes]

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]

Re: Can I chain authenticators?

[Nikola Milutinovic]

Ryan Rhodes wrote:

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);
   }
   }
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]

Re: Can I chain authenticators?

[Mario Ivankovits]

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Can I chain authenticators?

[Nikola Milutinovic]

  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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Can I chain authenticators?

[Ryan Rhodes]

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?

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can I chain authenticators?

[Bill Barker]

Ryan Rhodes [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]