A useful, yet sparsely documented feature of Windows CardSpace is its support for resource side Security Token Services (STSs) – STSs that are used by relying parties rather than Identity Providers. Vittorio has done an excellent job helping to provide detail on this subject , and I highly recommend people interested in understanding more about what resource STSs are and why they are useful, read his post. In this post I want to fill out some of the technical details. That said, I'll start with a short introduction to the subject with an example I’ve found particularly helpful. The canonical CardSpace scenario has a relying party (RP), usually a website, which requires a token from an identity provider (IP). The user selects a card in CardSpace. CardSpace then requests a token from the corresponding identity provider. A token is returned to the CardSpace client, which then sends it to the relying party. Figure 1 shows the RP site, and the IP STS the RP has a relationship with. In the following figures, the line connecting IPs and RPs indicates where explicit relationships exist. Figure 1 Now, part of the flexibility of CardSpace and the Identity Metasystem , is that it is trivial for an RP to set up new relationships with multiple IPs, as shown in figure 2. Figure 2 What’s interesting about the case with one RP and multiple IP’s is that the RP site maintains the logic about how to authenticate the various IPs, and potentially has logic to understand the
Read More...