WS-Federation OASIS TC

I'll begin by quoting from a piece by Paul Madsen after the OASIS announcement of a new working group to drive WS-Federation towards standardization.  Paul writes: 

“James McGovern predicts:

‘I humbly predict that WS-Federation will become more important than SAML within the next two years and will invalidate all the hard work already done by the Liberty Alliance.’

“I guess it's over. I have to admit that I'm disappointed and, to be honest, even surprised.

“I actually thought things were going well, you know, lots of adoption, encouraging signs of convergence, important new functionality etc.

“As for the New Jersey Devils, it seems that the Liberty Alliance's playoff run is over. I'll be emptying my locker and signing autographs this afternoon before spending the summer golfing.”

Like Paul, I'm surprised, if not so inspired to irony, by James’ comment. 

I do agree that WS-Federation will gain a lot of traction.  But I absolutely disagree that it will “will invalidate all the hard work already done by the Liberty Alliance.” 

Liberty has contributed deeply to understanding a whole series of use cases and requirements, and the protocols, formats and concepts proposed by the SAML working groups have been an important step forward for all of us involved with identity.  Nothing about WS-Federation invalidates this work.

On the other hand, technology doesn't stand still.  Think back to the days when SAML was first posited as an alternative to LDAP authentication.  Those of us involved in LDAP from the very beginning didn't for one minute take LDAP as the end of all thinking about attributes and identity.   Ask LDAP guru Mark Wahl, or Bob “RL” Morgan or Keith Hazelton – people deeply involved in Kerberos and LDAP but just as willing to embrace new technologies like SAML as meeting new use cases.

Just as SAML broke new ground, WS-Federation is intended to address a number of things that people working in Web Services want better defined to facilitate interoperation using WS-Security and WS-Trust. 

These protocols hadn't even been invented when SAML evolved.  The idea of claims transformation is the most important technical advance in distributed computing for at least a decade.  It is so powerful that it wasn't even fully understood until we began to build things with it.  So how can anyone expect SAML to deal in an optimal way with the issues that ultimately emerged?  This doesn't detract from SAML's successes.  That's not how software engineering works.

WS-Federation will provide new options for people who want to build on the web services architecture, evolving their current web technology in an incremental way to be consistent with that architecture.  To do this, no one will have to throw out their existing SAML deployments.  Many of the SAML producers will include support for WS-Federation so that interconnectivity will be a given.

A lot of WS-Federation editorial work has been done by my friend DES (Don Schmidt).  This guy has paid his dues – triple dues – and works from a deep experience in security.  After some badgering he has just started to blog his ideas.  Here's part of how he explains his goals: 

WS-Federation enables development and deployment of advanced federation services (e.g. Authentication, Authorization, Attribute and Pseudonym Services) as special purpose variations of the WS-Trust STS claim transformation model.  Managing, discovering and accessing such services can be simplified when they are all based on a common processing model and speak the same protocol. Further, reusing an established processing model and protocol can simplify the threat model for implementers and should lead to more robust code.

Customers have indicated that manually configuring federation trusts – particularly exchanging signing keys and specifying service endpoints and access policies – is an onerous process when they have many partners. WS-Federation defines a Federation Metadata format to identify services, including the communication and security policies which must be satisfied for accessing them. This enables much of the configuration to be automated.

Another significant benefit of WS-Federation is improved security through “automated de-provisioning” of external user access. If a Relying Party issues local accounts for external users from its partners, it may not immediately learn when those users have changed responsibilities or been terminated. Such accounts could be misused to obtain unauthorized access. WS-Federation enables a Federated Identity relationship wherein a user can no longer access a partner’s resources as soon as he is unable to obtain a valid security token from his own organization.

Microsoft is actually pretty typical of many other companies in that it will have to support a whole spectrum of deployments reaching from simple, restful apps at one end to transactionally guranteed high security applications at the other.  The ability to support the whole spectrum consistently is the key.

We don't want to build two parallel infrastructures in order to do this.  We don't want to deploy everything twice.  Test everything twice.  Secure everything twice.   Does anyone? 

So we need a technology that takes everything learned while elaborating SAML – plus new features – and allows them to be composed and managed within the WS framework as well as used in conventional web sites. That's what I understand this TC to be about.

It remains a personal hope that those who have been involved with SAML will adopt this larger goal as part of what needs to be achieved.  That really will make convergence possible.

And I also expect everyone to give them credit for all they have done, which will not be lost if WS-Federation continues to gain momentum, but will rather be extended.