Building a service with signatures (over timestamps) supported by tokens from an STS turns out to be straightforward –PROVIDED you totally ignore the ws2007federation binding (with its compexity concerning secure sessions, etc).
Much like the examples of signed SOAP messages we say being using in the CRM case, we see the same being used in our own demo API :
an unsigned body is supported by a signed timestamp (and a signed keyinfo); where the keyinfo lets the signature verification process for the header use the referenced token in the signature as support – in the key resolution process for the key that drives the symmetric signature checking.
To make this happen, the setup of server-side bindings and resolvers is relatively straightforward
resolvers for 1) token handlers (a WIFism), 2) cert trust point issuers (another WIFism), and 3) the local cert collection which which to do token decryption.
On the client side, for sue with channels and channels with issued tokens, we see the custom binding automatically formulated by svcutil, as it inspects the metadata of the service and that of ACS (which is our STS)
We see the almost-implied use of symmetric tokens of the ACS, whose proof keys then drive a symmetric signing process for the timestamp header. A full set of binding elements have to be supplied (messages, and https) so the binding is functionally complete.
Note that this binding induces the client to do the signing process, for a SOAP header, essentially.
So WITHOUT adding any kind of protection mode to the contract/method, we have been getting a “signed request” all along – albeit one that didn’t sign the request body! The signed request establishes that the token assertion is properly asserted, by the party to whom it was issued. Moreover, the design of the “issuedTokenOverTransport” method bundles up the process of conforming one’s proof of the right “as an authorized device” to assert that token with SOAP messaging.