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.
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
