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:
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:
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!
PingBack from http://msdnrss.thecoderblogs.com/2007/09/23/the-resource-sts-r-sts-rp-sts-a-sts-the-other-face-of-token-issuing/
Very informative post, tackling some rather common misconceptions.
However, I have two questions:
1) Regarding your statement "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 (...) 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.". This is a old question that I have and that the infocard specs do not address clearly. If I understood you correctly, the STS "crawling" finishes when an STS policy is satisfied by a card, even if that policy points to the metadata of another STS (that is, even if the crawling can continue). I posted a similar question on the infocard forum (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1668019&SiteID=1) and got a different answer: the "crawling" only stops when the issuer is "self" OR the required token is not an issued token OR the IssuedToken assertion does not contain a MEX reference (that is, the crawling is unable to continue). What is the correct behavior? Shouldn't this behavior be clearly stated in the infocard specs?
2) Regarding your statement: "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". I understand you and agree with you. However, the messages presented in the CardSpace UI are misleading. See the following post on the CardSpace forum: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1918142&SiteID=1
A useful, yet sparsely documented feature of Windows CardSpace is its support for resource side Security
Last Friday I announced that the new version of the Biztalk Services SDK introduced support for managed
I am horribly behind schedule with my blog, I still have to post a wrapup of IIW but didn't find the