Bug 873821

Summary: UDDI v3 registry in SOA-P must support digital signatures in disconnected environments
Product: [JBoss] JBoss Enterprise SOA Platform 5 Reporter: Rich Lucente <rlucente>
Component: jUDDI - within SOAAssignee: Default User <jbpapp-maint>
Status: NEW --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.0CC: atangrin, jsightle, soa-p-jira
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Rich Lucente 2012-11-06 19:10:33 UTC
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

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):

How reproducible:
see above