On Fri February 13 2009 3:09:31 am Gabo Manuel wrote: > Hi Dan, > > Just a few questions: > > 1. What class do I use to test the digest support you created? This one > is added as an In interceptor, right?
Not really, it's kind of built into the HTTPConduit. The Conduit already had plugable auth suppliers, but the API on it was really limitted to just being usable for basic auth. I updated the API a bit to support more complex stuff for Digest. Basically, if you turn on the auto redirect support and turn off chunking, it should be completely automatic. The first request will get the digest challenge and we'll compute the stuff and resend. If you want it to work "up front" so streaming still works, there is an setAuthSupplier(...) method on the HTTPConduit. Just call it with a new DigestAuthSupplier() and it should work fine. > 2. Does it support "auth-int" as qop No. I pretty much ported the http-client code from: http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module- client/src/main/java/org/apache/http/impl/auth/DigestScheme.java and that specifically says: auth-int is unsupported > 3. Does it support nextnonce I would say no. Again, that isn't mentioned in the http-client code so I'm going to assume the answer is no. > and just a generic question.. > > what is the purpose of the "opaque" token? as an additional variable to > the nonce? Absolutely no idea. It isn't used in any of the calculations at all. It just seems to be echoed back to the server exactly as is. For the most part, I just ported the http-client code into our AuthSupplier API's. Thus, what they don't support we wouldn't either. I've only really tested it with the digest support in tomcat as well. Dan > > Again, my thanks. > > Gabo > > Daniel Kulp wrote: > > On Friday, I committed code to trunk to make it do digest auth. I'll > > get that merged to 2.1.x today and get new snapshots up. I've only > > tested against a simple service running in tomcat right now so it would > > be GREAT if someone else gave it a quick try to make sure it works. > > > > One note: > > digest auth requires more of a "hand shake" and thus you will probably > > need to turn on request buffering. Turning on the auto-redirect > > property of the conduit will do that. MAY also need to turn off > > chunking. Not sure on that. > > > > > > Dan > > > > On Thursday 22 January 2009 8:14:05 pm krause wrote: > >> Any updates on this? > >> I think I have the same requirement and haven't been able to find any > >> info on how to do digest authentication at the transport layer, (i.e. > >> HTTP) with CXF. I have done it using Axis, which in turn uses > >> HttpClient and it is just a matter of adding the username and password > >> and HttpClient does the rest. The only info I have found regarding > >> digest authentication for CXF is related to WS-Security, wich is at a > >> higher level but is not what I need (which is arguably better, since it > >> is independent from the transport: http, jms, mail, etc.) . > >> > >> I have skimming through CXF documentation (and posts like this one) and > >> it seems that this might be accomplished using CXF interceptors, but I > >> don't have a clue on how to tap into the underlying http connection > >> management to handle digest authentication. > >> > >> I also found this > >> http://www.nabble.com/Using-HTTPClient-as-a-transport-td14715325.html > >> thread in which it is suggested that in order to use HttpClient as a > >> transport for CXF it has to be implemented as a conduit. > >> > >> The fact that there seems to be no easy way of doing it with CXF, and > >> that no one seems to have contributed an interceptor or conduit for > >> doing this makes me wonder if what I'm trying to do can be accomplished > >> some other way which I'm not aware of. > >> > >> There is a http://issues.apache.org/jira/browse/CXF-291 Jira issue > >> open for this, but there doesn't seem to be much activity. > >> > >> Any feedback would be very welcome. > >> Regards > >> > >> Gabo Manuel wrote: > >>> Hi All, > >>> > >>> I am currently trying to implement a ReST service and was hoping to put > >>> some security to it. Afaik, WS-security is already not an option since > >>> I am not exposing a SOAP service (am I wrong here?). > >>> > >>> I tried searching the forums for some hint on where to go. I was able > >>> to find entries re: Http Basic and SSL. I was hoping to take advantage > >>> of the username/pwd of Http Digest and use that later in the request > >>> processing, e.g. check privilege on the object accessed. > >>> > >>> I am already inclined to create a handler/interceptor to retrieve an > >>> "Authorization" header param and perform the hash calculation and > >>> comparison there. I am unsure of two things: > >>> > >>> ... > > > > ------------------------------------------------------------------------ > > > > > > No virus found in this incoming message. > > Checked by AVG - http://www.avg.com > > Version: 8.0.176 / Virus Database: 270.10.14/1917 - Release Date: > > 1/26/2009 6:37 PM -- Daniel Kulp [email protected] http://www.dankulp.com/blog
