When all you have is an STS, everything looks like a...

What is a reasonable use of a Security Token Service (STS)? Standards are very useful and powerful tools in enterprise architecture, but they have to be used to solve the right problems. WS-Trust, the standard that STS relies on is very flexible. Basically, you request a token and get at token back - you have a UsernameToken (username + password) and you get a SAML Assertion back.

So, this is useful when crossing security domains in federated models. For example, you need to call a 3rd party web-service and it requires a SAML assertion - call the STS, get the SAML Assertion and send it to the service. Simple enough. We can agree that for this type of use case, most web services clients can just generate the SAML assertion themselves, and sign the request - SAML sender-vouches. If the SAML assertion itself has to be signed then this can create complexity - requiring each service to have the private key of the issuer - so maybe, depending on the number of client applications that are required to federate, having a central service like an STS is preferred to having each client generate the SAML.

Another common use case for the STS generating a SAML assertion is attributued based authorization. The STS generates a SAML assertion containing the attributes required to access the service. This sounds good in practice, but how does the STS know what attributes are required? Are they published in the WSDL? Assuming that there was a standard way to do this, would services advertise what attributes are required to gain access? Not likely.

Instead, as in most federations, there needs to be some prior arrangement made between the service producer and consumer - you'll send me a SAML Assertion like this with these attributes. This means that the STS has to manage all of the meta-data for all of the partners. Is this practical? It might make more sense to just generate a SAML assertion with no attributes, and then have the service call-back to the "issuer" for more attributes as needed. The SAML protocol - SAML Attribute Query, with out WS-Trust or an STS, can be used to expose additional information to relying parties. There are definately scenarios where the relying party is not authorized to callback to the asserting domain, so in that case it might make sense to have the SAML Assertion contain a fixed set of common attributes. This generation could also be simplified by an STS.

As to not be accused of being an STS "hater", here's a scenario I've come across for a POC I'm working on that I actually like for an STS. In an online banking scenario, how the user authenticates (business card + PIN or personal card +PIN) determines which accounts they have access. Make a call to the STS - authenticate the user, and based on which authentication method they used, filter the accounts they access. Return the list of accounts in the SAML assertion. Use the accounts contained in the SAML assertion for personalization - I would also go to the system of record you authorizing transactions.

I guess the point is that WS-Trust/STS solves some good use cases, but it is not the only or best solution - neither is SAML or even WS-Security for that matter. In selecting standards for a project or an organization, consider the likely use cases and understand that simpler is almost always better.