Bug 779483 (SOA-1865)

Summary:	Integrate juddi's JBossAuthenticator
Product:	[JBoss] JBoss Enterprise SOA Platform 5	Reporter:	Marc Schoenefeld <mschoene>
Component:	jUDDI - within SOA	Assignee:	Ken Johnson <kejohnso>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	5.0.0 ER7	CC:	rcernich
Target Milestone:	---
Target Release:	FUTURE
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/SOA-1865
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:	SOA - ER7
Last Closed:		Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Marc Schoenefeld 2010-01-22 15:32:38 UTC

Date of First Response: 2010-03-02 18:27:00
project_key: SOA

SOA5 currently specifies "org.apache.juddi.v3.auth.JUDDIAuthenticator" in esb.juddi.xml, although there is jbossified "org.apache.juddi.auth.JBossAuthenticator" class provided in Juddi SVN [1] . I wonder if this could be covered by a quickstart or config option. 

[1] http://svn.apache.org/repos/asf/webservices/juddi/trunk/docs/examples/auth/JBossAuthenticator.java

Comment 1 Kevin Conner 2010-03-02 14:35:56 UTC

Link: Added: This issue depends JBESB-3190

Comment 2 Jeff DeLong 2010-03-02 23:27:00 UTC

I would like to see this capability added to the platform:

1) It is provided my jUDDI 
2) customers expect JBoss to provide integration with JBoss JAAS 
3) Apache jUDDI web site specifically states jUDDIAuthentication is not for production use 
4) If customers want to use jUDDI for registration of their web services, they will expect to have some control over which users can publish these services to the registry.

I have tested this in SOA-P 5. The issues I found are:

1) The jars in SOA-P 5 are signed and the JBossAuthenticator class has the same package name as classes in a signed jar which results in an exception. This can be resolved by packaging it in the same signed jar or changing the class name.

2) A default login module should be configured with in the esb.juddi.xml file in jboss-registry.sar
<!-- jUDDI Authentication module to use  -->
<entry key="juddi.authenticator">org.apache.juddi.auth.JBossAuthenticator</entry>
<entry key="juddi.securityDomain">java:/jaas/soa</entry>

If we use soa login module, then  I believe that there are possibly other users that must be added, e.g. jbossesb=jbossesb 

3) While I could login to the UDDI Console I immediately saw authentication errors when I tried to query for services. It appeared as though the credentials (password) was not being passed.

Comment 3 Anne-Louise Tangring 2010-09-21 19:16:20 UTC

John Graham to investigate. This may split into two JIRAs (jUDDI and ESB). No decision yet for SOA 5.1.0

Comment 4 Rob Cernich 2011-05-20 17:36:19 UTC

I've done a bit of investigating on this.  Beyond what's listed in Jeff's comment above...

The following users are required:  (conf/props/soa-users.properties)
# esb registry user/password from deployers/esb.deployer/jbossesb-properties.xml
root=root
# riftsaw registry user/password from deploy/jbossesb.sar/esb.juddi.client.xml
riftsaw=

The UDDI console requires some work to get authentication to working.  The current problem is that the page authenticates the web user, but UDDI requires separate authentication.  (In other words, the login page authenticates the user, giving them the ability to see the page, but does not authenticate the user against the UDDI registry so there is no content on the page.)  Refer to SecurityServiceImpl in the apache uddi-portlets project.