> -----Original Message-----
> From: Peter Wong [mailto:[EMAIL PROTECTED]]
> Sent: 21 December 2001 15:50
> To: Cactus Developers List
> Subject: RE: Security testing in Cactus
>
>
>
> Hi Vincent,
>
> Yes, HttpClient supports https. What I meant by authentication was
> building the truststore & keystore, verifying the server's public key
> matches somewhere along a chain up to a root CA, validating with a crl
> if there is one, providing mechanism for user to select one of his
> certificates to submit if necessary, dealing with persistent storage
> on user's hard-drive etc.
do we need this on the client side of Cactus ?
Thanks
-Vincent
>
> Peter
>
>
>
>
> "Vincent Massol" <[EMAIL PROTECTED]> on 12/19/2001 02:50:18 PM
>
> Please respond to "Cactus Developers List"
> <[EMAIL PROTECTED]>
>
> To: "'Cactus Developers List'" <[EMAIL PROTECTED]>
> cc:
> Subject: RE: Security testing in Cactus
>
> I'm not sure what you are referring to. Since the beginning,
> HttpClient
> supports HTTPS (through the use of JSSE). Thus it is possible to call
> a
> web server which has SSL turned on.
>
> -Vincent
>
> > -----Original Message-----
> > From: Peter Wong [mailto:[EMAIL PROTECTED]]
> > Sent: 17 December 2001 19:01
> > To: Cactus Developers List
> > Subject: RE: Security testing in Cactus
> >
> >
> >
> > Hi,
> >
> > I just looked at httpclient's nightly built code and did not see
> > certificate auth.
> >
> > Peter
> >
> >
> >
> >
> > "Peter Wong" <[EMAIL PROTECTED]> on 12/17/2001 12:14:32 PM
> >
> > Please respond to "Cactus Developers List"
> > <[EMAIL PROTECTED]>
> >
> > To: "Cactus Developers List" <[EMAIL PROTECTED]>
> > cc:
> > Subject: RE: Security testing in Cactus
> >
> >
> >
> > 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]>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > 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: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]>
