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