XML - 2

I was meaning to write about some of the new openinfocard features this weekend, but instead I spent my time trying to get the openinfocard selector working against the Windows Live Beta site supporting Information Cards. I finally found the problem and really just could not believe it. A few months ago, I received a similar, yet unrelated, bug report against my own libraries. A person was using my wsse/xmlsec libs to communicate against a .NET SOAP service that required messages to be signed and told me that it would not work unless the XMLDSIG elements used a default namespace. This means that ... would work, while .. would not. Anyone who works with XML is fully aware that these two are exactly the same, so I just couldn't accept that. In fact, when mixing namespace (as often is the case when working with XMLDSIG and XMLENC) its easier to read the document when prefixes are used.

Within my libraries, I do prefix namespaces. Unfortunately for that person, I did not believe them and stressed that it had to be a coding error either on their part or from the service provider. Note that I didn't just dismiss their report. I was unable to reproduce the issue, was not given access to test against their service, do successfully interoperate with other .NET systems, and have a large number of users implementing my code against .NET services employing encryption and digital signatures. I hadn't heard anything more and ended up forgetting about it... that is until now.

Over the weekend, I spent a good amount of time comparing tokens from various selectors and trying different parameters. There were only two differences between tokens from Openinfocard and those from CardSpace. The first, which I spent most of my time on, was the timestamps. CardSpace provides a full hour for token validity. Openinfocard, on the other hand, allows the token 10 minutes of validity. I have run into a number of problems in the past due to the clock from either the client or server not being in synch. A fudge factor is usually built into the interactions (the client might set their NotBefore time to a few minutes prior to the current time, and the server might allow an extra ten minutes past the expire time), but I have seen cases, especially due to day light savings and systems not being updated, that the clocks between the client and server are too far off and the token is not considered valid when submitted. Anyways, this didn't end up being the problem.

Come to find out, the Windows Live Beta site has the exact same problem when dealing with the SAML token as the bug reported I told you about before. The issue is unrelated to the client code (so thankfully it wasn't an issue in my library - written in PHP); Openinfocard, which is the selector having a problem working with Windows Live, is in fact written in Java, and also prefixes namespaces. After altering the openinfocard code to use default namespaces, building new jars, installing the new jars and restarting firefox (sounds simple, yet REALLY time consuming), I finally got Windows Live to accept my Infocard. The underlying problem itself still eludes me. All I know is that the issue lies on the server side. I have no idea if this is a problem stemming from a particular version of the .NET libraries or if a third party library is being used.
Either way, I would have expected more from Microsoft. It's forgivable that a developer from a small company might use an outside library to work with digital signatures (that also happens to be buggy), but for a company that pushes the WS-* stack (XML Digital Signatures being a core component of WS-Security) and provides core libraries for working with it, this is a serious issue. It also seems to not be isolated either; as exemplified by the same issue against a .NET SOAP service.

Now hopefully someone can get me some answers to where this problem stems from so in the future I have a little more insight if I personally end up encounter it when dealing with a SOAP service; or at least can provide some help to someone reporting the issue to me again.

Life and work have been eating up all my time, so I have had no time to write anything about what's been going on. I finally decided to take a break from work, sit down and try to catch up with things.
Although busy, I have been updating my libraries; adding deatures, fixing bugs and trying to get some structure going. The libraries are used by a good number of projects, so I figured it was about time to make some of the changes known. First off, I started tracking versions and keeping changelogs for the different libraries (Only those that have changed since I started version tracking have changelogs right now). The libraries can all be found on my Source Code page. As for some of the specific changes....

Work has been keeping me extremely busy over the past few months, so I haven't had much time for any new entries. This, however, doesn't mean that there hasn't been anything going on. I figured it was about time I provided an update so people will quit asking if I'm still alive

XMLSec/WS-*:
Contrary to what I said in the past about no longer maintaining these libraries, I have been quietly releasing updated versions of the code with bug fixes. There are quite a number of people using them for various reasons so I have decided to continue supporting and developing all the libraries. There will be a few changes though. I have had far too many emails and questions concerning the lack of licensing (For some reason people don't get the public domain concept). To hopefully reduce the amount of questions I get about this, I will be releasing the next versions under a BSD license. I will also being maintaining versioning information for each file and the changes made between versions. The changes made so far have primarily been concerned with fixes when used through a SOAP server context, some ability to perform encryption in a SOAP message from the client side and some new features that I have needed for an Managed Identity provider (see the Infocard section for details).

Identity/OpenID/Infocard:

I finally managed to get my slides converted to PDFs (and a decent size). They can be found in the Talks section along with older ones. Yann and the rest of the crew did a great job (as usual) putting together the 2007 PHP Quebec conference. I had a great time in Montreal and my body is still getting over the sugar shock from consuming so much maple syrup on Saturday.

I've ran into services in the past that supported WS-Addressing, but it was only recently that I worked with one requiring it in addition to WS-Security. It's not very difficult to implement, but I threw together a library for anyone else that might need to leverage it.

WS-Addressing Library: soap-wsa.php
WS-Addressing Example: soap-wsa-example.php
* The example also uses WS-Security (not required for WS-Addressing) but demonstrates some new WS-Security functionality.

The functionality has only been implemented for a SOAP client side and has only been tested against a .NET service. If anyone runs into any bugs or interoperability issues, please let me know so they can be addressed.

I finally got around to uploading the slides for my workshop: Advanced XML and Web Services

Although it has been shortened and slightly modified from the previous workshops, I find that presenting the material keeps taking longer and longer each time. This is probably the last time I will give this workshop because in the future I am going to propose breaking it into 2 different workshops; One or the other unless they are to be given back to back.

As far as the conference went, I had a good time. The presentations I attended were good and it was nice seeing everyone again. I hadn't been on the West cost for over 10 years and my wife had never been, so once the conference was over we headed to San Francisco. Walked well over 100 miles that week, ate way too much food and had breakfast with the sea lions every morning. All in all it was a good vacation but I am still trying to recover from it as we speak.

Last month I released some prototype code for working with XMLSEC and XMLDSig in PHP and also mentioned that I would not be actively maintaining it. A few weeks ago I was asked by Pat Patterson, one of the Federation Architects at SUN, about incorporating the library for use in a PHP based SAML 2.0 service provider within the OpenSSO project. The code will probably recieve more attention there than I currently have time to provide, so you might want to check out what they are doing within their repository (note: the code located there is subject to the Common Developement and Distribution License). They are also looking for help from any PHP developers who might be interested in working the project.

So what does this mean to people already using the code or do not want to worry about any potential licensing issues?

The xmlseclibs code located on my site (including any changes I might make to it) currently is and will remain to reside within the Public Domain. Basically if you get the code from here you do not need to worry about any licensing legal mumbo jumbo (there is none). You will however be on your own for any bugs or problems you might encounter when using the code from here.

So what's in the future for working with Encryption and Digital Signatures in PHP?

We, Alexandre Kalendarev and myself, are close to being ready to add our xmlsec implementation to PECL, but are still working through some issues - especially in the Digital Signature area. Currently it can process almost the same files as when I use the xmlseclibs library, but is still lacking when trying to create signatures with multiple references.

For those who might want to try it out in its current state, you can Download the Pre-Alpha code, which includes some examples. Also, Alexandre has some documentation in Russian available, for those of you who can read it. It has taken us a while to get the code to this state, so hopefully we will be able to have an alpha release in the near future.

The slides for my tutorial and talk can be found at:
Advanced XML and Web Services (with accompanying code)
XML Security

For the XML Security session, what people are probably most interested is the code used to implement WS-Security and possibly Infocards using PHP.

Security Library - Base XML Security library implementing XMLENC and XMLDSig functionality.
WS-Security library - WS-Security library for use with SOAP. Currently only implements client functionality and is missing the ability to encrypt SOAP data.
Example Usage of WS-Security - An example of interacting with the Amazon Elastic Compute Cloud (Amazon EC2) SOAP Service. Easily re-factored for use with other services requiring WS-Security.
Infocard Library - Base library for processing infocards.
Infocard demonstration - Demonstration of processing a submitted Infocard. The result is a SAML token along with a function to view submitted assertions. The form has NOT been updated to work with the recent namespace change, so modify the requiredClaims for use with IE7 RC1, Vista RC1 or .NET 3.0 RC1.

With the releases of RC1s for IE, .NET 3.0 and Vista, there has been a slight change in CardSpace. The http://schemas.microsoft.com/ws/2005/05/identity namespace has been discontinued in favor of http://schemas.xmlsoap.org/ws/2005/05/identity. In accordance with this change, as of today, the Infocard usage within my site has been updated to use the new namespace. Anyone running an older implementation will most likely be greeted with a message stating that the site requires a managed card.

This message is not really true and just means anyone using older CardSpace cannot access the site until they upgrade. I use the namespace when calling CardSpace only to identity the claims I require when submitting a card. The good news is that this change was only comsetic, requiring the small change on the registration and login forms. No backend code changes were required to support this namespace change.

Warning: I upgraded both my .Net 3.0 framework and IE 7 one after another and never backed up my previously created cards. Once my system was up and running and I launched the Windows CardSpace, I was greeted by a nice message telling me that either my cards were corrupted or somehow were removed from the system. I did not have a backup of them (good thing I have only been playing around with them so far) and was required to re-create my cards and re-establish relationships with sites using my cards again.

Lesson learned: Backup your cards prior to upgrading if you dont want to lose them!

If anyone is wondering what the new Infocard registration and login links are on my blog, let me explain. As I mentioned in my last entry, I am working on libraries to work with XMLENC and XMLDSig in PHP. Being complicated technologies, the code produced so far has been just trying to design a API that uses PHP's KISS approach before moving on to writing bindings for the XML Security Library. In order to test out the APIs I wanted to use real world scenarios, such as building a class to handle WS-Security using the routines from the API. A few months ago I came across another technology leveraging XMLENC and XMLDSig: Infocards (aka Windows CardSpace). I am getting really sick of long blog entries showing up almost in their entirety in aggregators, so I am truncating this here and you can read the full entry for the rest of the story.