To host a message-security federation-binding in azure websites we had to turn off the tlsnego and the securesession support (since the azure webvsite concept doesn’t seem to allow hosts offering the WCF pipeline to store the relevant state information).
The result of these feature eliminations from the messaging security protocols is that a client does prepare a layer-7 secured XML request message – to which is attached the SAML assertion received earlier from an STS. Session-based keying and symmetric-encryption is not used, however – by the client or the server. There being no shared state, only derived (vs shared/ephemeral) keying might be exploited within a single, multi-party message. The server processing each message must perform a full public key operation to handle proof keys borne within the accompanying saml assertion; and then verify message header signatures using key derived from the proof key service.
Furthermore, the WSDL metadata of the service MUST expose the layer 7 server cert of the service (the so-called service cert). A (typically static) service reference at the client picks up the resulting identity claim (a certificate) from the endpoint’s description. This is then stored in the service model’s client endpoint to support client-side delivery of a saml-based proof service for messages.
We also had to activate our service component using a custom service host factory. This enabled us to insert a service certificate into the relevant credentials behavior, since we could not reference any certificate in a trust store. We loaded our keying material and certificate from a .pfx file stored in the file system of the website, whose decryption-password we stored in the service’s code.
Trying to use state-maintaining features manifested as “gateway errors”. The clue that we MIGHT turn off these features came from observing the wire protocol. TLSNego is basically a ssl handshake with two round trips (with message borne in ws-trust message rather than the SSL record layer protocol). We found the gateway error only occurred on the second roundtrip, which suggested that environment issues were preventing “handling” of the final result. While its possible that the host set denies access to the SSL crypto provider (that computes SSL derived keys), its more likely that the kernel of the VMs simply has no support for sharing the session state – enforcing stateless load balancing and in general “tuning up” the web security for web-style APIs (vs. other API base don theo other tunings of the protocols that target thick clients making RPC calls).
Peter's ruminations 