4.5 Security and integrity in relation to UDDI implementations

As with all things Web- related , post-9/11 security, as already discussed in the preceding sections, has hampered the spread of UDDI and the UBR. However, when it comes to UDDI and the UBR, one has to be very careful and judicious as to what one means by security ”and the scope of potential security exposures in this context. The first distinction that has to be made is between enterprise implementations and the UBR. Enterprise implementations, whether private or semiprivate, are meant to be closed user group affairs, which should only be accessible to authenticated and authorized users. The corporate phone book analogy has already been used.

In the case of private registries, system administrators should implement all appropriate access control mechanisms to ensure that only those with a need to know have the necessary rights to search, populate, or update the registry. This goes without saying. A private registry becomes just another sensitive corporate IT asset, and the type of corporation that would need a private registry will already have mature security policies about such IT assets. Obviously the one thing that you do not want is unauthorized users being able to snoop around or modify the contents of a private registry.

With semiprivate extranet registries, the issue of security becomes more difficult ”but not insurmountable. First, having an extranet registry that is shared among trusted partners does not preclude you from also maintaining an intranet-only private registry. Thus, you can have multiple levels of security and access controls. Within this structure, you would only publish select and carefully vetted information in the semiprivate registry.

Companies looking at semiprivate UDDI implementations are most likely to already have some level of experience when it comes to b2b e-business. There is a high possibility that they already operate a partners-specific extranet portal. As a result, such companies will already know how to share and at the same time restrict information between partners using authentication, personalization, and access controls. All of these will come into play when implementing a successful and secure extranet UDDI registry.

The security issues surrounding the UBR are, however, totally different. One can even plausibly argue that when it comes to the UBR, what is at stake is not so much security ”but integrity. What is important to remember here is that the UBR, by definition and intent, is meant to be a public repository. Hence, to read that the UBR node operators go to great lengths to encrypt the information maintained by a UBR node is incongruous. That is akin, if you think about it, to a public library having all of its books behind lock and key. The information published to the UBR is meant to be in the public domain.

What is key, however, is to maintain the integrity of the information in the UBR, and this is a challenge. Remember the bad old days when people poached domain names that should by rights belong to others? Well, a similar problem is still there with the UBR. As yet, there is no controlling authority that truly validates users who wish to publish new entries in the UBR. Consequently, an unscrupulous but resourceful joker could hijack the UBR entries for genuine businesses if those businesses have not already registered with the UBR. Thus, frivolous and inaccurate information is one of the big dangers facing the UBR and its users. To this end, recall that IBM lists 170 categories of services versus the one stated by Microsoft. Is one or both of these entries a joke? That is the problem. It is hard to tell.

Yes, the UBR nodes insist that you register with them before you can publish an entry. In the case of IBM, this involves selecting a previously unused user ID and an appropriate password and providing a set of contact information, with a valid e-mail address being sacrosanct. Your registration is only activated when you invoke a link to send to the e-mail address provided. This e-mail-based validation approach is not new and has been widely used in the last 5 years or so as a minimally acceptable, baseline method.

The rationale here is that the service provider (i.e., the UBR node operator) has at least an e-mail address that once worked and that points to the user trying to register. Suffice to say that this e-mail-based validation is really not worth the electrons used to execute it! A wily hacker will not have any problems opening numerous hard-to-track e-mail accounts. Microsoft insists that registration to use its UBR node has to be made via its now severely tarnished and undermined Passport service. This alone, as discussed in Chapter 3, may be enough to convince cynics that the integrity of the UBR is already compromised!

This is where digital certificates and digital signatures come in. UDDI V3 supports these mechanisms, but the exact use of these is left as policy decisions to the individual node operators. It now seems inevitable that down the road, all the UBR node operators will insist upon third-party certification, la digital certificates, in order for one to register as a bona fide UBR publisher. Until this happens, there will always be concerns about the integrity of the information available in the UBR.

Once an entry is published, only the user who published that entry can modify or delete it. This is good and reassuring, assuming that the original user who did the publishing was legitimate and was who he or she actually claimed to be. The original publisher, through the custody transfer API set, also has the ability to assign ownership to another registered user ”the key here, though, being that the original publisher has all the initial rights. This is why it is so imperative to ensure, via digital certificates, that the original publisher is not a charlatan. Once there is a validated publisher, a UBR node s policies could further dictate that it will only accept digitally signed entries from that user. With such policies one can put stock in the integrity of the information maintained in the UBR. During the transition to a digitally verified UBR structure, it will be possible, albeit with V3 implementations, for users to request that the searches they conduct on the UBR be restricted to those entries that have been digitally verified as to their authenticity.