Hi Mike, Cool! I'm glad you succeeded. Are you using HttpClient's NTLM authentication?
Thanks -Vincent > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: 20 April 2004 11:28 > To: [EMAIL PROTECTED] > Subject: RE: NTLMAuthentication - SOLVED! > > The problem I had was that I was trying to do the full authentication in > the > configure() - what I am now doing (which works) is the following: > > - Attempt connection - should fail 401 > - get WWW-Authenticate header (if available) > - If starts with NTLM, set type 1 response message > - Attempt connection - should fail 401 > - get WWW-Authenticate header > - extract challenge key > - Set type 3 response message > - exit method > > The key here is I removed the explicit connection attempt after setting > the > type 3 header - this should be left to the Cactus framework. > > Thanks Vincent for your help on this. > > Mike > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > Sent: 19 April 2004 13:27 > To: [EMAIL PROTECTED] > Subject: RE: NTLMAuthentication > > > Thanks for your help so far Vincent... > > I think I'm getting close to a solution now - basing my NTLMAuthentication > class on FormAuthentication I can now do an authentication handshake which > works! > > BUT there is still a problem. Authentication still fails at the GetResults > stage of the test. I think the problem would be solved if I could > understand > what happens to the Session Object - jCIFS sets a parameter in the Session > once it is authorised (and this is correctly set during the handshake > which > takes place in the authenticate method) but the session object is null > when > it next goes through the jCIFS filter - this is when it is calling > /ServletRedirector?Cactus_Service=GET_RESULTS > > What can I do to ensure persistence of the session? > > Mike > > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 16 April 2004 12:20 > To: 'Cactus Users List' > Subject: RE: NTLMAuthentication > > > 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] > > --------------------------------------------------------------------- > 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]
