Hi,
I didn't mean to exclude the basic authentication; I just like the
form-based & certificate ones better.
As for httpclient, the last time I looked(mid October), I recalled
seeing support for basic but not for certificate.
Let me download the source again to look at it.
Peter
"Vincent Massol" <[EMAIL PROTECTED]> on 12/17/2001 11:57:40 AM
Please respond to "Cactus Developers List"
<[EMAIL PROTECTED]>
To: "'Cactus Developers List'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Security testing in Cactus
I wouldn't exclude basic authentication, which is also widely used.
Regarding SSL, you're right, we would have to support it in Cactus,
which is why I'm advocating moving to Commons HttpClient which does
support it. Thoughts ?
-Vincent
> -----Original Message-----
> From: Peter Wong [mailto:[EMAIL PROTECTED]]
> Sent: 17 December 2001 17:36
> To: Cactus Developers List
> Subject: Re: Security testing in Cactus
>
>
>
> Hi,
>
> It seems to me that the 2 important authentication schemes are
> form-based and certificate via ssl.
>
> Peter
>
>
>
>
> "Vincent Massol" <[EMAIL PROTECTED]> on 12/17/2001 11:14:27 AM
>
> Please respond to "Cactus Developers List"
> <[EMAIL PROTECTED]>
>
> To: "'Cactus Developers List'" <[EMAIL PROTECTED]>
> cc:
> Subject: Security testing in Cactus
>
> Here is a summary on my views for supporting Security testing in
> Cactus
> :
>
> First, there are 2 areas Cactus users may wish to test :
> 1/ Programmatic security logic : This means to be able to unit test
> methods which have calls to getRemoteUser(), isUserInRole() and
> getUserPrincipal().
> 2/ Security integration testing : Verify that the security mappings
in
> web.xml and the interaction with the container work ok.
>
> * 1/ is easily achievable by adding a
WebRequest.setCredentials(String
> username) and a WebRequest.setCredentials(String username, Vector
> roles). The HttpServletRequestWrapper would use this information to
> return expected values from getRemoteUser(), isUserInRole() and
> getUserPrincipal(). However, this does not verify the interaction
with
> the container. On the other hand it is very easy to implement and
can
> make it in Cactus 1.3
>
> * 2/ is more difficult for 2 reasons :
> - the client part of Cactus need to be able to handle the
different
> authentication schemes (Basic Authentication, Form-based
> authentication
> and possibly Digest Authentication - although seldom used so we
could
> probably drop this one). Thus the client part of Cactus is becoming
> complex and I think it would need refactoring. It would be high time
> to
> move to Commons HttpClient and maybe even participate to include the
> feature it might be missing (notably, we need to verify if it
supports
> these authentication schemes).
> - We probably don't want to secure the Redirector Servlet as it
> would
> mean all tests will run in this secure mode whereas we may only wish
> to
> test security for such and such test cases. Thus before doing this,
we
> would need to implement a per testcase configuration (as discusses
in
> the past on this list (see thread "[proposal/poll] Per testcase
> configuration of web.xml" in archives). Another solution is to
figure
> out a way to have a per testcase redirector.
>
> To summarise, we can certainly include 1/ in Cactus 1.3 but 2/ would
> need more thinking and more work. We could target it for Cactus 1.4.
>
> What do you think ?
>
> Thanks
> -Vincent
>
>
>
> --
> To unsubscribe, e-mail: <
> mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <
> mailto:[EMAIL PROTECTED]>
>
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:cactus-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:cactus-dev-
> [EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
