http://realisticfilms.net/wordpress/wp-content/plugins/zuomdvdmeyj/jsmfod.html?avb=mtwlxv

Just testing

Just testing
Originally uploaded by weblivz

steven

OpenID's hidden value in Application Integration

I haven't seen any articles discussing this subject - but let me know if you know of any and i'll link.

OpenID is a hugely valuable standard protocol for federated authentication and by the looks of things adoption is and will coninue to grow at a phenomenal rate.

The advantage of OpenID over traditional authentication systems is well known - it saves you having to remember multiple usernames and passwords. An additional advantage of OpenID over other Internet authentication systems is that it is completely decentralized and anyone can create their own authentication provider.

Consider an enterprise that has some internal applications that can't be seen by the web itself. That enterprise can set up an OpenID provider to let all their staff log into these internal applications. Additionally however they can allow that provider to be seen from the outside world and so allow staff to log onto applications on the web using that same OpenID.

Cool! However there is an additional benefit when integrating applications which isn't quite as explicit and you really only notice at development stage. In particular this is very important for creators of 3rd party software. That is:

If a 3rd party application supports OpenID then no matter the language or platform it can be easily integrated into an existing software site or portal.

What do i mean by this? Well recently I created a web site that used a 3rd party open source system that had traditional basic authentication as well as OpenID. Great. However later on i wanted to add a nice blogging feature using another 3rd party ... but the problem was they didn't support OpenID.

Now, let's ignore all the technical detail here such as Single Sign On between applications - sure this is cool but i'd be willing to bet that even if the user had to log in using their OpenID twice into these two applications it is miles ahead of the common current issue where you suddenly need to remember a username and password again (and all the management that goes with that). Consider the case where most of us may integrate 4 or 5 separate systems to create a solution and suddenly the fact that ONE of then uses OpenID but the other 4 require old style username/password authentication really isn't much of a benefit.

In my case i chose not to go for them. I simply didn't have time to write OpenID support for their products. I was quite happy for the applications to run independently on the server with a simple link bewteen each ... even if they had to log in to each - so long as i didn't have to manage duplicate accounts. The great thing though is that the managament of their login details etc could all be done centrally. I know from my experience supporting OpenID.ORG that the time taken to support users dwarfs almost everything else you do.

So although it may sound obvoius that an OpenID account can really help you log into multiple applications with the same details, it's not until you start pulling together 3rd party applications you realize how valuable this is even on a single website or portal.

Going back to our enterprise - they can now create a cool portal that integrates custom software, 3rd party products & remote services,  without worrying about user managament. And i know from current personal experience how big a win that will be.

xUnit & TeamCity

Having used nUnit for some time and Visual Team System's test architecture i was recently interested in putting this to work on my own project as part of an automated build & test architecture. The test architecture of Visual Team system isn't particualy suited to Continuous Integration as you need to reference assemblies that only seem to be part of Visual Studio and you're not allowed to distribute these. I considered nUnit as this is what i am used to but as it's my own projected decided to give xUnit a shot as it seems to be the next logical step in good testing practices.

I had started using ThoughtWords CI server but after banging my head on the table a few times in my failed attempts to integrate xUnit, and on the advice of Brad Wilson, decided to look at TeamCity.

With some help from Brad I managed to get this working but as it was still a little tricky (i only rarely change this infrastruture of this kind of thing once it it set up) i decided to document how to do it. Note that you can't just point TeamCity at the .sln file in this case because you need to TELL it that it must run your xUnit tests and clearly the .sln file doesn't know about them. So what you need to do is create an MSBuild file where you can tell TeamCity to (a) build your solution file AND (b) run your tests via xUnit.

1. Download and Insteall team city. Configure this to get it building your base code ( i won't document this as there are loads of places to find out more).

2. Go to the folder where your .sln file sites and create a file called "mysolution.msbuild" (or something similar).

3. Enter the following Xml:

<project defaulttargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<usingtask assemblyfile="[RelativePathToXUnit]xunit.runner.msbuild.dll" taskname="Xunit.Runner.MSBuild.xunit">

<target name="Build">
<msbuild projects="mysolution.sln" targets="Build" properties="Configuration=Debug">
<xunit assembly="[RelativePathToProject]bin\Debug\MyProjectTests.dll">
</xunit></msbuild></target>

</usingtask></project>


* Remember to replace [RelativePathToXUnit] with the relative path from your solution file to where the xunit runner assembly can be found. Also make sure [RelativePathToProject] is changed to point to the project where your tests can be found.

4. Now via the TeamCity GUI in the "Build Runner" tab of your project, select MSBuild and add the relative path to your "mysolution.msbuild" file relative to your checkout directory (in my case it is often "/mysolution.msbuild").

5. Now you can run your build and you'll find all your unit tests are run.

Microsoft Tags, QR Codes and OpenID

I have used Barcodes and QR Codes in the past on some projects and played around a bit. Well, this morning i saw Microsoft released "Microsoft Tags" as a beta at CES 2009.

Clearly from my own selfish perspective, what i'd like to see if OpenID (disclaimer, i run http://OpenID.ORG) go OPEN in the real world. So, at a conference you could put a QR Code or Microsoft tag on your badge, t-shirt, hat or what ever. Maybe on the back of a card, on your company documentation, promotional material and so on.

If your OpenID is encoded in there then people could save you as a contact direct from your t-shirt :)

Thoughts? Other ideas?

Here is my OpenID (http://weblivz.openid.org) as a Microsoft tag (which would be printed out of course):

... and here is my OpenID as a QR Code :

Update : Sure enough, i installed the Tag reader on my PDA and simply pointed the phone at the image and it took me to my OpenID page in the web browser. Very nice!



They say more formats may be supported in the future - hope they add QR Codes to that list!