I have been using Windows 8 as the primary OS on my new laptop for about 4 weeks now.  And I have to be honest, it is really growing on me.  There are still little things here and there which bug me (usability with a mouse has taken an obvious back seat in some areas).  But overall, it is better.  I actually like the new start screen.  It’s like the start menu on steroids once you learn it.  Of course I am a fairly proficient shortcut key user so the UI stays out of my way most of the time.

I did try an experiment with Windows 8 and my wife.  I had her log into an out of the box install with no instructions whatsoever and have her try to “do stuff”.  Within a few minutes she was pretty frustrated (and she was just trying to browse the web).  Enough things have changed that she had a hard time finding simple things (like the clock and the back button in metro IE).  However after a quick two minute training session she was using it just fine and was possibly even starting to like it.  And after some simple modifications (like making Chrome the default browser) she was even happier.  So yes, this one is going to require some hand holding at first and there will be resistance.

But my real test for whether a new UI is better than the last is to try and return to the old one after using the new one for a while.  If I find myself missing the new UI, then I consider the changes a win.  A great example for me was the relatively new Office Ribbon.  There was a huge backlash when they made that change.  But for the most part, everyone I have talked to recently that has had to go back an older version of Office misses the ribbon.  Another example was the new start menu and task bar in Vista/Win7.  For anyone who learned to use the integrated search to launch apps and spent the time to personalize their taskbar, moving back to XP is very painful.

I am seeing some fairly similar sentiments already with Windows 8.  The more proficient I get in the new UI (yes, even on my dual display docking station) the harder it is to go back to Windows 7.  In fact I struggled with some driver issues at first (Dell finally released updated Win 8 drivers for some key hardware the day before the official Win8 launch).  But when weighing the pros and cons of dealing with the issues or going back to Win7, dealing with the driver issues won out.  And ever since the update it has been solid.


I do feel compelled to mention, as I would feel dishonest if I didn’t, that the metro apps still largely feel useless for those of us in a business environment (especially for those of us with dual screens).  The desktop is still a better environment for the type of productivity I need.  Metro will need to come a long way before it can replace the utility of the desktop for me.  But it’s fun to ‘play’ with.

So yes, the transition to the new paradigm is incomplete in this version of the OS and the gaps are apparent to those of us in the know.  But even with those gaps, I feel like this OS is an improvement and is moving in the right direction.  And I have not even tried it yet on its intended platform, their new touch devices.

casLogoRecently, I was given the assignment to help coordinate the single sign-on efforts between a new partner and our University.  Like many Universities, we use a single sign-on solution called CAS, or Central Authentication System.  CAS is an open source project sponsored by Jasig[1].

CAS supports an open standard called SAML [2] that allows us to provide both authentication and authorization information to our partners (and internally) without the need to share our user’s credentials.  Now I myself am not an expert in this area, but this assignment finally forced me to pay a little more attention to how our CAS infrastructure works, and more specifically to its implementation of SAML.

The first thing I wanted to know was what our SAML assertions (the user data exchanged through the protocol) looked like and whether they provided the right information to our partner.  Since CAS is a system that leverages HTTP, I figured it should be simple to make a few calls using a web browser and a simple tool–that allows me to make HTTP post requests–to manually create some calls that return my own personal SAML assertions back from CAS.

I began my experiment with my primary research mechanism, ask our experts.  However our experts (including our CAS engineers) had no clue how to make the simple web calls I needed.  How is that possible you ask?  Well they are all programmers and as programmers they rely on the nice Jasig libraries which, as designed, abstract away the necessary calls into the CAS system.

So what next?  Well Google, of course (or for the sake of fairness Bing too).  Google brought up several posts, albeit a bit old, about using the samlValidate endpoint and a tool called SoapUI to make the calls.  Unfortunately none of these instructions worked as they appeared to use older versions of CAS.

My searching did bring me to the Jasig wiki[3] which started to point me in the right direction. But it still fell flat when it came to providing me the complete picture to make my request.  CAS itself was not offering any help either as all of my requests were met with 500 errors (I did talk to our engineers about this since I eventually discovered that the endpoint was running just fine and the only issue was a malformed request).

At last, I finally broke down and went to my third method of discovery, writing and debugging code.  I downloaded the .Net client code provided by jasig[4] and was happy to find that there was a great demo app included.  After some debugging and html packet sniffing I finally came across the secret sauce to making the calls I needed.  Here is a quick tutorial on how I was finally able to do what I needed.

First you need to initiate a login into the CAS system and provide a return URL.  You can do this in any browser.  I gave a bogus URL so that the redirect back from CAS would fail and expose to me a vital piece of information.

After a successful login, the CAS system will redirect the browser back to the specified URL with something called a SAML assertion artifact.  Oddly enough, this simple call was the root of all my previous issues.  A typical (non-SAML) call into CAS uses the query string parameter “service” instead of “TARGET”.   Using that parameter you get back a service ticket instead of a SAML assertion artifact.  And as you can now expect, a service ticket does not work on the SAML endpoints.

The redirect came back looking something like this:


At this point, all that the originating system has received about the authenticated is this SAML artifact.  So now, in order to complete the process, a simple HTTP POST call back to the CAS system will return whatever information, about the user, that CAS deems necessary (usually at least a primary identifier).  To create the POST call, I like to use a tool called Fiddler[5].  It’s simple, yet very powerful.  Note that this call requires a SOAP body in addition to the properly formed URL.

The URL looks like this:

and the body looks like this:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=””>
<samlp:Request xmlns:samlp=”urn:oasis:names:tc:SAML:1.0:protocol”
MajorVersion=”1″ MinorVersion=”1″ RequestID=”_192.″

Notice the assertion artifact exists in both the URL and the SOAP body.  This is the only thing that differs in the body from request to request.  After making this call, you get back a SOAP envelope containing all the appropriate SAML assertions for the user in question.  At this point the originating systems has verified, through CAS, that the user did indeed know their credentials and was able to retrieve all of the relevant user data that CAS was configured to return (username, firstname, lastname, email, etc.).