The Resource STS: R-STS, RP-STS, A-STS… the other face of token issuing

In short: I talk a bit about the idea of resource STS, and I give the ropes of the messages exchanged for engaging it.

 

When you get introduced to the Identity Metasystem, one of the first things you hear about is the role subdivision it proposes: subjects, relying parties and identity providers. The next step is usually showing you a diagram, where those roles are played by some concrete element: the relying party is the website of a wine seller, the identity provider is represented by the STS of the department of driving licenses, and the subject is they typical faceless guy of the MSDN clipart who proudly brandishes a browser as a shield. Then we go through the classic fable of the faceless guy who for some reason is always craving alcohol in a country where there is a drinking age, and the happy handing is always the department of driving license sending back a token containing a claim that certifies to the relying party that the guy is in his legal right of getting a good glass of Chianti (the problem of actually drinking it without a mouth has to be solved out of band). Below there’s an example (in Japanese, just for adding some variety :-)).

Now, our reductionism (yes, it’s starting to affect me as well) may suggest you a couple of generalizations that are actually not entirely true:

• An STS is an Identity Provider. Nope. Saying that STS and IP are interchangeable terms is a bit like saying that you are a browser. In fact, the browser is the tool that you use for expressing your role of subject in a computer based system: but YOU are the subject. Similarly, the STS is one of the many tools that an Identity Provider has to use for performing in its role; but in fact the identity provider is a “business entity”, far more abstract. The STS is super important, because it offers the addressable endpoint through which I can interact with the IP via the negotiation & encapsulation protocol, it is from where I can get the certificate that asserts the IP identity in a cryptographically strong way; but the identity provider is more than that, it is the set of identities it knows about, its reputation, its capability of issuing cards (which are NOT tokens, even if they are signed), etcetera.


• Every STS does the bidding of an Identity Provider. Again, nope. The fact that you handle a pair of scissors does not implies that you are an hairdresser, you may be a tailor or a decoupage expert or the person that mutilated my mane a couple weeks ago. If you started your journey in the token based authentication via the Metasystem you may have gotten that impression, since the samples of the Subject-IP-RP tripod usually have room only for the STS at the IP. If you are familiar with WS-Federation, you already know that the RP may accept only tokens coming from their own STS, which would act more as a claim transformer than a pure IP. Oh wait, but can’t you tell that this last STS IS an IP but generates tokens depicting some visual shadow account? And WS-Federation talks about resource IP/STS? See, it’s complicated. The least controversial way of making the point [STS!=>IP] is referring to the concept of Authorization STS. Sometimes the RP will accept only tokens from a special kind of STS, the authorization STS, which will apply authoriZation logic to incoming claims and will give to the RPs a new, predigested token containing only the result of the authoriZation decisions (example: if the incoming token contained the claim Age, the new token will contain the claim CanDrink). You could write on that token “No identities has been harmed for the filming..hem… issuing of this token”. For closing on this:I am sure that people with a brain bigger than mine can see the differences between resource STS, resource IP/STS, authorization STS and the like; however for the purposes of the conversations I usually have, I can get away shoving all of them in a single category that I call “resource STS” and that contains all the STSes issuing tokens as the result of an RST secured by another issued token (as opposed to primary credentials). Hopefully all this will be much clearer after seeing the diagram below.

Well, I’ve stolen my own thunder while nailing home the point [STS!=>IP]; however let’s explore a bit more this concept of resource STS.

In the bartender-checks-id-and-gives-me-beer case, the authority that issued my ID is a direct relationship both with me (it issued me the ID) and the bartender (he trusts it). There can be situations in which things require a further step. Some time ago in Italy most Disco clubs adopted the drink card method: when you entered the club you had to show your ID, and you got back a paper “drinking card”. That drinking card would be waved to cloak services & bartenders, and punched accordingly (with decreasing prices for every further shot). Failure to show the card would result into the payment of the maximum possible amount (ie like if you would have punched the entire thing end to end). The card was mainly a way of keeping track of your bill, sure, but also a way of verifying that you entered the place through the proper channels (ie the entrance as opposed to a window). If you were caught roaming the dance floor without the drinking card, showing your driving licence would not have done you any good: only the tokens issued there were recognized by the staff.

I have to admit that I had to strain a bit for finding an example of cascading tokens in the pure consumer space, that is to say a scenario in which the subject doe not have a strong affiliation that comes into play. If I relax that constraint, I can literally flood you with examples in which cascading STSes (one that knows about the identity, one that knows about the resource); all partnerships and federations can work like that, since establishing trust between 2 STSes is enormously more handy than extending the range of things that the RP can swallow directly. There’s a huge amount of literature on federation, and I won’t repeat it here. My point was showing that the idea of resource STS can be generalized and can come in handy also in less traditional scenarios (note: I know that the ID->drinkingcard->drink schema can be modeled as a classic federation scenario too, but I don’t think it would be a useful way of attacking the problem since the relationship between government and commercial activities is so pervasive, unidirectional and invariant that it does not add much info).

Let’s see if I can squeeze some ROI from my new X61 tablet and sketch some of my signature schemas. If we add CardSpace to the picture, we can make some interesting considerations. First of all, the above works perfectly well with CardSpace as well. If a relying party wants to get a token from a resource STS, all it has to do is adding the element IssuerPolicy to the object tag. IssuerPolicy will contain the URI of the mex endpoint of the resource STS of choice (whose address will be in the element “Issuer”, as usual). In the diagram below the first step is retrieving the policy of the RP, which actually contain a reference to the STS http://entrance/STS and its metadata endpoint https://entrance/STS/mex.

 

 

When the selector encounters such an element, it will fetch (via WS-MetadataExchange) the policy of the resource STS. If that policy happen to be satisfied by one or more cards (read: token obtained by using a card) owned by the user, the identity selector will pop up with the suitable coloring schema. If it doesn’t, but the resource STS policy requires a token from yet another STS, the selector will crawl further and examine the metadata of the new STS. The process continues until the selector finds an STS that can be invoked using one of the managed cards owned by the user, or it reaches an STS that requires a non-issued token for which the user has no corresponding cards (in which case, the selector will come out anyway with all the cards grayed out and announcing that you don’t have anything suitable at the moment).

Assuming that the first resource STS accepts tokens from an STS for which we have a managed card for: if the user will use the corresponding managed card, the selector will take care of automatically traverse the chain of RST/RSTR and invoke the RP with the right token (that is to say the one obtained from the resource STS itself). Step by step:

The diagram below shows fetching the policy from the resource STS (which requires a token from http://gov/STS containing the claim Age) and highlighting the corresponding card.

Then the user selects the highlighted card; the selector invokes the IP STS and obtains the corresponding token.

Once obtained the token from http://gov/STS, the selector uses it for securing the RTS for http://entrance/STS and obtain a token compliant with the requirements of the RP:

The chain can now be closed. The token obtained from http://entrance/STS will be used for securing the call to the RP, which will comply to the authorization directives in it and serve the drink. It may seem all very convoluted, but in fact the user does not really see any of this… it’s just a matter of clicking, choosing a card and wait for the call to succeed. Everything is done behind the scenes, the subject doesn’t see any difference with the case in which the token from the IP STS is used directly with the Resource (unless the resource STS is performing poorly, in which case the wait time may increase (and short tempered subjects may complain:-)).

 

This system is very neat, and has the advantage over classic federation that the subject has actually the control on which persona will be used to start the chain. If your company has a relationship with an hardware vendor, let’s say Dell, when you navigate to their website from your intranet chances are that you’ll be recognized as a partner and brought to special pages with discounts. But what if you are the son of a Dell employee, and that entitles you to even bigger discounts? With classic federation your identity of employee would be implicitly used, with cardspace you’d have a choice of what hat you want to wear. If you want to dig deeper on this, check out the post about user centered federation (don’t forget the coffee).

There are at least a couple of important points to make:

• When there is more than an STS between you and the RP, what you see in the selector are NOT the claims that the RP is requesting. What you see are the claims that the one STS before the last in chain is asking for issuing a token. In the bartender authorization example, you would see in the selector that you are being asked for the claim Age while the bartender will actually consume the claim CanDrink; you see the Age claim because this is what the resource STS is asking from your STS so that it can transform it in the CanDrink one. What’s going on here? Are we limiting the control that the user exercise on the information he sends. Not really. Consider this: the claims you send contain a fixed amount of information, and unless you inject further material the amount of information can only decrease at every step (Age==35 has more info than CanDrink==true, since it collapses all the Age==[>21] cases). Information could be injected if somebody in the chain would add some: but if somebody in the chain would know about you, you would probably have a card representing that relationship and the crawling chain would have ended here instead of going further. Not exactly a theorem, since there are many things that can happen out of band, but hopefully that should reassure you that due diligence has been done


• When there is more than an STS between you and the RP, you don’t know who will be called and with what data. That’s the meaning of the expression “and its agents” in the UI. Again, that should not be a problem: there is an uninterrupted chain of trust that bonds every STS in the sequence, and we already talked in the bullet above about our little version of the Shannon theories. That’s just important for connectivity reasons: if your network whitelists the websites you can contact, some of the steps in the chain may fail because you cannot place the RST call.

Well, that’s pretty much it. It was MONTHS that a half finished version of this post was sitting on my Live Writer buffer, and I am happy I finally managed to push it out. If you have questions, as usual… I’m here!