A Security Token Service (STS) is a web service that issues security tokens. A security token can be used for encrypting and signing messages, and it can be used to carry information about a user (claims). One common security token in a windows environment is a Kerberos Security Token that carries information about the current windows user. Kerberos tokens are issued by Active Directory (AD) and a STS will typically issue SAML (Security Assertion Markup Language) tokens.
So why would anyone want to use STS? Isn't it enough with for example Kerberos tokens issued by AD? For me there are at least three main reasons why you might want to use a STS.
- The information carried in the Kerberos token (or other token) might not be enough. You might want to have more information about the user. A SAML token can carry a lot more types of information, both standardized and things you define for yourself.
- When we help customers with SOA, it is very common that there aren't only users from AD that will be using the services, but also external customers and partners. In the business services we do not want to handle a lot of different types of security tokens, and instead we can let the STS handle Kerberos tokens, Username tokens, X509 tokens and so on, and it will always issue a SAML token, which is the only thing that the business service will need to handle.
- The last thing is federation scenarios, which is very close to the previous reason.