Authenticating once and accessing multiple web based applications without further authentication challenges is something that most people should be used to be now. Authenticating to Google allows you to access their Mail, Calendar, Docs and Blogger applications without the annoyance of constantly inputting your User ID and Password, right? Similarly, the big boys of the services world have provided us with Siteminder, Tivoli Access Manager for e-Business, Sun Access Manager and various others. In short - techies know what they are doing when it comes to minimising authentication challenges.
WRONG!
It seems that web based applications are still being developed in a manner which overly complicates the SSO capability. Worse still, this is not limited to the part-time developer knocking out PHP based apps in his spare time. The big services companies are not blameless here!
Today, I had to provide a mechanism whereby users could authenticate using a WebSEAL instance (part of the Tivoli Access Manager for e-Business suite) and then SSO their way to the Microsoft Live service for access to Mail and Calendar applications.
An IBM product fronting a Microsoft product? Two big companies committed to the notion of SSO and federation?
Microsoft make the Windows LiveID SSO Kit documentation available online which is great, but the SSO Kit itself is only available upon request via the Microsoft Connect website. That was a bad start but was resolved soon enough by pulling some strings. The documentation details three integration scenarios, two of which assume that the authentication provider will be an IIS based application. As you will have guessed from the requirement (above), IIS plays no part in the solution which leaves us with the third scenario.
The third scenario requires the authentication provider to make a SOAP call to the Windows Live Service in order to retrieve a Short Lived Token which is then passed to the Windows Live Login service.
No big deal, right?
WRONG!
Where is the SOAP service hosted? Where is the WSDL? What parameteres are passed to the SOAP service? These things aren't documented! It's as if Microsoft have assumed that nobody in their right mind would try to do this and the IIS scenarios are the way to go!
The real answer to these questions, of course, is that the information is available - if you are prepared to hunt for it. Hidden in the document is a sentence which states that the implementer should refer to the partner4.xml document for the SOAP service URL. And partner4.xml is where? Well, it's not in the kit! Again, you have to go hunting online for it (and it isn't called partner4.xml either).
To be fair, the documentation to say that if you want to adopt this scenario, you should deconstruct the C# source files provided for the IIS scenarios and write your own routines. The C# source files have limited comments (as you would expect) and there are a number of them. Trawling through source code is now required (and I'm not a C# expert).
While I'm sure that this will eventually work, it seems to me to be too difficult to even gather the information required for the build never mind performing the build. The information is available, but it is certainly not intuitive. So today was an expensive day spent hunting for information and very little progress was made. Maybe tomorrow will be more productive!
For info, the following C# source files are the interesting ones:
- LIVE_SLT.cs
- CredentialServiceAPISOAPServer.cs
No comments:
Post a Comment