Red Hat Training

A Red Hat training course is available for JBoss Enterprise SOA Platform

Chapter 18. Securing the Service Registry

18.1. Service Registry Authentication


Here is a theoretical understanding of how the authentication process works.

Authentication is a two-phase process. These are known as the authenticate phase and the identify phase. Both of these phases are represented by a method in the Authenticator interface.
The authenticate phase occurs when the GetAuthToken request is made. The goal of this phase is to turn a user id and credentials into a valid publisher id. The publisher id (referred to as the authorized name in UDDI terminology) is the value that assigns ownership within UDDI. Whenever a new entity is created, it must be tagged with ownership by the authorized name of the publisher.
The value of the publisher id is irrelevant to the jUDDI Registry: the only requirement is that one exists to assign to new entities so it must be non-null. Upon completion of the GetAuthToken request, an authentication token is issued to the caller.
When you make subsequent calls to the UDDI API that require authentication, you must provide the token issued in response to the GetAuthToken request. This leads to the identify phase.
The identify phase is responsible for turning the authentication token (or the publisher id associated with that token) into a valid UddiEntityPublisher object. This object contains all the properties necessary to handle ownership of UDDI entities. Thus, the token (or publisher id) is used to identify the publisher.
The two phases provide compliance with the UDDI authentication structure and grant flexibility if you wish to provide your own authentication mechanism.
Handling of credentials and publisher properties could be done entirely outside of the jUDDI Registry. However, by default, the Registry provides the Publisher entity, which is a sub-class of UddiEntityPublisher. This sub-class makes publisher properties persist within the jUDDI Registry.

18.2. authToken

An authToken is a security container holding password credentials.

18.3. authToken and the Service Registry

In order to enforce proper write access to the Service Registry, each request made to it needs a valid authToken.


Note that read access is not restricted at all.

18.4. Obtain an authToken

Procedure 18.1. Task

  1. Make a GetAuthToken() request.
  2. A GetAuthToken object is returned. Set a userid and credential (password) on this object:
    org.uddi.api_v3.GetAuthToken ga = new org.uddi.api_v3.GetAuthToken();
    org.uddi.api_v3.AuthToken token = securityService.getAuthToken(ga);
  3. Locate the configuration file in SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF. Open it in a text editor.
  4. Configure the juddi.authenticator property to how the Service Registry will check the credentials passed to it by the GetAuthToken request. (By default it uses the jUDDIAuthenticator implementation.)
  5. Save the file and exit.

18.5. Security Authentication Implementations Available for the Service Registry

jUDDI Authentication


Do not use this authentication method in a production environment. It accepts any credentials provided, and effectively removes the need for clients to authenticate when accessing the registry.
The default authentication mechanism provided by the Service Registry is the jUDDIAuthenticator. jUDDIAuthenticator's authenticate phase checks to see if the, user ID submitted matches against a record in the Publisher table. No credentials checks are made. If, during the authentication process, the Publisher record is found to be non-existent, it is added "on-the-fly".
In the identify phase, the publisher ID is used to retrieve the Publisher record and return it. The Publisher inherits every property it needs from UddiEntityPublisher:
juddi.authenticator = org.apache.juddi.auth.JUDDIAuthentication
The authenticate phase checks that the user id and password match a value in the XML file. The identify phase uses the user ID to populate a new UddiEntityPublisher.
The CryptedXMLDocAuthentication implementation is similar to the XMLDocAuthentication implementation, but the passwords are encrypted:
juddi.authenticator = org.apache.juddi.auth.CryptedXMLDocAuthentication
juddi.usersfile = juddi-users-encrypted.xml
juddi.cryptor = org.apache.juddi.cryptor.DefaultCryptor
Here, the user credential file is juddi-users-encrypted.xml, and the content of the file will be similar to this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user userid="anou_mana" password="+j/kXkZJftwTFTBH6Cf6IQ=="/>
<user userid="bozo" password="Na2Ait+2aW0="/>
<user userid="sviens" password="+j/kXkZJftwTFTBH6Cf6IQ=="/>
The DefaultCryptor implementation uses BEWithMD5AndDES and Base64 to encrypt the passwords.


You can use the code in the AuthenticatorTest to learn more about how to use this Authenticator implementation. You can plug in your own encryption algorithm by implementing the org.apache.juddi.cryptor.Cryptor interface and referencing your implementation class in the juddi.cryptor property.
The authenticate phase checks that the user ID and password match values in the XML file. The identify phase uses the user ID to populate a new UddiEntityPublisher.
LDAP Authentication
Use LdapSimpleAuthenticator to authenticate users via LDAP's simple authentication functionality. This class allows you to authenticate a user based on an LDAP principle, provided that the principle and the jUDDI publisher ID are identical.
JBoss Authentication
A final alternative is to interface with third-party credential stores. You can link it to the JBoss Application Server's authentication component.
You will find the JBossAuthenticator class provided in the docs/examples/auth directory. This class enables jUDDI deployments on JBoss to use a server security domain to authenticate users.

18.6. Configure XMLDocAuthentication

Procedure 18.2. Task

  1. Create a text file called juddi-users.xml and save it in jbossesb-registry.sar.
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
        <user userid="sscholl" password="password" />
        <user userid="dsheppard" password="password" />
        <user userid="vbrittain" password="password" />
  2. Save the file and exit.
  3. Add the file to the class-path.
  4. Open the file in your text editor (located in SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF).
  5. Modify the file so that it looks like this:
    juddi.authenticator = org.apache.juddi.auth.XMLDocAuthentication
    juddi.usersfile = juddi-users.xml
  6. Save the file and exit.

18.7. Lightweight Directory Access Protocol (LDAP)

Lightweight Directory Access Protocol (LDAP) is a protocol for accessing distributed directory information over the internet.

18.8. Configure LDAP Authentication

Procedure 18.3. Task

  1. Locate the file in SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF. Open it in your text editor.
  2. Add the following configuration settings:
    The juddi.authenticator.url property tells the LdapSimpleAuthenticator class where the LDAP server resides.
  3. Save the file and exit.

18.9. Configure JBoss Authentication

Procedure 18.4. Task

  1. Locate the file in SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF. Open it in your text editor.
  2. Add the following lines to the file:
    The juddi.authenticator property connects the JbossAuthenticator class to the jUDDI Registry's Authenticator framework. The tells JBossAuthenticator where it can find the Application Server's security domain. It uses this domain to perform the authentications.
    Note that JBoss creates one security domain for each application policy element in the SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml file. These domains are bound to the server JNDI tree with this name: java:/jaas/<application-policy-name>. (If a look-up refers to a non-existent application policy, a policy named other will be used by default.)
  3. Save the file and exit.