The only thing that needs agreement is the protocol. There are two choices IMO. SAML, or WS-Federation. SAML2 is pretty good but limits implementers to the passive requestor profile (it relies on the browser for the HTTP 3xx redirects) and means you can't use services[1]. It also doesn't do attribute provisioning (something U-Prove can do). The SAML protocol also mandates use of SAML tokens. WS-Federation on the other hand lets you use any token you like. And it supports services.
[1] TBH I haven't looked at SAML for a long time. It may well have come along by now.
As mentioned, I don't know what the requirement is. The article mentions Ruby, Python and Node, but also suggests those selections are random to introduce complexity.
Would I choose WS-Fed? Depends.
Maybe, if the IDP uses AD. The benefit is that you can use ADFS and only code out the relying party. Definitely, if the solution is service-based. And also definitely, if a). I need a token other than SAML or b). I'm doing anything with Azure or Office 365.
I guess a more interesting question is why I'd code web SSO from the ground up when there are two stable protocols out there. I wouldn't. I'd use what brains more capable than mine have already designed. Something that has been out there for a while, and has proven itself to scale and be secure.
Security is very compelling. WS-Federation is used to protect some very, very sensitive public sector services. And I'm talking a lot more sensitive than the HR solution I built for the UK government.
By the way, I should've mentioned this -- you can get WS-* -based federation without having to "adopt a WS-star XML-hell enterprise standard".
The way you'd do that is by putting ADFS or another WS-Federation-capable proxy (UAG, maybe) in front of your Django/Node.js/etc. app. All you need to do then is to deal with claims. Not even, if you have something like UAG transform claims into AD roles. Note that that approach doesn't rely on AD. You could use a flat text file, XML or SQL Server.
And while I'm here - coding up something that uses a non-ideal technology (XML) is still a better option than re-inventing the wheel. 'Specially in this context.
Well, the question was asked why Ruby, Python, and PHP apps don't have an existing SSO standard. I guarantee you WS-foo is never going to be that standard.
