CDATA Zone - Identity

Digital Identity and OAuth slides from ZendCon

nospam@example.com (Rob Richards) — Wed, 21 Oct 2009 15:29:00 +0000

Slides have been posted for the latest version of my Digital Identity talk.

The contents is a bit less technical than in the past and is aimed at wider audience than just developers. Please contact me if there are any questions on the material or topics presented. Rob Richards.

You can also find the slides from my OAuth presentation.

OAuth Signature Validation Tool

nospam@example.com (Rob Richards) — Wed, 07 Jan 2009 12:26:00 +0000

While working on OAuth implementations for our clients at Mashery, one of the biggest issues I see developers running into is how to debug and fix invalid signature errors. There are numerous OAuth libraries out there, in fact we even have our own, so how do you determine which side is really generating the correct signature and which has a flaw in the logic? I find that using a third party library is a great way to quickly zero in on which side is at the root of the issue. The problem, however, is there are no readily available tools to do this. I have found a number of test applications, but they pretty much are for testing wether a consumer library/app is working correctly against them.

We mostly deal with providing the service provider side of OAuth, meaning numerous different endpoints, so these tools were of little help. I ended up writing a down and dirty signature generation app using the C# OAuth library (so Windows only folks). It will generate a signature based on the different OAuth parameters you enter. You can use this to compare the signature it generates to that from your consumer app or service provider. Full source code and more detailed information can be found on the Mashery Customer Solutions site. Time permitting, I may continue to add features to this tool. Hopefully others find this useful as well.

Source and Binaries: OAuth Signature Validation Tool

Digital Identity slides from ZendCon

nospam@example.com (Rob Richards) — Mon, 22 Sep 2008 12:23:00 +0000

Slides have been posted for the latest version of my Digital Identity talk.

This talk has evolved since I first starting giving it, but the latest version simple needed more time to present. I was asked to combine all the topics (OAuth was to be its own presentation) into one, which I probably won't do again. Even just only covering the absolute basics, I found that there just isn't enough time to cover them all in the short amount of time, so some material was skimmed over. If anyone has any questions on any of the material, please feel free to contact me.

Brick & Mortar No Safer Than Online

nospam@example.com (Rob Richards) — Tue, 27 May 2008 11:27:32 +0000

Did you ever think you would have to worry about your data while visiting the grocery store? Less than 3 months ago, I was one of the victims of the Hannaford data breach where my credit card number was stolen and fraudulently used. This is kind of ironic. I talk about the digital identities and keeping your data safe. I never thought I would end up on the receiving end of this. Discover card has an excellent fraud department, imo, and immediately of detecting fraudulent use, contacted me. I was issued a new card and it was sent overnight. On Saturday, while in Chicago for php|tek, I received another message from Discover card about fraudulent use. It really sucks when this happens while traveling because the card gets shut-off. I was leaving on Sunday morning, so an overnight delivery wouldn't even reach me. Anyways, I got things settled and was able to check out of the hotel - even paying my bill .

Continue reading "Brick & Mortar No Safer Than Online"

RSA Identity Interop

nospam@example.com (Rob Richards) — Fri, 28 Mar 2008 10:32:00 +0000

Now that I've settled into my job at Mashery, I've starting getting a chance to get back to some of my side projects. On the information card and openinfocard front, I am currently looking at getting the selector to export and import cards so that I can synch up my cards amongst my different selectors. More importantly though, I will be in San Francisco for work in little over a week, allowing me to attend and participate in the OSIS User-Centric Identity Interop event at the RSA Conference. While I only play an insignificant role in the openinfocard project, I will be there as part of that project as well as representing my own information card code.

We even have our own logos . Axel did a great job coming up with a logo for openinfocard. As I was up at the PHP Quebec conference when they asked for logos, Julie was kind enough to quickly pull one together for me. With under 24 hours to get it done, no graphic utilitities installed on her new macbook and extremely bad internet bandwidth to even try to download any applications, I think she did a fantastic job.

Anyone interested in participating or seeing demonstration of the identity technologies should be sure to check it out on April 8th and 9th from 11am - 6pm. As I am out there primarily for work, I will most likely will be there later in the day. If you can't make it but are interested in getting involved, interoperability testing is currently underway.

Updated 04-03-2008: The openinfocard logo has been changed to the one now displayed

2008 Rings In Unemployment

nospam@example.com (Rob Richards) — Sun, 06 Jan 2008 00:05:00 +0000

2008 is sure off to a lousy start. I went back to work the first work day of the new year after some relaxing time off just to be told the entire IT department has been let go effective immediately. I am just praying this isn't an indication about how the rest of the year is going to go. I get enough of the open position emails, but the trouble is that I am not going to leave Maine. I like it here and it's a great place to raise a family. That being said, if anyone is looking or knows of someone looking for a developer in Maine (I'm trying to avoid doing Java full time) or that allows for a full time telecommuter, I would appreciate any leads: You either already have my email address or contact me via: =rob.richards.

As far as outside projects I am involved in and work on, I do plan on continuing working on them, although I might be a bit MIA for some time until I get settled. My apologies for tagging this in all categories, but hey I need to get maximum exposure here.

Microsoft and XML Fundamentals

nospam@example.com (Rob Richards) — Mon, 17 Dec 2007 14:07:00 +0000

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.

Identity Selector Catchup

nospam@example.com (Rob Richards) — Fri, 14 Dec 2007 16:50:00 +0000

A lot has been happening in the world of identity selectors and I'm finally getting around to mentioning some of it. In the past, you might have noticed that on my linux machine, outside of the openinfocard selector, I have had little to no luck with any other selectors. Things have finally changed in this regard. You might be aware of the DigitalME selector. I may be mistaken, but believe it to have been the first selector available for the Mac. There is still no Windows support, but I did find a Fedora 7 rpm available for download. As I had recently upgraded to Fedora 8, I decided to give it a try and was pleasantly surprised with the results. As you can see from the following screen shots, it is really clean and polished, oh I forgot to mention the big thing that is also works (for the most part).

If you look at the larger image, you will notice the selector divided between 2 parts. Within the "My Cards" section, I have selected the CData Personal card (notice its highlighted). To the right, you are presented with the claims that will be submitted with the card.; Personal Private Identitifier (which I have blurred out), my given and surname (Rob Richards) and finally my email address. The last two items listed (http://www.bandit-project.org/identity/claims/groupmembership and http://burtongroup.com/interop/2007/05/identity/cameratype) are optional claims for which I am not providing any data for.

As you can see, I am now successfully logged into the system. It breezed through some of the sites I test against and worked fine with my own managed card demo. I did run into a few glitches. I think the wrost happened to be when firefox had launched the selector and I accidentally clicked on something outside of the selector; cuasing it to go to the background. Well, my desktop ended up to be a bit useless at that point. Everything was greyed out, since I was the stages of selecting a card, but I couldnt get the selector to come back and no clicks or key presses did any good. I ended up having to reboot at that point (And this, folks, is why I test out new selectors within a VM).

Now, this doesn't mean I am switching my selectors. Although for most people, I would recommend using DigitalME over openinfocard, mostly due to the fact that openinfocard is currently a development selector with lots of debug code too, but also DigitalME looks slick; still not up to the CardSpace eyecandy level, but getting there. I have been using openinfocard for well over a year now and think I'll stick it out with it and see where it goes. Plus, there's plenty of work to be done on it, so when I have time I try to help (though pitiful it may be), with it.

One change in the works I am looking forward to see developed is the identity selector selector, which is currently in its infancy stage. The problem boils down to the possibilty of having multiple selectors installed. How does a browser determine which selector is launched when called for? On the simplest level, the identity selector selector would allow a user to specify which selector they would like to use, so when one is called the correct one is launched. This stems from a firefox extension to support CardSpace. Work is now being done for a plugable system so that selectors can fit within this framework, providing the user with choice rather than selector conflicts.

Another change that has occured is the usage of Infocarmation cards without the requirements of SSL. CardSpace rolled out this change in the 3.5 .NET release. Other selectors, such as the latest openinfocard releases, already support this functionality. You can test this against a little demo I wrote: Non-SSL Infocard support. This takes advantage of my latest infocard-lib library, which simply by passing False as the third paramter to the processCard function, handles the non-ssl enabled communications without any other code changes.

These are just a couple of the changes that have/are happening, but imo a little more noteable than others given an end user perspective. Personally I am excited over some of the changes that have been made to the openinfocard selector (i.e. remote card storage). Those, however, I will leave for another day. Given that there happens to be a nice snow storm heading into Maine this weekend, I expect to have plenty of time to present some of those changes.

Library Updates and Other Dealings

nospam@example.com (Rob Richards) — Mon, 10 Dec 2007 14:35:00 +0000

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....

Continue reading "Library Updates and Other Dealings"

Infocards and E-Commerce

nospam@example.com (Rob Richards) — Fri, 05 Oct 2007 15:05:07 +0000

The other day I was reading some recent thoughts by Kim Cameron about Information Cards and CardSpace. It had gotten me thinking about the usage of cards and when they would be rolled out in the financial area. In particular, wouldn't it be really cool being able to used managed cards instead of having to enter credit card information when trying to purchase something online. You might ask what the benefit this would be... well I'll get to that in a minute. Today, while going reading through all the recent posts on Planet Identity, I was pleasantly surprised to come across an entry by Andre Durand from Ping Identity. He and another developer had put together a demo, integrating Information cards and an e-commerce site, demonstrated at Digital ID World 2007, that does exactly what I was thinking of. Now, how soon until reality is my question.

Anyways, here was what I had on my mind prior to seeing it. I for one, use temporary credit card numbers. This means that every time I want to make a transaction, I have to go to my financial institution, log in, generate a one-time use number and CVV, cut and paste those into the merchant's form fields and then hit submit. It would be greatly simplified if the merchant would accept cards, which means I just click on their "submit credit card i-card" button, at which point I would be asked for my credentials by my financial institution, and have a one-time generated card number, expir date and CVV automatically created and then submitted to the merchant's site. This would not only save me time and steps, but definitely eliminate the possibility that I accidentally sign into a phishing site, thus exposing my credentials and allow attackers access to my financial information.

The reason why Kim's article had gotten me thinking about this is that I don't see why financial institutions wouldn't be rushing to get this implemented out the in the real world. From their side, all they need to do is get the infrastructure in place to provide and manage the managed cards. They already have the software in place for users to provide credentials and retrieve the temporary numbers. On the merchant side, there also is little work involved. Provide the hooks and backend to handle submitted infocards. There is really no change to their existing software or business processes. They data points for the credit card (number, expir date, CCV, etc..) are the same, so all that would be required is to take the data from the submitted card and pass it off to the existing process. This also gets rid of the issue of trying to filter out card types in the selector from those that the merchant doesn't accept. My opinion is who cares? Nothing is stopping someone right now from entering in a Diner's Club card to a merchant who doesn't accept them. The user simply gets an error saying that they need to use a different type of card.

It would be great if the credit card companies could get say someone like Amazon to buy into this. It would get the things moving along in a major way. The only potential sticking point to this I could really come up with is getting all the credit card companies to agree on a common format. Worse case is that each has their own, but then it would be up to the merchant to make sure their software could understand all the different formats and parse them appropriately. I guess time will tell.

Identity Selectors

nospam@example.com (Rob Richards) — Tue, 02 Oct 2007 12:53:00 +0000

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.

Continue reading "Identity Selectors"

PHP and Managed Information Cards

nospam@example.com (Rob Richards) — Tue, 21 Aug 2007 09:50:00 +0000

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.

xmldap Selector gotchas

nospam@example.com (Rob Richards) — Tue, 10 Jul 2007 13:21:00 +0000

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.

Managed Infocard Demo

nospam@example.com (Rob Richards) — Mon, 09 Jul 2007 20:24:00 +0000

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

Catching Up

nospam@example.com (Rob Richards) — Thu, 05 Jul 2007 16:40:00 +0000

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:
Continue reading "Catching Up"