Hide Forgot
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
Link: Added: This issue depends JBESB-3190
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.
John Graham to investigate. This may split into two JIRAs (jUDDI and ESB). No decision yet for SOA 5.1.0
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.