jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike.ra...@barclayscapital.com
Subject RE: NTLMAuthentication - SOLVED!
Date Tue, 20 Apr 2004 09:28:24 GMT
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: mike.raath@barclayscapital.com [mailto:mike.raath@barclayscapital.com]

Sent: 19 April 2004 13:27
To: cactus-user@jakarta.apache.org
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:vmassol@pivolis.com] 
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: mike.raath@barclayscapital.com
> [mailto:mike.raath@barclayscapital.com]
> Sent: 16 April 2004 13:09
> To: cactus-user@jakarta.apache.org
> 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:vmassol@pivolis.com]
> Sent: 16 April 2004 11:00
> To: 'Cactus Users List'
> Subject: RE: NTLMAuthentication
> 
> 
> 
> 
> > -----Original Message-----
> > From: Christopher Lenz [mailto:cmlenz@gmx.de]
> > 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: mike.raath@barclayscapital.com
> > >> [mailto:mike.raath@barclayscapital.com]
> > >> Sent: 16 April 2004 09:29
> > >> To: cactus-user@jakarta.apache.org
> > >> 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:vmassol@pivolis.com]
> > >> 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: mike.raath@barclayscapital.com
> > >>> [mailto:mike.raath@barclayscapital.com]
> > >>> Sent: 15 April 2004 10:17
> > >>> To: cactus-user@jakarta.apache.org
> > >>> 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:
cactus-user-unsubscribe@jakarta.apache.org
> > >>> For additional commands, e-mail:
> cactus-user-help@jakarta.apache.org
> > >>
> > >>
> > >>
> > >>
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail:
cactus-user-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail:
> cactus-user-help@jakarta.apache.org
> > >>
> > >>
> > >>
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail:
cactus-user-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail:
> cactus-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
cactus-user-help@jakarta.apache.org
> > >
> > >
> > --
> > Christopher Lenz
> > /=/ cmlenz at gmx.de
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-user-help@jakarta.apache.org

Mime
View raw message