Description of problem:

The US Army WIN-T program is evaluating moving to SOA-P in order to have a supported JBoss UDDI v3 registry so they no longer have to pay a premium for Systinet.  The requirement they're trying to satisfy is:

   "The UDDI registry provided by Systinet uses UDDI version 3.0, which supports digital signatures for registry entries."

Jess Sightler, a Red Hat consultant, pointed out that the DoD Application STIG (Security Technical Implementation Guideline) states:

   (APP3840.1: CAT II) The Designer will ensure UDDI versions are used supporting digital signatures of registry entries.

A Category II finding is significant and can prevent a system from receiving authority to operate (ATO) per DoD security accreditation processes.

Digitally signed registry entries are failing in Apache jUDDI as discussed in an email exchange with Kurt Stam:

On 7/6/12 1:48 PM, Jess Sightler wrote:
> I've tried passing a signed business entity to jUDDI, but the signature was lost. In looking at the code, I don't see any code to retrieve it from the JAXB objects and save it to the database, so I think this feature is missing. Do you see anything to indicate otherwise?
I guess you can add it to the mapping (and the database?), so it does
get saved? The mapping is pretty straightforward.
>
> When grabbing the client classes via code like this:
>
> [...]
> String clazz = UDDIClientContainer.getUDDIClerkManager(null).getClientConfig().getUDDINode("default").getProxyTransport();
> Class<?> transportClass = ClassUtil.forName(clazz, Transport.class);
> if (transportClass != null) {
>         Transport transport = (Transport) transportClass.getConstructor(String.class).newInstance("default");
>         System.out.println("Transport: " + transport.getClass().getName());
>         security = transport.getUDDISecurityService(secEndpoint + "?wsdl");
> [...]
>
> The transport.getUDDISecurityService ends up triggering a load of the WSDL. This then triggers loads of various XSDs. Most of these are contained within uddi-ws-3.1.3.jar with local references to other schemas within the jar itself. However, uddi-ws-3.1.3.jar/www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd contains a reference to http://www.w3.org/2001/XMLSchema.dtd. When using CXF, this ends up getting retrieved. If no public internet access is available, it fails.
Hmm In
http://svn.apache.org/repos/asf/juddi/trunk/juddi-client/src/main/java/org/apache/juddi/v3/client/transport/JAXWSTransport.java

We go straight to the endpoint and the wsdl and xsds are obtained from
the uddi-ws jar. You can probably fix any dtd references in the xsds to
be local too and add them to the jar. That way you can use it w/o having
access to the public internet.
>
> I'm guessing you haven't run into either of these issues? :-)
>
> Thanks,

Version-Release number of selected component (if applicable):
6.0

How reproducible:
see above