I solved the last problem passing to tomcat 5.5.16 .
At the end everything work as i desired (well i didn't do many tests so
that's what I hope).
Thanks your help and your patience
Alessandro
On 3/24/06, Alessandro Colantoni <[EMAIL PROTECTED]> wrote:
>
> Hi!
> One day after i understood what you explained me.
> HexUtils.convert just do an hex representation in a string format of the
> binary number represented by the array of byte.
>
> I taught that a solution to my problem could be implement a custom realm,
> that extends JDBCrealm and overwrite the method getPassword in such a way
> protected String getPassword(String username) {
> System.out.println("username= "+username);
> String password=super.getPassword(username);
> log.info("password="+password);
> String hexpassword=HexUtils.convert(password.getBytes());
> log.info("hexpassword="+hexpassword);
> return hexpassword;
> }
>
> In theory should work , but I don't know why tomcat still uses the
> getPassword of the JDBCrealm , cause I don't see messages printed.
> But this is an other problem, and that's better I open another thread.
> I hope I'm following the rigtht way
>
>
> On 3/23/06, Alessandro Colantoni <[EMAIL PROTECTED]> wrote:
> >
> > Hi !
> > I'm lost. Sorry.
> > I don't understand when you say
> > >I can guarantee that
> > >MessageDigest.digest(), which returns an array of bytes, will NOT
> > return an
> > >array of bytes every time that can be transmitted on a URL i.e. is a
> > printable
> > >string.
> >
> > I will try to explain better what I have done
> > I have an algorithm called manolo (from the name of the manager of the
> > other application that passed it to me).
> > I wrote a class
> > public class ManoloMessageDigestSpi extends MessageDigestSpi implements
> > Cloneable
> >
> > I have in this class the field
> > private byte[] digest = null;
> >
> > I implemented the method engineDigest:
> >
> > protected byte[] engineDigest(){
> > byte[] completedDigest=this.digest;
> > engineReset();
> > return completedDigest;
> > }
> >
> > in the engineUpdate(byte input) I just set the field digest with the
> > encrypted value of input using the manolo algorithm.
> >
> >
> > I wrote a Provider called ManoloProvider
> >
> > public final class ManoloProvider extends Provider{
> >
> > public ManoloProvider() {
> > super("manolo", 1.0, "algoritmo pasado por Manolo el
> > 21-03-2006");
> > put ("MessageDigest.manolo","
> > com.steria.tc.security.ManoloMessageDigestSpi ");
> > }
> > }
> > Then in a servlet that load on startup I do something like that
> >
> > Security.addProvider(new ManoloProvider)
> >
> >
> > In the context.xml of my application I put
> > <Realm className = "org.apache.catalina.realm.JDBCRealm"
> > digest="manolo"
> > .....
> > ....
> > />
> >
> > When The other application(developed in power builder) store a password
> > use the manolo algorithm to encrypt it. So what it stores is the same
> > value of
> > MessageDigest.update(cleartext);
> > MessageDigest.digest().toString().
> >
> > So let's call:
> > cleartext : password in cleartext
> > digested : password encrypted
> > converted: digested converted with HexUtils.convert
> > At the end, when Tomcat authenticates it will compare converted with
> > digested and always fail.
> >
> > Everything work fine if was my application to store password, storing
> > RealmBase.Digest(cleartext,manolo)
> >
> > Thanks for attention
> > Alessandro
> >
> >
> >
> >
> >
> >
> > On 3/22/06, Jay Burgess <[EMAIL PROTECTED]> wrote:
> > >
> > > Then maybe I'm misunderstanding something. But I can guarantee that
> > > MessageDigest.digest(), which returns an array of bytes, will NOT
> > > return an
> > > array of bytes every time that can be transmitted on a URL i.e. is a
> > > printable
> > > string. That's why it has to be encoded in some form, and two hex
> > > chars/bytes
> > > is the way this gets encoded.
> > >
> > > However, if you really do want to undo the encoding, simply reverse
> > > the logic of
> > > the encode() method in the MD5Encoder.java file.
> > >
> > > Alternatively, if you are just trying to authenticate something in
> > > your code, it
> > > may work to just run through the digest and encode steps yourself,
> > > then compare
> > > your end result with what the user sent. If they're the same, then
> > > they're
> > > authenticated, without you needing to "undo" anything.
> > >
> > > Jay
> > >
> > > -----Original Message-----
> > > From: Alessandro Colantoni [mailto: [EMAIL PROTECTED]
> > > Sent: Wednesday, March 22, 2006 12:37 PM
> > > To: Tomcat Users List
> > > Subject: Re: return (HexUtils.convert(md.digest())) in RealmBase
> > >
> > > Thanks for answer.
> > > I'm sure that the byte representation is printable, because that's a
> > > very
> > > easy algorithm, and it is working since some year storing correct
> > > encrypted
> > > password with the other application.
> > > What i should need is an inverse operation of the HexUtils.convert.
> > > Is there such an algorithm?
> > > I 'll explain better.
> > > Lets call this inverse operation convert_inv.
> > > It should be so that
> > >
> > > HexUtils.convert
> > >
> > > (convert_inv(myAlgorithm(myClearCredential)))=myAlgorithm(myClearCredential).
> > > So including convert_inv in myAlgorithm (while the other application
> > > follow
> > > with the original one) I solve my problem.
> > >
> > > Is it possible?
> > > Thanks for help
> > > Alessandro
> > >
> > >
> > >
> > >
> > >
> > > On 3/22/06, Jay Burgess <[EMAIL PROTECTED] > wrote:
> > > >
> > > > I think this is the right answer:
> > > >
> > > > digest() returns a sequence of bytes. Depending on the values of
> > > the
> > > > individual
> > > > bytes, if you were to try and convert it to String, you can end up
> > > with
> > > > non-printable characters, etc.
> > > >
> > > > I'm assuming that HexUtils.convert() turns each 4 bits of each byte
> > > into a
> > > > hex
> > > > character, so that you end up with a proper String representation of
> > > the
> > > > digest
> > > > that can be sent as part of a URL.
> > > >
> > > > Jay
> > > >
> > > > | Jay Burgess [Vertical Technology Group]
> > > > | http://www.vtgroup.com/
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Alessandro Colantoni [mailto: [EMAIL PROTECTED] ]
> > > > Sent: Wednesday, March 22, 2006 12:12 PM
> > > > To: Tomcat Users List
> > > > Subject: return (HexUtils.convert(md.digest())) in RealmBase
> > > >
> > > > Hi All!
> > > > I saw that both method Digest(..) and digest(..) in RealmBase return
> > > (
> > > > HexUtils.convert(md.digest())) and not just
> > > > md.digest().toString.
> > > >
> > > > My problem is that user table is maintained by another application
> > > > developed
> > > > in an other technology.
> > > > My application uses this table just to authenticate.
> > > > The password of user table is encrypted with an algorithm I've been
> > > done.
> > > > I wrote a MessageDigestSpi for that algorithm, I wrote my provider,
> > > I
> > > > registered it and everything looks work fine.
> > > > Except that of course if I do:
> > > > RealmBase.Digest(myCredentials,myAlgorithm);
> > > >
> > > > I get a result different from doing
> > > > MessageDigest md = MessageDigest.getInstance(myAlgorithm);
> > > > md.update(myCredentials.getBytes());
> > > > md.digest().toString;
> > > >
> > > > but the same result of
> > > > MessageDigest md = MessageDigest.getInstance(myAlgorithm);
> > > > md.update(myCredentials.getBytes());
> > > > HexUtils.convert(md.digest())
> > > >
> > > > So the problem is that the other application stores without using
> > > the
> > > > HexUtils.convert method
> > > > but when tomcat authenticates it uses it.
> > > >
> > > > One solution could be write a Realm class that extends the JDBCRealm
> > > (the
> > > > one I'm using) and overwrite these methods.
> > > > But I'm afraid that in different versions of Tomcat (i don't want
> > > link to
> > > > one) could be different signature of these methods.
> > > > There's another solution?
> > > > At least avoiding overwriting these very important methods?
> > > >
> > > > And just for curiosity, why HexUtils.convert has been utilized?
> > > >
> > > > Thanks in advance for help and have a nice springtime
> > > > Alessandro
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > 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]
> > >
> > >
> >
>
