I've done a fair bit of reading on this and what happens is a 3-stage negotiation:
Step 1 - the request is bounced back with a WWW-Authenticate NTLM header and 401 code Step 2 - the client responds with a "type 2" message and receives a challenge key from the server. The client then hashes the password using this key and ... Step 3 - ... Sends a type 3 message containing the LM (or LMv2) response and NTLM (or NTLMv2) response accordingly. So the key is the passing of the challenge key - if in the configure message I could perform this three stage handshake I'd be home and dry but I can't see how to do that. -----Original Message----- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: 16 April 2004 11:00 To: 'Cactus Users List' Subject: RE: NTLMAuthentication > -----Original Message----- > From: Christopher Lenz [mailto:[EMAIL PROTECTED] > Sent: 16 April 2004 11:36 > To: Cactus Users List > Subject: Re: NTLMAuthentication > > I would have suggested HttpServletRequestWrapper#setRemoteUser, but > that won't work for code that uses getUserPrincipal() :-( > > We probably should return a simulated user principal object when the > remote user name is simulated? But we aren't doing that currently. Yes, that could be useful. > > However, you probably are expecting a specific subtype of Principal in > your code, right? Oh, I didn't know it was being implemented this way! This breaks the advantage of having an spec and interface... > > In that case you'd be right that you'd need to create a > NTLMAuthentication class and plug it into Cactus. Note that the > underlying Commons-HttpClient library does actually support NTLM, but > the HttpClient-API isn't directly exposed in Cactus so accessing the > NTLM functionality might require a hack or some refactoring of Cactus > that is actually on the TODO plan. It should be relatively easy for someone who knows how NTLM works with Commons HttpClient to implement a NTLMAuthentication class for Cactus. Cactus now makes available the following objects to authentication classes: void configure(HttpState theState, HttpMethod theMethod, WebRequest theRequest, Configuration theConfiguration); Thanks -Vincent > > Cheers, > Chris > > Am 16.04.2004 um 10:40 schrieb Vincent Massol: > > Hi Mike, > > > > But you can get this by using any authentication mechanism (for ex by > > using the BASIC authentication)? From the application's point of view > > it > > would be exactly the same. > > > > -Vincent > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] > >> Sent: 16 April 2004 09:29 > >> To: [EMAIL PROTECTED] > >> Subject: RE: NTLMAuthentication > >> > >> Because the application needs to know the identity of the user - > > something > >> that jCIFS provides via its extended HttpServletRequest class's > >> implementation of getUserPrincipal(). > >> > >> There is validation in the application to ensure that only valid users > >> view > >> the resources (ie users in an LDAP group). > >> > >> -----Original Message----- > >> From: Vincent Massol [mailto:[EMAIL PROTECTED] > >> Sent: 15 April 2004 22:01 > >> To: 'Cactus Users List' > >> Subject: RE: NTLMAuthentication > >> > >> > >> Hi Mike, > >> > >> I have personally no knowledge of NTLM. I can only suggest disabling > > the > >> filter. > >> > >> Could you please elaborate on the reasons why you will not be able to > > full > >> test your application? > >> > >> Thanks > >> -Vincent > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] > >>> Sent: 15 April 2004 10:17 > >>> To: [EMAIL PROTECTED] > >>> Subject: NTLMAuthentication > >>> > >>> Has anyone managed to write an NTLMAuthentication class extending > >>> AbstractAuthentication? I'm using jCIFS on a corporate intranet (so > > we > >>> have single sign-on) but when running the unit tests authentication > >>> fails because > >>> of the jCIFS filter. I can obviously disable the filter, but then I > >> can't > >>> fully test other aspects of the application. > >>> > >>> Alternatively, can anyone suggest to me a better alternative? > >>> > >>> Mike > >>> > >>> > >>> > >> > > ----------------------------------------------------------------------- > > - > >>> For more information about Barclays Capital, please > >>> visit our web site at http://www.barcap.com. > >>> > >>> > >>> Internet communications are not secure and therefore the Barclays > >>> Group does not accept legal responsibility for the contents of this > >>> message. Although the Barclays Group operates anti-virus > > programmes, > >>> it does not accept responsibility for any damage whatsoever that is > >>> caused by viruses being passed. Any views or opinions presented are > >>> solely those of the author and do not necessarily represent those of > >> the > >>> Barclays Group. Replies to this email may be monitored by the > >> Barclays > >>> Group for operational or business reasons. > >>> > >>> > >> > > ----------------------------------------------------------------------- > > - > >>> > >>> > >>> > > --------------------------------------------------------------------- > >>> 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] > > > > > -- > Christopher Lenz > /=/ cmlenz at gmx.de > > > --------------------------------------------------------------------- > 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]
