Identity - 2

The majority of people using/playing around with Information Cards seem to be using Microsoft CardSpace as their selector. That's not surprising since it is pretty much the de-facto standard for selectors and, as people always hear me remark, it's really pretty. More than 50% of my time is spent using Fedora, so CardSpace (running under Windows only) is really out the question. Those who know me, know that the selector that I prefer is the xmldap plugin for firefox. Even with the problems I used to run into by using it. I say used to because it finally now works without having to modify any of the code.

It turns out that the cause of my problems was due to the dependency on Kevin Miller's selector chooser. The initial usage of the chooser allowed users running firefox to use the CardSpace selector (normally only available within IE 7). Now, as I said I am running Linux, so this chooser was useless to me. In fact, it does not work on Linux or Macs as detailed in an open bug report. Really, that is not an issue because for one thing CardSpace isn't available on those platforms and secondly, it's easy enough to enable/disable plugins in firefox to choose which selector you want to use anyways. Over the past couple of days, I worked with Axel Nennker to finally resolve the major issues I was having and there is finally a working version again.

I was never aware of this, but, the selector and it's development efforts can be found within the openinfocard project. Prior to this discovery, I would always just monitor the version available at Chuck Mortimore's site. I'm glad to have found this so now I can stay on top of the changes made to make sure the selector continues to work on non-Windows (at least Linux) systems.

Last month I wrote about a managed card demo in an entry called Managed Infocard Demo and had supplied the code used to create the managed card. Most people who read this blog already are aware of the xmlseclibs library I wrote. There is, however, a missing piece to the managed code example I had posted, which I am finally getting around to talking about. It is the Infocard Managed library file (icard_managed_lib.php). This library provides the functionality needed to create a managed card that a user can download and install. The actual consumption of a managed card is handled by different code that I will eventually get around to talking about in the coming months. As you might guess from the amount of time between my entries, free time is not something I have a lot, so things are a little slow going.

The library is still a work in progress as it doesn't implement every feature (i.e. currently only adding support for username authentication exists), but is a good starting point for someone wanting to create managed cards in PHP. The library contains a number of classes, making it a bit more logical when constructing a card. The include:

ICard - This class is the container for the managed card. Using this class, you set all the various aspects of the card, such name, identifier, claims, services, etc... This class is used to assemble the managed card which is then embedded within an XML Signature.

ICardClaimType - Used to set the URI, name and description of the supported claims. As you might notice in my example code, I created my own claims having the URI - http://cdatazone/preference, the name - preference, and the description - Category Preference.

ICardEndpoint - Used to set the location of the Identity Provider (IP) and the Metadata Exchange service (MEX). It also provides the mechanism to add the identity certificate of the IP.

ICardUserCredential - Class to setup the authentication used with our managed cards. Currently only username/password authentication (ICardUserCredential::UsernamePasswordCredential) is supported, but extending this would not be extremely difficult.

ICardTokenService - Used to group the ICardEndpoint and ICardUserCredential objects together as a single service. This is necessary as multiple services (ICardEndpoint / ICardUserCredential combinations) are supported.

ICardSAML - Used to create a SAML 1.0 document. Currently used further on when I demonstrate the interaction of an Infocard selector with an IP.


Using these classes, required libraries, and the previously discussed example code, you should be able to easily create managed information cards using PHP. I will continue to work on the library on and off, so if you decide to use it, make sure you check back intermittently for any updates.

Over the next couple of months, I will go into further details on working with managed cards in PHP. Now that you can provide end users managed cards, you still need to provide the mechanism for users to retrieve the underlying information as well as consume this data once it is passed to your application. This, however, will have to wait until next time.

Source Code:
Infocard Managed library (icard_managed_lib.php) - version 1.0.0.
example code - demostrates library usage.

You might have guessed by now, but I'm pretty keen on the xmldap identity selector. Most of the time I am running Fedora 6 with firefox and this was the first functional selector available for that platform. I have played with some others (also yet to be released) but until I find a compelling reason to switch, I am going to stick with this one.

Now, granted it is still a work in progress and bugs are to be expected, but it really drove me crazy this past month while I worked on the code for my managed card demo (the Microsoft Cardspace selector btw worked flawlessly). As of this time, the current xmldap selector doesn't seem to work with managed tokens. I have filled a bug report with a proposed fix, and until it is either fixed or I find out that I am doing something terribly wrong and its not the selectors fault, I am making available an unofficial 0.9.2 selector containing that one change (meaning with it you can use my demo).

Unofficial xmldap-0.9.2-cdata selector:
You can download it here: xmldap-0.9.2-cdata.xpi.

Now, my initial problems began prior to this bug. After my code created the managed token, I could not for the life of me get the selector to create a card based on it. Unlike Cardspace, which thankfully logs all the errors in the event log, this selector did not make a peep. It simply would not do anything after selecting the card from the filesystem through the selectors gui. This is where opensource really shines. I was able to open up the xpi, enable debugging and add some additional debugging routines for myself. Come to find out the card I was creating contained a BOM. There is nothing wrong with this, perfectly valid with XML documents and worked fine with Cardspace. The xmldap selector however craps out bad. Once making sure the created cards did not contain a BOM, I was back on track.

My next problem had to do with my testing. I was repeatedly installing cards to test out the affects of some of the optional fields from the managed card structure. The problem now ended up being that the selector doesn't update the cards (based on the card ID and the version). I ended up with a store containing a good number of the same card. This really wouldn't have been so bad except once this happens, it seems like the selector gets confused making it impossible to selecting any of those cards (my other self asserted cards still worked fine). Again, thanks to the wonders of opensource, I saw that the store was an XML file located within my firefox profile. I was able to open it up, remove the offending cards, and start again. With a single card for my demo system in my store, I was now ready to fully try out the relying party.

Ok, next roadblock (and this was the big one). When submitting my card to the RP, the token is retrieved so my username and password are required. Things were looking good until I got a big popup on the screen with a Java exception error. Something about a chainLength. This one took me a good few days to find out what was going on, which ultimately lead me to that bug report and the code change. Hopefully that patch is correct as this was the only problem that I could not work around on my side and had to modify the selector code itself. Again, feel free to try it out: xmldap-0.9.2-cdata.xpi. It is a copy of the xmldap released version with that one line added to the infocards.js file.

I finally finished putting together a demo of a system using the PHP code I wrote for Managed information cards. Other than the minor problem I previously had with namespaces, getting it working with Cardspace was simple. The xmldap selector, on the other hand was not so simple (more on that in a separate entry). Anyways, after having been first introduced to infocards, I envisioned a system where I would be able to surf the web maintaining my anonymity, yet still be able to achieve some personalization on sites. Sounds a bit like an oxymoron, but let me explain.

My surfing experience is pretty bleak. I use anonymous proxies to shield my IP. At most I only accept cookies during a session. I wont register with a sites unless I have some specific reason, and I wont give a site information (requiring another login mind you) just so they can tailor the site to my interests. I don't really care about the social networking sites - though I've tinkered with LinkedIn so dont have much of linkability. Software cleans up any non-trusted cookies and scrubs the disk each time I shut down the browser. I am probably the thing marketing people hate the most.

Now, when I was first exposed to this technology, I envisioned the possibility that I could pass some of my personal preferences to a site I was visiting, allowing them to tailor their site to me, all the time then not knowing or having any further information (no email address, no username/login, etc...), simply just a list of things I am interested in. While creating my libraries in PHP for an identity provider, I decided to create a working demo of what I envisioned. I went so far as to create the identity provider on a different domain than the relying party.

Getting a Managed Card:
How this system works. You first need to register at https://www.ctindustries.net/icard/index.php. Registration simply involves setting up a username and password (in order to retrieve the card and manage the account) and selecting from 1 to 3 of the listed categories you are interested in. Once you have successfully saved this information, you can then click on the Retrieve Managed Card link to download and/or install the managed card. Although I set a custom type, I decided upon SAML to convey the claims.

Using the Card:
The relying party side resides at https://www.cdatazone.org/demostore/index.php.

When not logged in, the system will randomly select 3 categories for you and then randomly display the top 3 items for sale within those categories. This is done leveraging the Yahoo! Shopping API. Each time you refresh the page the results will either be displayed from a local cache or are fetched and cached. (So Please be patient if it takes a few seconds making remote requests behind the scenes).

When logging into the demo system, the identity selector will retrieve your previously selected categories and pass them to the system. These results you now see are based on your personal categories rather than the system randomly picking them for you. Each time you refresh the page the results returned will only come from one of your categories.

Now, I really don't know how feasible of a use of information cards this really is, but it something I really wanted to see if possible and the reason for this demo. I will be releasing the code over the next week. I am currently debating whether to use native ext/soap, so all conditions (like errors) are handled properly or just leaving the code as is (some XML build on the fly and some embedded within soap structures). Until then, I am at least providing the code used to create the managed card, which in turn uses my new library code: createcard.phps

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:

It's no surprise to anyone who has visited my blog before that I have had InfoCard support within Serendipity for some time now. Serendipity was not originally designed with third party authentication mechanisms in mind, so in order to allow for this, I had to heavily modify the internals of the code. Although an external authentication plugin has been available, it simply allows a username/password combination to be validated by an outside source. This combination is then saved in the Serendipity author table and then pulled from there. Not the best solution (and a simple explanation on my part of how it really works), but in the case of OpenID and InfoCard quite impossible. There are no username/passwords being submitted to the blog. In any event, this made Serendipity upgrades very painful as I had to merge my changes by hand into the new revisions. The problems I had with integration have been the very same issues that has prevented the addition of OpenID support.

That is until now (hopefully).

A while ago I was having a conversation in which I mentioned that I was surprised you didn't see Information Cards used with more languages. Without thinking I quipped that even I could easily port the code I wrote in PHP over to Python. I tend to be one of those people who if you say you are going to do something, by god you better see it through; so it was time for me to put up or shut up. I haven't touched Python in a good 10 years so I had my task cut out for me. One of the biggest problems I had while going through this exercise was finding out what modules I need to and/or should use and then figuring out how to use them.

Using a stock Fedora 5 install, the only additional modules I had to install were python-crypto, m2crypto (both used for different crypto aspects) and lastly, PyXML (so that I had access to xml.dom.ext for canonical xml support). The remaining modules I used were already available. Although it took me a few days to port the code, an experienced Python developer (who was also familiar with PHP) could have easily done this in a few hours - and their code would have been much better.

You can find the source code for all of this within the python section of my Source Code page. I have also made a Python Information Card Demo available. The code simply decrypts the submitted card, verifies the signature on the included SAML document, and prints out the included Assertions.

I probably will continue to complete the conversion of the code so that it also supports the (yet to be tested) encryption and signing functionality, but will go no further than that. I am not a good Python developer (if you couldn't tell from the code) and it would benefit much more from someone who knows what they are doing in the language. The only reason that I am planning on completing the remaining the functionality is simply because I started it so will see it through.

One question and comment I often get is why I am re-inventing the wheel. There are already libraries out there that do XMLENC and XMLDSIG, so I am just wasting my time with “just another implementation” (that is also not complete I may add). I am specifically referring to the original PHP code for XMLSec, WS-Security, etc.. To these people all I can say is that they are not wrong and I do not disagree. I would love to be spending my time doing something else, but there is something that these people do not quite get. All of these other libraries are C libraries and/or have a good number of other dependencies. Previously to having gotten my own dedicated server, I was in a virtual hosting environment. Anyone working in this type of environment knows that it is not easy and many times impossible to get a hosting provider to install libraries outside of their base supported development packages. Another issue is that these technologies are difficult to work with. Even using the libraries, a developer still needs to know a lot about how the stuff works. To make these technologies available to a greater number of people, I decided to see how much I could write in PHP code using commonly available packages. The goal was also to make working with the code extremely easy; which means that not everything is supported, but from the feedback I have gotten so far, it has provided at least 95% of the functionality needed by the developers using it. This doesn't mean there won't be a C library for at least PHP. It has been in the works for quite some time, and is close to an initial release. The only caveat is that it will be relying on a yet-to-be released version of The XML Security Library.

It has taken me quite some time to come to grips with OpenID. Why? Because I trust no one. When I first started playing around in the Identity arena, I thought it was a great step forward in protecting my identity. Minimal, and only information I allow, is released to the requesting party. The requesting party has no need (and should not unless absolutely necessary; after informing me they are doing so) to store any of the information provided with my identity. This doesn't mean though that they can't store other information to make my experience at their site better.

Take your favorite on-line store for example. It eventually should be possible to login into their system using your identity (leaving it vague right now what type) and maybe have a profile they store that's tied to your identity so that they can tailor their site to you, say promoting only products in categories you are interested in, like computer gadgets rather than dishwashers. This all sounds great, so what's my problem?

I am paranoid when dealing with companies involved with marketing. I typically would be browsing their system through anonymous proxies and be using site specific email addresses if I need to register. In most case I browse on-line stores to compare products, product reviews and prices and only shop at a handful of stores I actually trust. So to get the personal integration on all these sites, I would either be using my OpenID or an InfoCard to logon. The difference between these two technologies is where I start having some issues with OpenID.

While playing around with the identity technologies, I decided to get myself an i_name and give it a spin. I am =Rob.Richards (or using my i-number: =!4015.A5A3.AE2A.54B9). An i-name is similar to a domain name. Just like my website is identified by my domain name, I can be identified by my i-name. In the event i-names catch on, I figured it was a good idea to get the one I wanted now rather than take my chances later. Do you know how many people right now confuse me with this Rob Richards? Just so we are clear - that is NOT me .

You might notice that I am using the xri.net url for my i-name, though when you access it, it resolves to 2idi.com. 2idi is the broker where I got my i-name. It is perfectly valid to use their urls when resolving my identity, but by using xri.net, I could move my i-name to another broker down the line and have no need to change any of my contact links. Due to having to resolve the address to my broker, it is a little slower doing it this way, but at least I wont have to change anything down the line if I change brokers.

Recently I have wondered whether using InfoCards can help reduce the amount of comment spam. Granted, I am fully aware they are not meant to solve the spam problem, but I was still curious about their effectiveness. Comment spam is a constant nuisance for both bloggers and forum owners. It is so bad that typically either the ability to leave comments is turned off or user registration to the site is required. In InfoCard terms, I will be using self-issued cards (probably the most common type that will be seen for this use) as the means of authentication. Unlike managed cards where the blog or forum site would trust a third party to validate claims, the site would simply be trusting the claims made by the end user. This is really no different than current registration schemes where the user just types in their information.

In addition to the requested user information, the site generally verifies the email address provided to insure that the submitting user controls the particular address. This holds true whether an InfoCard or traditional method is used. Email verification is usually performed by the site sending an email to the submitted address with a link, containing some identifier, that the user must click on or navigate to to verify their address. Once this is done, the site has verified the user's registration and allows the user to now login and add comments or post to the forum.

This past weekend, I wondered how easy it would be to automate this process (of course using PHP) with InfoCards and let me create comment spam. Needless to say that I found it quite easy and realized how important that the human factor must be taken into account. This means that I need to make sure I am verifying the registration of a LIVE person and not some automated routine. With the traditional method of user registration (you know where you actually have to type in all your information), it is common to have some form of captcha, making it very difficult create an automated process that is able to create a registration. Using InfoCards, there is no typing. Simply click on an image, select your card within the selector and the selector automatically submits it.