Mailing-List: contact cactus-user-help@jakarta.apache.org; run by ezmlm
Message-ID: 
 <A93374CF4D13D311876F00805FFE21FC0B9609FE@exlpseu003.ldn.bzwint.com>
From: mike.raath@barclayscapital.com
To: cactus-user@jakarta.apache.org
Subject: RE: NTLMAuthentication
Date: Fri, 16 Apr 2004 11:56:03 +0100
MIME-Version: 1.0
Content-Type: text/plain

How can I get at the request from Cactus then - I could probably modify the
call so it calls getRemoteUser. But from Cactus (and I must stress I'm new
to it) it seems that all I get is the Cactus WebRequest object which doesn't
seem to expose the HttpServletRequest object.

Vincent, as far as using Basic is concerned - jCIFS looks at the
"Authorization" header and expects it to start with "NTLM" so I can't use
the BasicAuthentication class. 

-----Original Message-----
From: Christopher Lenz [mailto:cmlenz@gmx.de] 
Sent: 16 April 2004 10: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.

However, you probably are expecting a specific subtype of Principal in  
your code, right?

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.

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