Active, Passive and Passive-Aggressive

Ahh, terminology: joy and sorrow of our kind. There are some expressions that are very catchy and we use all the time, but that do not always serve well the purpose of communicating our thoughts. Take the usage of “passive” in the context of identity management; we tend to use it every time a web browser is in the picture, but that can be extremely confusing: if you just mean “I am talking about a web app” but you audience understands “he is going to use WS-Federation”, you can be sure that things will get messy pretty quickly. In fact when I use CardSpace with a web app I am riding a passive client, but I obtain my token via proper WS-Trust traffic (thanks to our friendly identity selector) and I shove it directly in the first POST I send, without following the gracious redirect dance that WS-Federation would require. That’s what I like to jokingly call passive-aggressive 🙂 For the ones among you that are not super familiar with this space, after the pic I restate the same but with extra context.

 

Almost 5 years ago we published WS-Federation 1.0. To quote Don, THE authority on the topic:

WS-Federation extends WS-Trust to provide a flexible federated identity architecture with clean separation between trust mechanisms, security token formats, and the protocol for obtaining tokens. This architecture enables a reusable token service model and protocol to address the identity requirements of both web applications and web services in a variety of trust relationships.

Trivializing a bit the beauty of the above: WS-Trust and other specs are building block which provide protocol “primitives”. WS-Federation gives a script in which some of those primitives are composed in certain sequences for obtaining higher level outcomes such as sign-in, sign-out, the works.

The original spec described how to make the magic of federation happen according to the capabilities of your client (the “requestor”). Grossly speaking, clients were classified according to their ability of producing SOAP messages:

• Web clients (especially browsers), while notoriously good HTTP jockeys, are unable to emit proper SOAP hence got the label “Passive Requestor”, or colloquially just passive. Example in the example: the terminology used for passive in the spec, “Web requestors such as Web browsers that cannot directly make Web Service requests“, would not work in today’s REST-aware world in which the definition of web services “evolved” to include non-enveloped, raw HTTP style calls
  
• Anything able to produce proper SOAP got the label “Active Requestor”

The lack of SOAP capabilities forced some creative solution for “emulating” WS-Trust on top of GET, POST and cookies: the result is the above mentioned dance of redirects, where the browser goes back & forth between previously established addresses on the resource and requestor domains and using cookies for communicating authentication information. THIS is what is meant by passive federation.

This was guidance that was greatly appreciated by implementers, since often in this space “creative solution” is spelled “underspecified,hence won’t interoperate”: having a spec giving prescriptive guidance for the web client proved to be of great value. Things went in a different way for the active case: if you are able to use SOAP directly, you can pretty much use whatever combination you need for obtaining your purpose and you’ll end up in a consistent “state”; hence there was much less need to define higher order protocols. As a result, in the most recent incarnations of WS-Federation the subdivision between active and passive is dropped: the focus is on the web (passive) case, and the assumption is that the active can take care of itself egregiously by handling WS-Trust directly. So: today, when you talk about WS-Federation you are referring to the redirect dance mentioned above, which is the evolution of the old passive requestor federation case. Since habits are hard to die, people may also refer to it as “the passive case” or simply “passive”. The active case covers all the scenarios addressed directly via WS-Trust.

Now that we clarified the etymology of the terms “passive” and “active” in this context, let’s move to our attention to CardSpace. Let’s say that you are the happy owner of a web site in which the sing-in operation requires your customers to use a managed card. You interact with the web site with a web browser, the quintessential passive client; but there’s very little passivity in the way in which the token flows around.

1. the RP policy is acquired dynamically by the caller, and may not be prescriptive about which issuer is meant to produce the token we want (it may be just the expected format and a bunch of claim types)


2. Once the user picks a card (quite literally), the identity selector communicated with the intended STS using oh so very active soapy WS-Trust


3. When the browser receives the token from the identity selector, typically it hurls it toward the RP in a POST.

Yes, it is very passive of the browser to just attach the token http request and not using it for signing or encrypting anything; but that’s the only element in the entire sequence, and it differs from the cookie+artifact mechanism from the proper passive case anyway. Furthermore: one leg of the sequence is clearly active, and the entire schema happens in a single postback instead of redirecting around in search of the right authorities.

In essence, the point is: if you are thinking about using CardSpace within a browser, as opposed to with a web service, beware of calling it a passive scenario or you may confuse your buddies. Perhaps passive-aggressive? 😉

I know that the most informed among you will think “but Vittorio, why the long post? The last sentence would have gotten the job done”. Well, I can assure you that I tried that in person with various people but very rarely succeeded, which is why I wrote this post instead of doing real work on my inbox 🙂