Hi Mike, You can have a look at the FormAuthentication class in Cactus which does something similar.
Thanks -Vincent > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: 16 April 2004 13:09 > To: [EMAIL PROTECTED] > Subject: RE: NTLMAuthentication > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
