Bug 779478 (SOA-1862)

Summary: jUDDI v3 URLs are not secured
Product: [JBoss] JBoss Enterprise SOA Platform 5 Reporter: Len DiMaggio <ldimaggi>
Component: Security, jUDDI - within SOAAssignee: Julian Coleman <jcoleman>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 5.0.0 ER7CC: jcoleman, kurt.stam
Target Milestone: ---   
Target Release: 5.2.0 GA, 5.2.0.ER5   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-1862
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-08 23:38:51 UTC 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 Len DiMaggio 2010-01-22 02:11:13 UTC 
Date of First Response: 2010-01-22 10:29:09
project_key: SOA

The servlet + console URLs exposed by the ER7 build SOA-P 5.0 server are password protected:

=========================================
 lynx -dump http://localhost:8080/uddi-console/
   You must provide security credentials to access this management console.

                       User Name ____________________
                       Password  ____________________
                                 Log In
=========================================

But the URLs exposed by jUDDI v3.0 are not:

http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl
http://127.0.0.1:8080/juddiv3/services/inquiry?wsdl
http://127.0.0.1:8080/juddiv3/services/publish?wsdl
http://127.0.0.1:8080/juddiv3/services/publisher?wsdl
http://127.0.0.1:8080/juddiv3/services/security?wsdl
http://127.0.0.1:8080/juddiv3/services/subscription?wsdl
http://127.0.0.1:8080/juddiv3/services/subscription-listener?wsdl

=========================================

[ldimaggi@ldimaggi ~]$ lynx -dump -source http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl

<definitions targetNamespace='urn:uddi-org:v3_service' xmlns='http://schemas.xmlsoap.org/wsdl/' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' xmlns:uddi_api_v3_binding='urn:uddi-org:api_v3_binding' xmlns:uddi_custody_v3_binding='urn:uddi-org:custody_v3_binding' xmlns:uddi_repl_v3_binding='urn:uddi-org:repl_v3_binding' xmlns:uddi_sub_v3_binding='urn:uddi-org:sub_v3_binding' xmlns:uddi_subr_v3_binding='urn:uddi-org:subr_v3_binding' xmlns:uddi_vs_v3_binding='urn:uddi-org:vs_v3_binding' xmlns:uddi_vscache_v3_binding='urn:uddi-org:vscache_v3_binding'>
 <documentation>WSDL service definition for UDDI 3.0.2 specification</documentation>
 <import location='http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl&amp;resource=uddi_vs_v3_binding.wsdl' namespace='urn:uddi-org:vs_v3_binding'></import>
 <import location='http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl&amp;resource=uddi_vscache_v3_binding.wsdl' namespace='urn:uddi-org:vscache_v3_binding'></import>
 <import location='http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl&amp;resource=uddi_sub_v3_binding.wsdl' namespace='urn:uddi-org:sub_v3_binding'></import>
 <import location='http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl&amp;resource=uddi_repl_v3_binding.wsdl' namespace='urn:uddi-org:repl_v3_binding'></import>
 <import location='http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl&amp;resource=uddi_api_v3_binding.wsdl' namespace='urn:uddi-org:api_v3_binding'></import>
 <import location='http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl&amp;resource=uddi_subr_v3_binding.wsdl' namespace='urn:uddi-org:subr_v3_binding'></import>
 <import location='http://127.0.0.1:8080/juddiv3/services/custody-transfer?wsdl&amp;resource=uddi_custody_v3_binding.wsdl' namespace='urn:uddi-org:custody_v3_binding'></import>
 <service name='UDDI_Service'>
  <port binding='uddi_subr_v3_binding:UDDI_SubscriptionListener_SoapBinding' name='UDDI_SubscriptionListener_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/subscription-listener'/>
  </port>
  <port binding='uddi_api_v3_binding:UDDI_Inquiry_SoapBinding' name='UDDI_Inquiry_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/inquiry'/>
  </port>
  <port binding='uddi_custody_v3_binding:UDDI_CustodyTransfer_SoapBinding' name='UDDI_Custody_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/custody-transfer'/>
  </port>
  <port binding='uddi_vscache_v3_binding:UDDI_ValueSetCaching_SoapBinding' name='UDDI_ValueSetCaching_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/valuesetcaching'/>
  </port>
  <port binding='uddi_api_v3_binding:UDDI_Security_SoapBinding' name='UDDI_Security_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/security'/>
  </port>
  <port binding='uddi_api_v3_binding:UDDI_Publication_SoapBinding' name='UDDI_Publication_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/publish'/>
  </port>
  <port binding='uddi_sub_v3_binding:UDDI_Subscription_SoapBinding' name='UDDI_Subscription_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/subscription'/>
  </port>
  <port binding='uddi_repl_v3_binding:UDDI_Replication_SoapBinding' name='UDDI_Replication_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/replication'/>
  </port>
  <port binding='uddi_vs_v3_binding:UDDI_ValueSetValidation_SoapBinding' name='UDDI_ValueSetValidation_Port'>
   <soap:address location='http://127.0.0.1:8080/juddiv3/services/valuesetvalidation'/>
  </port>
 </service>
</definitions>
Comment 1 Marc Schoenefeld 2010-01-22 15:29:09 UTC 
Mitre recomments protecting WSDL access to a restricted audience, as information about endpoints and methods could leak (CWE-651). 
Having those locked down (at least basic auth) in the default looks like a proper choice. 

(http://cwe.mitre.org/data/definitions/651.html)
Comment 3 Anne-Louise Tangring 2010-09-21 19:15:49 UTC 
John Graham to investigate. This may split into two JIRAs (jUDDI and ESB). No decision yet for SOA 5.1.0
Comment 4 Kurt Stam 2011-07-15 15:12:46 UTC 
Support supplying credentials for basic authentication slated for jUDDI-3.1.1: https://issues.apache.org/jira/browse/JUDDI-512
Comment 5 Kurt Stam 2011-09-13 18:34:07 UTC 
Some comments:

1. In jUDDI-3.1.0 the WSDLs can be locked down with basic authentication without any issue. The jUDDI client is getting at the service URLs directly (not using the wsdl urls anymore). Though there is one exception which is the JUDDIApiService (we will change that too). Then again in this case I'm not sure what the big deal is since the WSDLs are part of the UDDIv3 public spec. Protecting the URLs can be achieved in the web.xml if needed. We may want to do this by default.

2. Eventhough (1) is all that is talked about we should then also protect the actual service endpoints. I can think of two ways:
     - application level, jUDDI supports requiring an authentication token on inquiries just like it does for publishing right now. For that use 'juddi.authenticate.Inquiry' in the juddiv3.properties on the server.
     - basic authentication, for that we'd add basic authentication settings to the web.xml much like (1), and then we have to set the credentials on the client call. This is what https://issues.apache.org/jira/browse/JUDDI-512 speaks to.
Comment 6 Kurt Stam 2011-09-14 18:12:21 UTC 
When using the *juddi-client-3.1.1* it is now possible to use WSTransport against a WebServices deployment which is protected by Basic Authentication. To set the protection add the following fragment to the juddiv3.war/WEB-INF/web.xml

 <security-role>
      <role-name>JBossAdmin</role-name>
   </security-role>
   <security-constraint>
      <web-resource-collection>
         <web-resource-name>Authenticated Realm</web-resource-name>
         <url-pattern>/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>JBossAdmin</role-name>
      </auth-constraint>
   </security-constraint>
   <login-config>
      <auth-method>BASIC</auth-method>
   </login-config>

and to the juddiv3.war/WEB-INF/jboss-web.xml add

<security-domain>java:/jaas/soa</security-domain>

Then, the juddi-client needs to be given the credentials to login. Therefore add the following properties to the uddi.xml

<property name="basicAuthUsername" value="<username>" />
<property name="basicAuthPassword" value="<password>" />

where in soa the default username/password would be admin/admin
Comment 7 Julian Coleman 2011-09-28 16:23:59 UTC 
From IRC: as well as adding the above to juddiv3.war, we should also add commented
out basicAuthUsername/basicAuthPassword properties both to esb.uddi.xml, and to
riftsaw.uddi.xml.
Comment 8 Len DiMaggio 2011-10-21 14:23:42 UTC 
Verified fixed in ER5 build
Comment 9 David Le Sage 2011-11-08 23:01:41 UTC 
Temporarily reopening to update release note info.
Comment 10 David Le Sage 2011-11-08 23:38:38 UTC 
Release Notes Docs Status: Added: Documented as Resolved Issue
Writer: Added: dlesage
Release Notes Text: Added: https://issues.jboss.org/browse/SOA-1862

Whilst the servlet and console URLs exposed by SOA Server were password-protected, the URLs exposed by jUDDI v3.0 were not. When using the juddi-client-3.1.1 it is now possible to use WSTransport against a WebServices deployment which is protected by Basic Authentication.