Bug 873821 - UDDI v3 registry in SOA-P must support digital signatures in disconnected environments
Summary: UDDI v3 registry in SOA-P must support digital signatures in disconnected env...
Status: NEW
Alias: None
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: jUDDI - within SOA
Version: 5.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Default User
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2012-11-06 19:10 UTC by Rich Lucente
Modified: 2013-05-07 19:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

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

Note You need to log in before you can comment on or make changes to this bug.