Exploring Claims-Based Identity

This column introduces the new identity model in the Microsoft .NET
Framework 3.0... Trust and Federated Identity: WCF and other
communication frameworks use cryptography to ensure that the sender of
a security token is indeed the subject and that the claims in the token
were signed by the issuer named in the token. But all of this fancy
plumbing doesn't have any idea how much you trust the issuer. If you
don't trust him, you're not going to trust the claims he makes about
his subjects! That's why the issuer is always identified when you
receive a claim set, and it's the first thing you should look at when
processing a claim set. It's easy to write code that accepts tokens
from a single trusted issuer. Just make sure the claim set you received
was issued by the one authority you trust, and then you can use those
claims to make security decisions. You've essentially delegated
responsibility to the STS for doing the heavy lifting such as mapping
users onto roles and dealing with different types of security tokens.
Now imagine you wanted to take this one step further. Instead of only
accepting Windows credentials and X.509 certificates, what if your STS
also accepted signed SAML tokens issued by an STS at a trusted partner?
This leads to the realm of federated identity, which is very powerful.
Instead of having to worry about managing user accounts for external
users from partner companies, you can instead accept signed statements
from those partners in the form of SAML tokens... Federated identity
ultimately boils down to claims transformation, if you think about it.
The partner's STS makes the client's life easy by accepting as input
whatever credential is most natural for her, given her operating system
and platform. For example, if the client is running Windows, the STS
could use Kerberos to automatically authenticate her and issue a SAML
token. Another partner company might run a completely different OS that
uses other strong authentication protocols. But the STS at that company
would use those protocols to seamlessly authenticate the user and issue
a SAML token. Meanwhile, the user enjoys the benefits of single-sign on,
even when using applications like yours from federated partner companies.