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...
Keywords:
Status: NEW
Alias: None
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: jUDDI - within SOA
Version: 5.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Default User
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
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
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


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