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]

Reply via email to