Wednesday, October 31, 2007

Updating Skype with yum - updated repository location

pencil icon, that"s clickable to start editing the post

Since I installed Skype (see Going Skype on Fedora Core Level 6) it's been working, but sometime between then and now updating with yum started giving me errors like: [Errno 14] HTTP Error 404: Server: nginx/0.5.14
Date: Wed, 31 Oct 2007 18:53:37 GMT
Content-Type: text/html
Content-Length: 1292
Connection: keep-alive

Trying other mirror.
Error: Cannot open/read repomd.xml file for repository: skype

For some time I thought that it was just an intermittent problem, then I keept ignoring it running like yum --disablerepo=skype update. Today I decided it was to silly and also that I was still running skype- A seach lead me to a post by DerKaiserInKanada, not that he had a problem but I discovered that he was using another repository location (read baseurl):

#cat /etc/yum.repos.d/skype.repo

name=Skype Repository

Then i ran a normal yum update and vupti no problem and an upgrade to Why did I wait that long :-)

Read more

Tuesday, October 30, 2007

Updating with yum - strange warnings about useradd

pencil icon, that"s clickable to start editing the post
  Updating  : monotone                     ######################### [1/4]
Usage: useradd [options] LOGIN

  -b, --base-dir BASE_DIR       base directory for the new user account
                                home directory
  -c, --comment COMMENT         set the GECOS field for the new user account
  -d, --home-dir HOME_DIR       home directory for the new user account
  -D, --defaults                print or save modified default useradd
  -e, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -f, --inactive INACTIVE       set password inactive after expiration
                                to INACTIVE
  -g, --gid GROUP               force use GROUP for the new user account
  -G, --groups GROUPS           list of supplementary groups for the new
                                user account
  -h, --help                    display this help message and exit
  -k, --skel SKEL_DIR           specify an alternative skel directory
  -K, --key KEY=VALUE           overrides /etc/login.defs defaults
  -m, --create-home             create home directory for the new user
  -l,                       do not add user to lastlog database file
  -M,                       do not create user's home directory(overrides /etc/login.defs)
  -r,                       create system account
  -o, --non-unique              allow create user with duplicate
                                (non-unique) UID
  -p, --password PASSWORD       use encrypted password for the new user
  -s, --shell SHELL             the login shell for the new user account
  -u, --uid UID                 force use the UID for the new user account

  Updating  : monotone-server              ########################  [2/4]warning: user monotone does not exist - using root
  Updating  : monotone-server              ########################  [2/4]warning: user monotone does not exist - using root

Keeping my Fedora system updated is easy enough with yum, but lately I've noticed a couple of similar warnings, like this one above.

The messages warning: user monotone does not exist - using root does leave me a little puzzled, since it's a warning it shouldn't be a problem but since a user account is missing will it run correctly, does it use another account, is it just a bad RPM build/configuration or the worst possiblity something/someone has silently messed up my system!.

I've search for an answer on the web, but didn't really find one. Most posts were related to people trying to run src.rpm's or specific packages (where I think the problem is a bit more general). Anyway I've removed Monotone since I don't need it (I didn't even know that it existed). Leaving me with the ol' question of how to keep my system at the minimal without using endless time using yum and understanding what the different packages do , being just an average Fedora user I'm relaying primarily on default configurations

Read more

Thursday, October 25, 2007

Blogger editor - annoyances with adding images

pencil icon, that"s clickable to start editing the post

A minor annoyance to me that the blogger editor adds images with invalid XHTML. I'm using 'Editor HTML' mode, and every image I add gives me three things to correct:

  • the attribute border is added with the value 0. It has been deprecated in strict (X)HTML
  • the attributes alt and id are for some reason concatenated
  • the XHTML fragment is added to the top of the posting, not where I was when I pressed the 'add image' button

It looks like this:

<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"
   <img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer;cursor:hand;"

I have survived until now and will keep doing that, it's just that it irritates my DRY instinct.

Read more

REST API (GET) for UDDI entities - does anyone implement it?

pencil icon, that"s clickable to start editing the post

The webservice API for UDDI isn't pure SOAP, there's also a little REST part, though calling it an API for itself would be an exaggeration since it only enables aminor part of the SOAP API, that for retrieving the basic entities. It's and optional feature (may but for some reason not with capital letters) and described in Section 6.5 HTTP GET Services for UDDI Data Structures :

A node may offer an HTTP GET service for access to the XML representations of UDDI data structures. If a node offers this service, the URLs should be in a format that is predictable and uses the entity key as a URL parameter.

The RECOMMENDED syntax for the URLs for such a service is as follows:

If a UDDI node’s base URI is, then the URI<entity>Key=uddiKey would retrieve the XML for the data structure whose type is <entity> and whose key is uddiKey. For example, the XML representation of a tModel whose key is "" can be retrieved by using the URL

In the case of businessEntities, the node MAY add these URIs to the businessEntity’s discoveryURLs structure, though this is NOT RECOMMENDED behavior as it complicates the use of digital signatures.

First example - Global Biodiversity Information Facility UDDI Registry

An example of a registry supporting the HTTP GET Services is theGlobal Biodiversity Information Facility UDDI Registry. The documentation contains a very nice presentation of the UDDI data structures in XML Schema in a fashion very like JavaDoc. On the frontpage the product and version number is given "GBIF UDDI is powered by Systinet (c) WASP 4.6 UDDI engine" - doing a HTTP GET returns the following headers:

wget --no-check-certificate -S
Connecting to||:443... connected.
WARNING: cannot verify's certificate, issued by
  `/C=DK/ST=Copenhagen/L=Copenhagen/O=GBIF Secretariat/OU=ICT/':
  Self-signed certificate encountered.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Tue, 23 Oct 2007 20:10:38 GMT
  Server: Systinet WASP Server for Java/4.6.1 (Java/1.4.1_03; Linux/2.4.21-52.ELsmp)
  Content-type: text/html; charset=UTF-8
  Connection: close
Length: unspecified [text/html]

That confirms this. Not exactly the newest versions, Linux 2.4 kernel, Java 1.4 and WASP server that seems to have run though two major releases in the meantime. I also find that it's run from Copenhagen.

Doing a browse search and choosing 'Australian National Insect Collection, CSIRO Entomology' gives:

Australian National Insect Collection, CSIRO Entomology, Business entity, web presentation

Activating The View as XML button, implemented as:

<input value="View as XML" 

using a simple JavaScript function defined in

function displayXMLDirect(paramName, paramValue, authinfo) {    
    window.location = "?"+paramName+"="+paramValue+"&authInfo="+authinfo;    

For my own preference I would have skipped the JavaScript and just made the link (HTTP GET) directly - simpler and more accessible. Any way the raw XML describing the Business Entity Australian National Insect Collection, CSIRO Entomology

<?xml version="1.0" encoding="UTF-8"?>
<businessEntity authorizedName="provider"
  businessKey="06bbd2a0-671b-11d8-b9b2-b8a03c50a862" operator="GBIFS">
    <discoveryURL useType="businessEntity"></discoveryURL>
  <name xml:lang="en">Australian National Insect Collection, CSIRO Entomology</name>
  <description xml:lang="en"></description>

Obviously there's either a configuration error or some redirecting going on since I can't access discoveryURL running on port 8009. A similar problem can be found in the old OIO UDDI based on another product so this is obviously a general problem.

Second example - OIO e-Business Registry

Abother UDDI is the OIO e-Business Registry, that can be accessed as Oracle Application Server Service Registry (don't use the Business Control Center that is another interface to the same data, though I haven't figured out the real diffenrence). Choosing 'Search' gives the simple search page:

Doing a wildcard/browse search and choosing KMD Gateway SKI 0.7 - 04:

But I can't call this as raw XML with the HTTP GET as described in the UDDI version 3 specification:

gives an error page similar to this:

But through the button on the page, that's a link enabled image:

<a href="javascript:submitToURL('form','/directGetXml','root##465195',-1,false,'');;void(0);" .....</a>

this is worse than the older version, since is all JavaScript but based on href and not onClick. The JavaScript function is defined in wf.js (port 12443):

// submits page to url
function submitToURL (formName, targetTask, actionID, targetDepth, redirect, targetURL)
  document.forms[formName].action = targetURL;
  submitPage(formName, targetTask, actionID, targetDepth, redirect);

// submits page
function submitPage (formName, targetTask, actionID, targetDepth, redirect)
  if (checkFields(formName,actionID)) {
    document.forms[formName].elements['actionId'].value = actionID;
    document.forms[formName].elements['targetTask'].value = targetTask;
    document.forms[formName].elements['targetDepth'].value = targetDepth;
    document.forms[formName].elements['redirect'].value = redirect;

which relates to this form:

<form name="form" method="POST" >
<input type="hidden" name="actionId"/>
<input type="hidden" name="targetTask"/>
<input type="hidden" name="targetDepth"/>
<input type="hidden" name="redirect"/>

The values were:

  • formName='form'
  • targetTask='/directGetXml'
  • actionID='root##465195'
  • targetDepth=-1
  • redirect=false
  • targetURL=''

So it can be POST'ed and that might not be true REST or according to what the specification suggests, but it can done by ex. curl or a simple form on another web page. I haven't tried to access it with GET, but it might work.

Does anyone implement it?

In fact it would be more interesting to know whether anyone uses it, but the two examples I've looked at here does both implement it (both systinet products), in diffent ways, I haven't used UDDI for a real business case or development so I can't way whether is a great feature or just a possible feature.

Read more

Tuesday, October 23, 2007

One of the reasons why I'll stop running websites myself

pencil icon, that"s clickable to start editing the post

In my spare time I help running the website for a non-profit organization. It runs on Drupal, a choice I don't have any regrets about, since it was easy to get running, configuring and using. In the meantime I've begun using blogger, which has many of the same basic features (we don't have any fancy stuff on the website). The advantage on using blogger is that i don't have to maintain it and the performance is in general okay. The current hosting is very cheap, but with corresponding service levels :-).

The website has been running stable for a long time and I've only done a couple of updates since very few modules is in use. I've also assisted in adding news to the site, which has been quite easy as well, but about a fourth night ago I encountered a strange problem. I logged in as webmaster and when I choose the page I wanted to edit my login was gone! I checked my cookie settings, but found nothing. I decided to wait for some time, since it could some intermittent problem during update or some thing like that. Tonight someone asked for the update again and I realized that the problem was still there. After doing some searches and refining my query I found the answer in Drupal's Troubleshooting FAQ. The entry Login problems on PHP 5.2 had the precise same diagnostics that I was experiencing, and the HTTP headers from a get confirmed the version of PHP:

HTTP/1.1 200 OK
Date: Tue, 23 Oct 2007 18:01:58 GMT
Server: Apache/2.0.55 (FreeBSD) PHP/5.2.4 with Suhosin-Patch
X-Powered-By: PHP/5.2.4

I have no idea when they upgraded (or from what) and didn't expect it (do we ever?). Now it's time to decided whether to do the upgrade (now how was that done) or swapping over to blogger. I'm not sure what the easiest for me, but I do think swapping will take a little more but should earn it self in the long run, making it easier to let someone other take over for one.

Currently I think the biggest problem is creating and not the least maintaining the menu (currently javascript based). Another thing is the layout which is Antique Modern where I've found a port for the old blogger, that maybe could be converted. The layout isn't really important, so I don't think anyone would complain as long as it simple. Uhmm, I'll sleep on it and post when I've decided.

Update (27. Dec. 2007): by manually appliying the patch from Session handler executed after $user object is destructed - that is adding the line register_shutdown_function('session_write_close'); after the declaration of global variable in function sess_read($key) (from file includes/ I got it working again. I didn't figure out why some had success applying that patch the normal way since that was rejected for me.

Read more

Sunday, October 21, 2007

Searching UDDI version 3 with the browse pattern - wildcards and findQualifiers

pencil icon, that"s clickable to start editing the post

It's been some since I last looked at UDDI, but the availability of the new OIO e-Business registry has awaken my interest once again. The old OIO UDDI supported only version 2 (see for example my post Using the ISB UDDI #1), whereas the new one supports UDDI version 3. In this post I'll walk through how to do a simple search for all tModels in a version 3 registry by using the web service API that comes with UDDI.

The WSDL for the Inquiry API

The new registry does have a correct Inquire WSDL that supports no less than the ws API's for all three version:

    1 <?xml version="1.0" encoding="UTF-8"?>
    2 <definitions name="UDDI_API_V3"
    3              targetNamespace="urn:uddi-org:api_v3generated/"
    4              xmlns:tns="urn:uddi-org:api_v3generated/"
    5              xmlns="">
    7   <import namespace="urn:uddi-org:api_v2"
    8           location="" />
   10   <import namespace="urn:uddi-org:api_v3"
   11           location="" />
   13   <import namespace="urn:uddi-org:inquiry"
   14           location="" />
   16 </definitions>

I have no idea about challenges with backwards compatibility, but it is covered by the specification. The only confusion here is that we're doing inquiry and an endpoint with the host name on but I guess the meaning like it's the production site, where it's public available and as such published. The WSDL for the inquiry API in version 3:

    1 <?xml version="1.0" encoding="UTF-8"?>
    2 <definitions name="UDDI_API_V3"
    3              targetNamespace="urn:uddi-org:api_v3"
    4              xmlns:tns="urn:uddi-org:api_v3"
    5              xmlns:api_v3_binding="urn:uddi-org:api_v3_binding"
    6              xmlns:soap=""
    7              xmlns="">
    9   <documentation xmlns:soap=""
   10                  xmlns:api_v3_binding="urn:uddi-org:api_v3_binding"
   11                  xmlns:tns="urn:uddi-org:api_v3">
   12     Copyright 2001-2005 Systinet Corp. All rights reserved. Use is subject to license terms.
   14     WSDL SOAP/HTTP binding for UDDI V3 Security, Publication and Inquiry APIs.
   15   </documentation>
   17   <import namespace="urn:uddi-org:api_v3_binding" location="uddi_api_v3_binding.wsdl" />
   19   <service name="UDDI_Inquiry_SoapService">
   20     <port name="UDDI_Inquiry_PortType" binding="api_v3_binding:UDDI_Inquiry_SoapBinding">
   21       <soap:address location="" />
   22     </port>
   23   </service>
   25   <service name="UDDI_Publication_SoapService">
   26     <port name="UDDI_Publication_PortType" binding="api_v3_binding:UDDI_Publication_SoapBinding">
   27       <soap:address location="urn:unknown-location-uri" />
   28     </port>
   29   </service>
   31   <service name="UDDI_Security_SoapService">
   32     <port name="UDDI_Security_PortType" binding="api_v3_binding:UDDI_Security_SoapBinding">
   33       <soap:address location="urn:unknown-location-uri" />
   34     </port>
   35   </service>
   37 </definitions>

The endpoint is given, and I'm ready to next step.

Not that it's significant, but it's a little confusing that the Security and Publish is also mentioned here (under 'Inquiry'), though without specific endpoints.

Coding the ws client with Axis2

Want to search the UDDI by programming? No problem, take the WSDL and run it through your favorite WS-tool, create your search Class and you're done ready to do the search. That was what I did with the Axis2 nightly, and with my preferred binding XmlBeans - well done Axis2 committers!

I could probably have used the Systinet Oracle Java API for the registry, but I don't see much use for it - yes there could be nice utility methods etc. but I don't need them.

The first quick search - uhmm, is it really empty?

Based on my earlier experience with the version 2 Inquiry programmers API, I knew that '%' is used as wildcard, so I decided to do a search on all tModels. In the UDDI version 3 specification this is called the browse pattern which is spot on:

Software that allows people to explore and examine large quantities of data requires browse capabilities. The browse pattern characteristically involves starting with some broad information, performing a search, finding general result sets and then selecting more specific information for drill-down.

The request went like:

    1 <?xml version='1.0' encoding='UTF-8'?>
    2 <soapenv:Envelope xmlns:soapenv="">
    3   <soapenv:Body>
    4     <urn:find_tModel xmlns:urn="urn:uddi-org:api_v3">
    5       <urn:name>%</urn:name>
    6     </urn:find_tModel>
    7   </soapenv:Body>
    8 </soapenv:Envelope>

And the response:

    1 <?xml version="1.0" encoding="UTF-8"?>
    2 <Envelope xmlns="">
    3   <Body>
    4     <tModelList xmlns="urn:uddi-org:api_v3">
    5       <listDescription>
    6         <includeCount>0</includeCount>
    7         <actualCount>0</actualCount>
    8         <listHead>1</listHead>
    9       </listDescription>
   10     </tModelList>
   11   </Body>
   12 </Envelope>

Uhmmm, this couldn't be true, so either I was doing something wrong or there would have to be some policy hiding all results for me - it naturally was the former. As described in the next section, in version 3 I have to add a specific FindQualifier in the request:

    1 <?xml version='1.0' encoding='UTF-8'?>
    2 <soapenv:Envelope xmlns:soapenv="">
    3   <soapenv:Body>
    4     <urn:find_tModel xmlns:urn="urn:uddi-org:api_v3">
    5       <urn:findQualifiers>
    6         <urn:findQualifier></urn:findQualifier>
    7       </urn:findQualifiers>
    8       <urn:name>%</urn:name>
    9     </urn:find_tModel>
   10   </soapenv:Body>
   11 </soapenv:Envelope>

And now i get results, a lot in fact (1,4 MB/27729 lines of pretty print XML), as this snippet shows:

    1 <?xml version="1.0" encoding="utf-8"?>
    2 <tModelList xmlns="urn:uddi-org:api_v3">
    3   <listDescription>
    4     <includeCount>6929</includeCount>
    5     <actualCount>6929</actualCount>
    6     <listHead>1</listHead>
    7   </listDescription>
    8   <tModelInfos>
    9     <tModelInfo tModelKey="">
   10       <name>AccountApi</name>
   11       <description xml:lang="en">This portType defines all operations with the accounts.</description>
   12     </tModelInfo>
   13     <tModelInfo tModelKey="">
   14       <name>Account_SoapBinding</name>
   15       <description xml:lang="en">This is the SOAP binding for the Account portType.</description>
   16     </tModelInfo>
   17     <tModelInfo tModelKey="">
   18       <name>administrationUtilsApi</name>
   19       <description xml:lang="en">This portType defines all operations with the administrationUtils.</description>
   20     </tModelInfo>
   21     <tModelInfo tModelKey="">
   22       <name>administrationUtils_SoapBinding</name>
   23       <description xml:lang="en">This is the SOAP binding for the administrationUtils portType.</description>
   24     </tModelInfo>
   25     <tModelInfo tModelKey="uddi:42f92342-c3ed-46ff-8a8a-6518f55d5cd5">
   26       <name>Application response service</name>
   27       <description xml:lang="en">NIST definition of the service interface for handling UBL application response messages.</description>
   28     </tModelInfo>

The header information (in bold) listDescription so there are 6929 tModels in the registry currently.

A deeper look at Find Qualifiers

In section 5.1.4 Find Qualifiers the second row in the table Find Qualifiers by API defines "approximateMatch" with the uuid uddi-org:approximateMatch:SQL99, the introduction says:

Each of the find_xx APIs accepts an optional findQualifiers argument, which may contain multiple findQualifier values. Find qualifiers may be either tModelKeys or may be referenced by a string containing a "short name". Each of the pre-defined findQualifiers in UDDI can be referenced using either the appropriate tModelKey, or by its short name. Registries MUST support both forms, and MUST accept the find qualifiers case-insensitively. The use of tModelKeys for findQualifiers allows extension to create additional new qualifiers, but registries are not obligated to support them. Find qualifiers not recognized by a node will return the error E_unsupported.

Matching behavior for the find_xx APIs when multiple criteria are specified is logical "AND" by default. Find qualifiers allow the default search behaviors to be overridden. Not all find_xx APIs support all findQualifier element values.

later in Find Qualifier Descriptions:

signifies that wildcard search behavior is desired. This behavior is defined by the uddi-org:approximatematch:SQL99 tModel and means "approximate matching as defined for the character like predicate in ISO/IEC9075-2:1999(E) Section 8.5 like predicate, where the percent sign (%) indicates any number of characters and an underscore (_) indicates any single character. The backslash character (\) is used as an escape character for the percent sign, underscore and backslash characters. This find qualifier adjusts the matching behavior for name, keyValue and keyName (where applicable).

Let's just take the special characters from the last part again:

percent sign '%'
indicates any number of characters
an underscore '_'
indicates any single character.
The backslash character '\'
is used as an escape character for the percent sign, underscore and backslash characters.

This find qualifier adjusts the matching behavior for name, keyValue and keyName (where applicable).

There's more detail in section 5.1.6 About wildcards, where I've put the most important parts in bold:

The default behavior of UDDI with respect to matching is "exact match". No wildcard behavior is assumed. Many UDDI inquiry APIs take the arguments "name," "keyName," and "keyValue" whose values are of type string. All such arguments may be specified using a wildcard character to obtain an "approximate match". In order to obtain wildcard searching behavior, the findQualifier tModel uddi-org:approximateMatch:SQL99 (whose tModelKey is, or its short name "approximateMatch" MUST be specified.

Wildcards, when they are allowed, may occur at any position in the string of characters that constitutes the argument value and may occur more than once. Wildcards are denoted with a percent sign (%) to indicate any value for any number of characters and an underscore (_) to indicate any value for a single character. The backslash character (\) is used as an escape character for the percent sign, underscore and backslash characters. Use of the "exactMatch" findQualifier will cause wildcard characters to be interpreted literally, and as such should not also be combined with the escape character. Detailed rules for interpretation are defined by the above tModel for approximate matching. Examples of the use of wildcards may be found in Appendix G Wildcards.

I havn't figured out if this is really smart or relly technical, since this isn't SQL and it sort of breaks with how it worked in version 2, also why the need to interpret them literally when there's a simple way to escape them? It works and now I know, so it's just my personal opinion.

Read more

Friday, October 19, 2007

A minimal P3P Compact policy - a suggestion by Microsoft

pencil icon, that"s clickable to start editing the post

Back in July I had a look at P3P compact policy, and in the post An analysis of a P3P compact policy example I resolved the example NOI DSP COR NID PSAo OUR IND. The other day I by coincidence came by an entry in the Microsoft Knowledge base Session variables are lost if you use FRAMESET in Internet Explorer 6 [HTML] (In danish: Sessionsvariabler går tabt ved brug af FRAMESET i Internet Explorer 6). This article suggest the minimal policy CAO PSA OUR to declare that no malicious actions are performed with the data of the user..

Doing a further search I found quite many articles and postings with plenty of positive comments that left me with the feeling that this is used as a technical fix to overcome problems with ex. using third-party content in Iframes. It's not that I think IE6+ is done right and FF 2.0 is done wrong, but that using the P3P compact policy without understanding the semantics, for sure wasn't what Microsoft had in mind when they choose to implement IE 6+ to demand P3P Compact policies (for third parties) and for certain not what the P3P working group had in mind!.

To turn around the problem I'll make my guess at what the policy CAO PSA OUR means and thereby give myself and other web administrators the possibility to check whether that fits our websites.

CAO (<contact-and-other/>)
Identified Contact Information and Other Identified Data: access is given to identified online and physical contact information as well as to certain other identified data.
PSA (<pseudo-analysis/>)
Pseudonymous Analysis: Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals for purpose of research, analysis and reporting, but it will not be used to attempt to identify specific individuals. For example, a marketer may wish to understand the interests of visitors to different portions of a Web site.
OUR (<ours/>)
Ourselves and/or entities acting as our agents or entities for whom we are acting as an agent: An agent in this instance is defined as a third party that processes data only on behalf of the service provider for the completion of the stated purposes. (e.g., the service provider and its printing bureau which prints address labels and does nothing further with the information.)

My best shot at the meaning of this is:

My website do collect some PII for my own use, your can probably check for yourself online what's stored about you. My website may use profiling mapped by pseudonymous identifier.

An 2002 posting on Oreillynet P3P in IE6 : Frustrating Failure has a comment with an even more minimal policy and also a comment from one of the authors of the P3P specification.

Read more

Thursday, October 18, 2007

What a difference a </q> makes ....

pencil icon, that"s clickable to start editing the post

After I made my last post yesterday evening I was chocked to see my blog totally loose layout. Rather desperate I tried other browsers and computers, and isolated the problem to Firefox browsers. After cooling down i finally realized what was wrong - I was missing a closed </q> element, fheewww. Here's how it looked before I fixed it:

It's surprising how f'ed up it is, with all those xtra ".

Read more

Wednesday, October 17, 2007

The keys to UDDI - from nonsense Hex-digits to meaningfull URIs

pencil icon, that"s clickable to start editing the post

UDDI version 3 is new to me even though it's not a new standard. A classic approach to new versions is to look for the what's new section. The specification doesn't give that (UDDI Version 3.0.2). A quick search lead me to PerfectXML's The Evolution of UDDI. Looking at the date's on history table I was surprised to see that it's in fact more than five years old. A couple of minor revisions lead me to believe i wasn't that old, but it is from the summer of 2002:

Update!: Today I found the announcement "UDDI Version 3.0 Beomes an OASIS Standard" dated February 03, 2005! It would had been nice with a formal version, with the label standard and the correct date, and I can't remember any other OASIS Standard without such an officially labeled specification. I conclude that it took approximately 2.5 years and 2 minor revisions for version 3 to become an real standard.

Version Date for Committee draft
3.0.2 19 October 2004
3.0.1 14 October 2003
3.0 19 July 2002


One of the central new things are the keys used in UDDI, which has always be central but with the shift of focus to federation, this is even more important. The article gives a short description in "Creating and Managing Registration Keys". But first a look at how it was defined in version 2.

UDDI Keys in version 2

In UDDI version 2 section "4 API Reference" the keys are described:

Access keys within all UDDI defined data elements are represented as universal unique identifiers (these are sometimes called a GUID). The name of the element or attribute designates the particular key type that is required. These keys are always formatted according to an algorithm that is agreed upon by the UDDI Operator Council with the one exception being tModelKey values, which are prefixed with a URN qualifier in the format "uuid:" followed by the UUID value.

and further down under tModelBag All tModelKey values are always expressed using a Uniform Resource Identifier (URI) format that starts with the characters "uuid:" followed by a formatted Universally Unique Identifier (UUID) consisting of Hexadecimal digits arranged in the common 8-4-4-4-12 format pattern.

According to Richard Monson-Haefel's book J2EE Web Services in section "6.5 UUID Keys": The UUID is a hexadecimal-encoded number taht is about 30 charaters long and is generated using the DCE UUID-generation algorithm.

UDDI Keys in version 3

In version 3, the section "4.4 About uddiKeys" gives the change:

..All UDDI keys are URIs that conform to RFC 2396 but not all URIs are valid UDDI keys. The URIs that are valid as UDDI keys correspond to a subset of the opaque part alternative of the absoluteURI rule in RFC 2396. Further, registries MUST use keys from the scheme "uddi" following the syntactic and semantic rules for that scheme as given in this section,..

and "9.4.2 Registry General Keying Policy":

UDDI Version 3 introduces the ability for publishers to generate entity keys. This feature preserves the requirement for distinct keys while enabling keys to be created in a safe, efficient manner.

A registry MUST have a policy on key format and key generation. The registry MUST have a policy on data integrity or how the keyspace is protected from unauthorized modification.

Registries MAY use whatever keying policies they wish subject only to the constraints that keys MUST be URIs, and the registry MUST have policies that prevent key collisions.

Update: Today I found the UDDI Version 3 Features List where "2.2 Human-friendly, URI-based keys":

Alongside the ability to promote keys across registries is a new format for UDDI keys. Prior versions of UDDI mandated that keys had to be a formatted Universally Unique Identifier (UUID). Version 3 removes this restriction and recommends the usage of a key scheme based on DNS names. This allows publishers to establish a key partition from a DNS record and then generate keys based on that partition. For example, a valid Version 3 key might look as follows:


These human-friendly keys allow organizations to manage their own key space using internally established conventions and structures.

So now all keys in UDDI are URI's and the publisher can suggest them. I haven't really used UDDI so I can't tell any story from the trenches about the problems with opaque keys, but sometimes it's sure nice to make some meaning out of them, Though it's also some times seen as best practice not to put any meaning into keys since things have a tendency to change.

Read more

Sunday, October 14, 2007

OIO e-Business Registry - choice of product and main use case

pencil icon, that"s clickable to start editing the post

The OIO e-Business Registry looks like the new registry for OIO, though the focus right now is just on e-Business. The original OIO registry (UDDI) is part of the InfoStructureBase (ISB), based on a Microsoft implementation. I'm not really sure if Microsoft has officially abandoned further development, but it currently only support version 1 and 2 (see the Windows 2003 Server UDDI FAQ).

The chosen product

Following the URL to the registry website you're met by the Oracle Application Server Service Registry Business Service Control - I haven't figured out what that loooong title really means, especially the final Business Service part puzzles me. In fact it's the Systinet Registry (Supporting UDDI version 3) that Oracle has teamed up with. I didn't know, but found an article about it on techtarget from 2005 Oracle-Systinet deal a win-win:

Oracle Corp. and Systinet Corp. have entered into a strategic three-year agreement in which Oracle will embed Systinet's registry with the recently unveiled Oracle Application Server 10g Release 3, a component of Oracle Fusion Middleware.

So Oracle has realized that developing they're own registry wasn't worth it - and they are not alone with that analysis. It turns out that BEA has done something similar, as can be read in an zdnet blog post Connecting the SOA dots with UDDI:

When BEA’s "AquaLogic" hits the market, one of its most interesting features will be a service registry that employs the Universal Description, Discovery and Integration (UDDI) standard. (Details on the service registry can be found here.) BEA announced it will be reselling the Systinet Registry as this component of AquaLogic.

On the Systinet website there's an overview of the registry [HTML] and the Systinet Registry Datasheet.

The main use case

I won't go into why the choose UDDI, but instead have a quick look at how it's used in connection with OIOSI. On the overview page for OIO Service Oriented Infrastructure (english version) the document: The Architecture of the Danish OIO Service Oriented Infrastructure [PDF] (Draft version 0.8, For public review) can be found. Main section 6 Service registry describes how the UDDI fits in, and section 6.2 Functionality lists the functionality (read use cases):

  • Registration

    Businesses or public authorities must register their web services with the service registry in order for others to find and use the service to send a business message. All registrations are done to the master UDDI and the registered information is copied to the replicas afterwards by the replication procedure. Registration can be done through a Web interface or by calling UDDI web services.

  • Activation

    It is necessary to make sure that interfaces defined by a client are correct after a registration. Therefore a number of test requests are initiated from the national master UDDI. The test requests use dummy data and test certificates. The responses are verified by the master UDDI....After the tests have been carried out successfully, the web service entry will be active in the UDDI, enabling lookups of the particular web service.

  • Endpoint lookup

    An organization needs the endpoint of another organizations web service in order to send a business message to that organization. The purpose of the lookup mechanism is to provide this endpoint, based on the information of the business.

    EAN location numbers2 and CVR numbers are used to identify organizations and based on one of these numbers, it is possible to lookup web services from the specific organization through the UDDI replicas.

With the last one being essential, that's heavy in terms of usage/volume, and the former two supporting this one. This is one of the classic UDDI use cases, though I'll gladly admit that I wasn't expecting to see this already considering dynamic lookup for a business process directly related to money and bank accounts, will need some founding business agreements and readiness in terms of both raw technology and willingness from the business perspective. In OIO e-business profile version 0.8 it's show in an activity diagram:

Read more

OIO e-Business - "there's a new Registry in town"

pencil icon, that"s clickable to start editing the post

The OIO e-Business framework has a as one of it's centrale components a UDDI registry. For a little background information visit OIO Service Oriented Infrastructure - Exchange of business messages over the Internet. At this year JAOO, Mikkel Hippe Brun gave the presentation Using the public Danish SOA Infrastructure. update: the presentation is available online on infoq. The slides specific to the use of UDDI registry I've included here:

four slides from presentation describing the usage of registry

The infrastructure has a central master registry (based on a commercial product) and decentral registries with a combination of local information and replicated data from the master registries. To lower the barriers for deployments (both technical and economical I guess) they've had an open source implementation (Apache License 2.0 license) developed of an UDDI registry version 3 (OASIS standard since February 2005). An overview of the architecture can be seen here:

Read more

Saturday, October 13, 2007

Local logout in federation - confirmed standpoint

pencil icon, that"s clickable to start editing the post

After my last post Local logout in federation - a good choice for mandatory feature to E-Authentication? I wondered whether others had written about local logout. I found a paper from XML Conference 2005: Case Study: Use of Liberty Federated Network Identity in an Enterprise Outsourcing Environment [PDF], presented by Yvonne Wilson, Sun IT Strategy & Architecture (The slides from the presentation [PDF]). In section 9.6. Logout [HTML] (my bold):

In a federated network identity environment with single signon, two logout options are possible. A service provider may provide a 'local' logout link, which terminates the user's session in the service provider's infrastructure only. Alternatively, the service provider and/or the identity provider can provide a 'global' logout link, which terminates the user's session in the identity provider's infrastructure as well. Use of local logout may be confusing to users because their identity provider session remains intact, allowing them to access without login an application from which they just logged out. Providing both a local logout and a global logout link may be confusing to users who don't understand the difference between them. Therefore, it is recommended to use only a global logout link.

A agree and can't figure out why it ended up in even the second version of E-Authentication, but maybe I'll discover some day.

Read more

Thursday, October 11, 2007

Local logout in federation - a good choice for mandatory feature to E-Authentication?

pencil icon, that"s clickable to start editing the post

Normally access protected websites offer a login and a logout. In federation scenarios the login is replaced with a Single Sign-On (SSO) that can be terminated by a Single Log-Out (SLO). The same Identity Provider may still offer the possibility to just login to one Service Provider if the user doesn't wish to enter Single Sign-On. This is in principle like the former (a website), but with distributed functionality. I've heard people that confused the Single Sign-On with just logging into a single Service Provider. Therefore when in doubt I use the terms Global for the federation and Local for the single Service Provider. E-authentication has another variant that they call simple logout, which I would call local logout. It's not clear what value it adds, but before further analyzing this I'll have a look at what the SAML specifications and E-Authentication says about it, starting with the definition of logout from the SAML Glossary:

Logout, Logoff, Sign-Off
The process whereby a user signifies desire to terminate a simple session or rich session.

The glossary doesn't say what's meant by a rich session. This is not important here though it would be interesting to know what they have in mind.

In the SAML V2.0 specifications, that's in SAMLProfiles section "4.4 Single Logout Profile" the single logout profile is described (basically the same content is in SAMLCore):

Once a principal has authenticated to an identity provider, the authenticating entity may establish a session with the principal (typically by means of a cookie, URL re-writing, or some other implementation specific means). The identity provider may subsequently issue assertions to service providers or other relying parties, based on this authentication event; a relying party may use this to establish its own session with the principal.

In such a situation, the identity provider can act as a session authority and the relying parties as session participants. At some later time, the principal may wish to terminate his or her session either with an individual session participant, or with all session participants in a given session managed by the session authority. The former case is considered out of scope of this specification. The latter case, however, may be satisfied using this profile of the SAML Single Logout protocol ([SAMLCore] Section 3.7).

In the E-Authentication Federation Architecture 2.0 Interface Specifications section "1.9 Single Logout Profile" it's mentioned:

The SLO protocol provides a means by which an authentication session and all associated RP sessions (i.e., initiated through that authentication session) can be terminated near-simultaneously.

  • The RP MUST offer the end user a choice between simple logout (logging out only from the RP) and SLO.
  • If the end user logs out while at a CS resource, the CS MUST terminate the end user’s authentication session and MUST initiate SLO (i.e., terminate all RP sessions associated with that authentication session).
    • Before proceeding, the CS MUST inform the end user that he or she will be logged out of all active RP sessions, and the end user MUST confirm the request.

Is essence the SAML V2.0 specifications doesn't say anything about local logout - it is out of scope, whereas E-Authentication demands that the user is given the option. There's no formal conflict in this since E-Authentication is based on SAML V2.0 but has a wider scope.

Value added with local logout

Without wondering off into the question about what logout really gives in it self, just taking for granted that doing a logout is the right way in terms of freeing up resources. Users seldom do this a then the timeout takes over. Further consideration about timeout/logout I'll save for a later post.

My spontaneous judgment is that is doesn't add any value at all or even worse might give the end user a faulty conception. I might be missing something, but my reasoning is that if the IdP-session (at the Session Authority) is still active there's nothing to hinder that the local session is reestablished (SSO doesn't care about whether your starting afresh or returning). The only thing that could change this would be if SP has implemented a policy that after a local logout, a new local session can't be started on the basis of the same global session (that's SAML V2.0 "SessionIndex"). Since there's no mention of such policy I guess it's not implemented. Taking it further would be to say that local logout doesn't make sense in a SAML V2.0 federation scenario, and as such there's a contradiction in using SAML V2.0 and also demanding a local logout.

Read more

Saturday, October 6, 2007

Five products approved for use by federal agencies in implementing E-Authentication

pencil icon, that"s clickable to start editing the post

EAuthentication has annonced that five SAML 2.0 products have successfully completed interoperability testing and are now approved for use by federal agencies in implementing E-Authentication.. The list can be seen under Approved Product Vendors [PDF]and to save you the lookup the lucky products are:

  • Entrust GetAccess v7.1
  • Hewlett-Packard OpenView Select Federation v6.6.2
  • BM Tivoli Federated Identity Manager v6.1.1
  • Ping Identity Corporation PingFederate v4.4
  • Sun Microsystems Access Manager 7.0 with SAML 2.0 Plugin

That's great for those vendors and the authorities on the lookout for a product with this kind of compliance, but what's in it and how do others come to the same lucky state?

The announcement gives the prerequisites:

GSA will accept applications from SAML 2.0 product vendors for interoperability testing based on the SAML 2.0 technical architecture and interface specifications. As a pre-requisite for such testing, GSA now requires that product vendors complete the Liberty Alliance SAML 2.0 v2.0 interoperability testing requirements for the Liberty Interoperable program. This requirement pertains to all product vendors interested in being listed on the E-Authentication Solution Approved Product Vendors list.

For products already listed on the Approved Product Vendors list, vendors will need to complete the Liberty Alliance SAML 2.0 Interoperability testing for any new version of the product, before it can be added to the Approved Product Vendor list.

The only question unanswered are the exercises that the product will have to perform to be interoperability testing. For Project Interoperable the test procedures (Liberty Interoperability Testing Procedures for SAML 2.0 v2.0 [PDF]) is public available but that doesn't seem to be the case for E-Authentication, though it would be interesting to see the difference and specifics of the these test procedures.

Read more