Skip to Content.
Sympa Menu

shibboleth-dev - RE: Integration JUnit testing

Subject: Shibboleth Developers

List archive

RE: Integration JUnit testing


Chronological Thread 
  • From: "Howard Gilbert" <>
  • To: <>
  • Subject: RE: Integration JUnit testing
  • Date: Wed, 24 Aug 2005 16:20:16 -0400

> -----Original Message-----
> okay, now I think I may remember why I didn't use Mock Objects...
> mockrunner doesn't appear to have a simple way to specify a client
> SSL certificate in the request. unless I'm overlooking something... ?

First, I assume this question arises in the context of the AA or Artifact
queries, which are the places where a client cert can matter.

The answer (without putting it in a context) is that you set the
"javax.servlet.request.X509Certificate" attribute of the
MockHttpServletRequest object to point to an X509Cetificate[] that you get
from the SP Credentials. Then you pass the request over to the Servlet in
the IdP. This might not be understood without a bigger picture.

(Now the context)

Off list, I had an exchange with Scott about a proposal to mock up this part
of the protocol. The problem, from the point of the SP, is that the client
end of both of these exchanges is controlled from within OpenSAML. We seem
to be in agreement, and I have largely written but not yet tested the code.

If you really need to test the low level JSSE manipulations of the code,
then you need a complete functional test with a real Web Server. A Unit or
Integration Test can, for example, verify that a particular Certificate
chain that is supposed to validate against the Metadata works and another
one fails, but it does so by inserting them up at the HttpRequest object and
not down at the SSLSocketFactory level.

The trick is to make a copy of org.opensaml.provider.SOAPHTTPBindingProvider
and then change it to manipulate Mockrunner objects to have the same effect
as previous statements that manipulated the URLConnection.

The result is then mock versions of an HttpServletRequest and associated
control blocks that can be presented through the ServletTestModule directly
to the IdPProvider Servlet.

Since this is part of the OpenSAML layer, the TestCase has to somehow
convince SAML to use this substitute object instead of the normal class.
Fortunately, SAMLConfig has a Map keyed by binding string that designates
the class that handles that binding. We can create an alternate binding
string, or just change the default binding map, to replace the SSL socket
call through the Web Server with a Mockrunner call through the simulated
environment.

At that point, the IdP validates whatever certificate the TestCase has
inserted into the Request.

As I say, I have mostly written the MockHTTPBindingProvider but have not yet
tested its actual insertion and use.





Archive powered by MHonArc 2.6.16.

Top of Page