Do we absolutely need a STS for SAML?
I am trying to implement SAML enabled SOAP services for the first time and I have some conceptual questions regarding the role of a Secure Token Service (STS) in a SAML implementation.
User ---> Web Application ---SOAP/SAML--> Messaging Application
Basically the scenario is that the user logs into the Web application using his user name and password, web application in turn authenticate and authorize the user with an external service, on successful authentication/authorization, Web application creates a Sender Vouches SAML assertion with user as subject, signs the assertion with its private key, packages the assertion in a soap envelope using WS-S and makes a SOAP call to the messaging application. Once messaging application receive the request, it verifies the signature with the public key of the web application, pull the authentication and attribute statements out of the SAML assertion and based on them enforce auth policy on the end point.
As you can see in the above scenario there was no external STS involved however most literature I have read on SAML suggest that an STS is absolutely required. The question I have is that am I doing anything wrong with the above scenario since I cannot see any reason why I would absolutely need an STS. Sure it would be nice to have a STS but at least in my opinion, absence of it does not stop me from implementing SAML for my use case.
Answer
No, you don't need an STS for SAML tokens in web services. The STS exchanges one token (where 'token' includes things like username+password) for another, so it's useful in that your web service consumer can send some input token (typically username+password or a signature+X.509 cert for simple use cases) to the STS and get back a SAML assertion all ready to go.
Now, if you have the capability to create SAML tokens that will be accepted by your web service provider, have at it! No STS necessary - the actual SOAP message on the wire is identical whether or not an STS was involved in its creation.
I wrote a couple of blog entries a few years ago that detail some of this:
Access Manager 7.1 Beta in Java EE Tools/NetBeans 5.5 Enterprise Pack
Anatomy of a SAML-Secured SOAP Message
Sun Access Manager 7.1 has been superseded by OpenAM, but the principles remain the same. In particular, the second entry is independent of any actual product.