Apache jUDDICommunity Documentation
In order to enforce proper write access to jUDDI, each request to jUDDI needs a
valid authToken
. Note that read access is not restricted
and therefore queries into the registries are not restricted.
To obtain a valid authToken
a
getAuthToken()
request must be made, where a
GetAuthToken
object is passed. On the
GetAuthToken
object a userid and
credential (password) needs to be set.
org.uddi.api_v3.GetAuthToken ga = new org.uddi.api_v3.GetAuthToken(); ga.setUserID(pubId); ga.setCred(""); org.uddi.api_v3.AuthToken token = securityService.getAuthToken(ga);
The property juddi.auth in the
juddi.properties
configuration file can be used to configure
how jUDDI is going to check the credentials passed in on the
GetAuthToken
request. By default jUDDI uses the
JUDDIAuthenticator
implementation. You can provide your own
authentication implementation or use any of the ones mention below. The
implementation needs to implement the
org.apache.juddi.auth.Authenticator
interface, and
juddi.auth property should refer to the implementation class.
There are two phases involved in Authentication. The authenticate phase and the
identify phase. Both of these phases are represented by a method in the
Authenticator
interface.
The authenticate phase occurs during the GetAuthToken
request as described above. 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 can be completely
transparent to jUDDI – the only requirement is that one exists to assign to new
entities. Thus, the authenticate phase must return a non-null publisher id. Upon
completion of the GetAuthToken
request, an authentication
token is issued to the caller.
In subsequent calls to the UDDI API that require authentication, the token issued
from the GetAuthToken
request must be provided. This
leads to the next phase of jUDDI authentication – the identify phase.
The identify phase is responsible for turning the authentication token (or the
publisher id associated with that authentication token) into a valid
UddiEntityPublisher
object. The
UddiEntityPublisher
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 for users that wish to provide their own authentication mechanism.
Handling of credentials and publisher properties can be done entirely outside of
jUDDI. However, jUDDI provides the Publisher entity, which is a sub-class of
UddiEntityPublisher
, to persist publisher properties within
jUDDI. This is used in the default authentication and is the subject of the next
section.
The default authentication mechanism provided by jUDDI is the
JUDDIAuthenticator
. The authenticate phase of the
JUDDIAuthenticator
simply checks to see if the user id
passed in has an associated record in the Publisher table. No credentials checks
are made. If, during authentication, the publisher does not exist, it the
publisher is added on the fly.
Do not use jUDDI authentication in production.
The identify phase uses the publisher id to retrieve the Publisher record and return
it. All necessary publisher properties are populated as Publisher inherits from
UddiEntityPublisher
.
juddi.auth = org.apache.juddi.auth.JUDDIAuthentication
The XMLDocAuthentication
implementation needs a XML file on
the classpath. The juddi.properties
file would need to look
like
juddi.auth = org.apache.juddi.auth.XMLDocAuthentication juddi.usersfile = juddi-users.xml
where the name of the XML can be provided but it defaults to
juddi-users.xml
, and the content of the file would looks
something like
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <juddi-users> <user userid="anou_mana" password="password" /> <user userid="bozo" password="clown" /> <user userid="sviens" password="password" /> </juddi-users>
The authenticate phase checks that the user id and password match a value in the
XML file. The identify phase simply uses the user id to populate a new
UddiEntityPublisher
.
The CryptedXMLDocAuthentication
implementation is similar
to the XMLDocAuthentication
implementation, but the
passwords are encrypted
juddi.auth = org.apache.juddi.auth.CryptedXMLDocAuthentication juddi.usersfile = juddi-users-encrypted.xml juddi.cryptor = org.apache.juddi.cryptor.DefaultCryptor
where the name user credential file is
juddi-users-encrypted.xml
, and the content of the file would
looks something like
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <juddi-users> <user userid="anou_mana" password="+j/kXkZJftwTFTBH6Cf6IQ=="/> <user userid="bozo" password="Na2Ait+2aW0="/> <user userid="sviens" password="+j/kXkZJftwTFTBH6Cf6IQ=="/> </juddi-users>
The DefaultCryptor
implementation uses
BEWithMD5AndDES
and Base64
to encrypt the
passwords. Note that the code in the AuthenticatorTest
can
be used to learn more about how to use this Authenticator implementation. You can
plugin 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 a value in the XML
file. The identify phase simply uses the user id to populate a new
UddiEntityPublisher
.
LdapSimpleAuthenticator
provides a way of authenticating
users using Ldap simple authentication. It is fairly rudimentary and more
LDAP integration is planned in the future, but this class allows you to authenticate
a user based on an LDAP prinicipal, provided that the principal and the juddi publisher ID
are the same.
To use this class you must add the following properties to the
juddi.properties
file:
juddi.auth=org.apache.juddi.auth.LdapSimpleAuthenticator juddi.auth.url=ldap://localhost:389
The juddi.auth.url
property configures the
LdapSimpleAuthenticator
class so that it knows where the LDAP
server resides. Future work is planned in this area to use the LDAP uid rather than
the LDAP principal as the default publisher id.
Finally is it possible to hook up to third party credential stores. If for example
jUDDI is deployed to the JBoss Application server it is possible to hook up to
it's authentication machinery. The JBossAuthenticator
class
is provided in the docs/examples/auth
directory. This class
enables jUDDI deployments on JBoss use a server security domain to authenticate
users.
To use this class you must add the following properties to the
juddi.properties
file:
juddi.auth=org.apache.juddi.auth.JBossAuthenticator juddi.securityDomain=java:/jaas/other
The juddi.auth property plugs the
JbossAuthenticator
class into the jUDDI the Authenticator
framework. The juddi.sercuity.domain
, configures the
JBossAuthenticator
class where it can lookup the
application server's security domain, which it will use to perform the
authentication. Note that JBoss creates one security domain for each application
policy element on the
$JBOSS_HOME/server/default/conf/login-config.xml
file, which
gets bound to the server JNDI tree with name
java:/jaas/<application-policy-name>
. If a lookup refers to a
non existent application policy it defaults to a policy named other.