When all else fails, look at the source code (Dave, thanks for the
suggestion). There is no support for SHA-1 in Tomcat's implementation of
DigestAuthenticator. It should be easy enough to implement, provided the
core JDK supports the creation of an instance of
java.security.MessageDigest that is implemented with SHA-1. I'll give
this a try tomorrow- no midnight java tonight.
-Mark
Mark Leone wrote:
Dave, thanks very much for your help. Unfortunately, the passage you
quoted is referring to how the password is digested when it is stored
in the realm. This is working fine for me, and I've been able to
configure it to use SHA-1 or MD-5 algorithms by setting the digest
attribute in the <realm/> element to either "SHA" or "MD5", which are
the appropriate keywords to identify those algorithms.
What I described above works fine when I select BASIC authentication
by putting the following in my web.xml
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>JDBCRealm</realm-name>
</login-config>
However, I change "BASIC" above to "DIGEST" to induce the server to
tell the client that DIGEST authentication is required, meaning that
instead of sending the username and password as a Base64 encoded text
string, which anyone can decode and thereby compromise the user's
credentials, it will send a hash of the username and password, with a
random value and a sequence counter generated by the server also
included as an input to the hash function. This of course is a much
more secure way to send login credentials. According to the spec that
governs DIGEST access authentication (rfc2617), if the server does not
explicitly specify a hash algorithm in the www-authenticate header of
the HTTP response message (status 401- unauthorized), it defaults to
MD5. So after much thrashing around, I discovered that I could only
get DIGEST authentication to work by specifying MD-5 in the <realm/>
digest attribute, and then letting the client default to using MD5 for
the DIGEST authentication algorithm, since Tomcat is not specifying
the algorithm in the HTTP header (which I verified with an HTTP
monitor tool).
What I would LIKE to do is use SHA-1, since it's a more secure
algorithm (and because I have engineer's disease, and I have to figure
out how to do something even if there's an almost-as-good
alternative). I know I can set the <realm/> digest attribute to SHA-1,
but I don't know how I cant tell Tomcat to require SHA-1 algorithm in
the www-authenticate response header. I found a method that does this
>>org.apache.catalina.authenticator.DigestAuthenticator.setAuthenticateHeader()<<
But I'd like to do it with a configuration parameter. I've looked
thorough all the Tomcat docs, and I see nothing that appears to do
this. I opened the Servlet spec and looked at the XSD for the web.xml
document, and there appears to be nothing there that can set the
DIGEST algorithm. Perhaps it can be set in the server.xml file. I'm
going to look for that XSD next, but if anyone knows off-hand what the
parameter is, please enlighten me.
If there's not a configuration parameter, could someone tell me how to
do this programmatically? I'm fairly new to Tomcat, and I think I can
figure out how to get access to the aforementioned
setAuthenticateHeader() method in the servlet context, but I don't
know how to make the container do that for the duration of a browser
session, as opposed to setting the www-authenticate header every time
my JSP or servlet is called.
-Mark
David Owens wrote:
The docs say this:
When a standard realm authenticates by retrieving the stored password
and comparing it with the value presented by the user, you can select
digested passwords by specifying the *digest* attribute on your <Realm>
element. The value for this attribute must be one of the digest
algorithms supported by the java.security.MessageDigest class (SHA, MD2,
or MD5). When you select this option, the contents of the password that
is stored in the Realm must be the cleartext version of the password, as
digested by the specified algorithm.
I have starred the word digest. If you look at the source for the page
you will notice the word digest is in <code> tags, and I think they are
trying to indicate this is a key word you can use in the <realm> tag.
Let us know if this works for you.
|)ave
-----Original Message-----
From: Mark Leone [mailto:[EMAIL PROTECTED] Sent: Wednesday, March
23, 2005 1:53 AM
To: Tomcat Users List
Subject: Re: DIGEST authentication; Does it work??
So at 3:00 AM I decided to read the Basic and Digest Access
Authentication spec (RFC 2617), and it says that MD5 is the default hash
algorithm. I had previously seen that Tomcat wasn't sending any response
headers explicitly specifying the hash algorithm, even though I had
specified SHA in the <realm/> element in Server.xml. So I changed my
digest algorithm for the realm to MD5, and DIGEST authentication is
now working.
I'd like to make it work with SHA-1. I've looked all through the
Tomcat documentation, and I can't find a configuration parameter to
set the www-authenticate response header to indicate SHA-1 algorithm
for the digest. I see the API that supports this in
org.apache.catalina.authenticator.DigestAuthenticator (
setAuthenticateHeader() ), but I can't find a configuration parameter
that will determine the value for "algorithm" passed to this method.
Does anyone know how I can set this?*
*
-Mark
Mark Leone wrote:
I found a silly classpath error that fixed the problem using
RealmBase. I didn't realize that my system still had environment
variable %catalina_home% pointing to an old tomcat 4.1.24 directory.
So when I opened a command window to generate digest values I was
executing RealmBase in tomcat 4.1.24. But guess what. When I digest
the same info with the same algorithm specifier (SHA) in Tomcat 4.1.24
and Tomcat 5.5.8 I get different digest values. And DIGEST
authentication still doesn't work, in either case. Something very
strange is going on here. :(
-Mark
Mark Leone wrote:
Okay, I was using 5.5.7. So I just downloaded the source and built
5.5.8, and things got worse. Digest authentication is not working for
me. I believe I've set everything up correctly. Using an HTTP monitor
I see a 401 response coming back from Tomcat with a
www-authenticate header whose parameters specify digest
authentication and identify the realm as JDBCRealm. And I have a
digested password that I created
by digesting {username}:JDBCRealm:{password} (including the colons-
is that correct?), as directed in the how-to documentation. But
when I enter that username and password, the authentication fails.
Now I used SHA-1 to digest the password, and my <realm/> element in
Server.xml identifies SHA as the digest algorithm for digesting
passwords. Does this mean that the DIGEST authentication will also be
done using SHA-1? Or do I need to specify that somewhere? Am I
missing something else?
I said it got worse with 5.5.8 because now I can't even get RealmBase
to generate a digested password. I enter
java -cp %catalina_home%\server\lib\catalina.jar
org.apache.catalina.realm.RealmBase -a SHA
{username}:JDBCRealm:{password}
and I get:
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/commons/lo
gging/LogFactory at
org.apache.catalina.realm.RealmBase.<clinit>(RealmBase.java:69)
So it's finding RealmBase, but while executing that code it fails
to find LogFactory. I don't see an org\apache\commons path in any
of the
class directories generated during the build. Do I have a defective
build? Was I supposed to download something else?
-Mark
Mark Thomas wrote:
Yes it does. I tested this extensively with both IE and Firefox. Any
combination of the following is OK:
Auth: BASIC, FORM, DIGEST
Realm: Memory, UserDatabase, JDBC, DataSource
Passwords: Cleartext, digested
There is a complication when using digested passwords with the
digest realm.
You need to be using 4.1.x from CVS HEAD or 5.5.8+
For more info see:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html
Mark
Mark Leone wrote:
I'm trying to use DIGEST authentication with Tomcat, and it doesn't
seem to work. I found some articles with Google about IE
implementing DIGEST authentication in a way that only worked with
MS servers, and I assume that hasn't been corrected. But I'm also
using Firefox with the same results as IE. I saw an article about a
workaround in Apache server to make DIGEST authentication work with
IE, but I didn't see anything about Tomcat. Anyone know of any
way to get DIGEST authentication in Tomcat to work with ANY browser?
I should mention that I'm also using digested passwords in a
JDBC Realm (implemented with mySQL), and I followed the how-to
instructions for creating digested passwords to work with DIGEST
authentication. And authentication with JDBCRealm works fine when I
use BASIC authentication.
For the record, I put the following in the Host element in
Server.xml
<Context path="/MyApp" docBase="MyApp">
<Valve
className="org.apache.catalina.authenticator.DigestAuthenticator"
disableProxyCaching="false" />
</Context>
I put the following in Server.xml's Engine element
<Realm className="org.apache.catalina.realm.JDBCRealm" debug="99"
driverName="com.mysql.jdbc.Driver"
connectionURL="jdbc:mysql:///Tomcat_Realm" userTable="users"
userNameCol="user_name" userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name" digest="SHA"/>
And I put the following in my app's web.xml
<security-constraint.../> (elided)
<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>JDBCRealm</realm-name>
</login-config>
<security-role.../> (elided)
And when I created the digested password to store in my JDBCRealm
database, I digested: (username) : JDBCRealm : (password). As
you can see, I specified "SHA" as the digest algorithm in
Server.xml's <realm> element, and I used SHA to create the
digested password that I stored in the database. I assume that
the server will prompt
the browser to use SHA also when it sends the challenge header
requesting DIGEST authentication?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
