Pi and Writing your own SAML Engine

Writing your own SAML Engine, like Pi, is not rational.  Unlike Pi, it can seem rational.  I promise you, writing your own SAML engine is not a rational act.  I have coached and counseled dozens of third-party developers, to the point of even getting in their face, and they don't quite believe me.  Hopefully you'll take this to heart, and avoid some pain.

I've been implementing SAML since 2002.  In fact, I've been doing commercial SAML as long as anyone has.  I was tech lead on the team that was the first to deploy SAML in the real world for real transactions.  We implemented the very first SAML interface to a 3rd party August of 2002, and then did the first 3-way handshake (chained assertion) a few minutes later.  Our commercial system, doing financial transactions via SAML federation, went live 6-Jan-2003.  Since those early day of SAML 1.0, I've implemented dozens of SAML 1.0, 1.1 and 2.0 systems, in roles that have included identity architect, certification engineer, build/run team, solution architect and consultant.  Undoubtedly, there are folks with more SAML experience than I have, but I've got quite a bit, and several implementations that have created scars.

Now that you know my bona-fides, let me tell you why creating your own SAML engine is not a rational act... even though it may appear to be a great idea.

Coding a SAML engine is one of the great examples of a bear trap laid before developers called Just a Matter of Programming (JAMP).  It seems pretty simply, doesn't it?  This is just some WS-Security Web Services with a canonical XML construct, easy-peasy.   Add a dash of auth and a quick crypto lib call, and done!  Yeah, no.   I have not quite seen professional developers break down and cry, but I have seen highly-lauded developers with impressive resumes founder on the rocks of SAML, even though they had all the right skills on paper.  Developers with 10 years experience doing hundreds of custom Web Services implementations have failed to deliver.  In fact, I can confidently say that I have NEVER seen a home-grown SAML implementation delivered in less than 3 months overdue for Browser Artifact SAML, and Browser Post Profile SAML is even worse, because getting mutually authenticating digital certificates seems to be a barrier that crack programmers slam against unexpectedly.  The scary thing is that we're not talking about script kiddies, but highly qualified developers that I've seen fail repeatedly -- kinda like watching a NASCAR driver fail to parallel park when given 100 tries.  It's not an expected outcome.

Perhaps you've had differing experience.  If so, you've been lucky.  I have yet to discuss homegrown SAML engine development with an experienced federation colleague and have anyone take the position that writing your own SAML engine is a good idea.

I'll admit that it's been 14 years since I was a hard-core client-server developer.  I cannot speak authoritatively and explicitly to the exact reason why this is hard, but point out that a SAML engine is the intersection of interactive web-services, session management, access management, cryptography and web access management engines.  Add in load-balancers, firewalls, VLANs, application firewalls and packet rewrites along the way, and it's a devil's brew.  I've also noticed that the incredible complexity that has been added within .Net and Java means that developers increasingly do not have a strong systems perspective.  Most developers seem to focus entirely within software, so may not readily understand network communications and protocols.  Whatever the actual cause, I can tell you that it's a big barrier.

Homegrown SAML engines also have enormous quality problems.  Since the Sunny Day positive- test scenario takes weeks to develop and get working, you can bet there is a lot of buggy code that will be discovered as unexpected conditions result in un-trapped exceptions.  In one notable case I saw a decade ago, whenever a load balancing error resulted in a timeout, an un-trapped exception in the code caused the last session to be provided to the new user -- session hijacking was the result.

Without a commercial SAML engine, who will provide documentation, support, training, maintenance, patching, upgrades and troubleshooting?  With a commercial SAML engine, changing the SAML exchange is a simple configuration change, while home-grown SAML means custom code changes.  Hopefully, the hot-shot developer who decided to write a custom engine is still available, and can figure out their code... but, frequently, they've already moved on.

Now that ADFS 2.0 provides for full SAML 2.0 interoperability, there is no longer any excuse.  It's been bad practice for a decade, it's time to kill this practice once and for all.  If your developers want to play with SAML, let them do so at home.  Meanwhile, buy a commercial SAML engine.  You'll be glad you did.

The next time someone suggests coding their own SAML engine, tell them it's as rational as writing your own Microsoft Excel, since you don't want to pay $150 for a spreadsheet.  Sure, Excel is just some C++ code, so anyone could write a replacement Excel, but it's not a rational act!