Using this kind of messaging will only be effective for the life of the SSL session. Because there's mutual authentication using public key cryptography, there's strong assurance of the identity of both parties, and because of the existence of the SSL session, there's a high degree of confidentiality of the data that is passed. Therefore, any reference to the GUID in the session would only be valid while that SSL session lasts.

Figure 6 shows a UML sequence diagram using our portal scenario, applicable to both trust models discussed - in the trusted client trust model, the SAML issuer is a component of the portal, and in the trusted infrastructure model, the SAML issuer is the SAML-issuing authority trusted by the enterprise.

Looking at Figure 6, once a mutually authenticated SSL session is established, the portal passes the signed SAML Assertion in the header of the WS-Security message to the Enterprise Search Service. It should be noted that the full message doesn't have to be digitally signed, because there's already a high assurance of the identity of the portal achieved in the SSL mutual authentication step. The signature of the SAML assertion, however, would be necessary to convey the non-repudiated assurance of the user's identity. Once the Enterprise Search Service validates the authenticity and trust of the SAML assertion, it caches the SAML assertion locally and assigns it a GUID. The final response to the portal will include the GUID in the SOAP header, which can be used for subsequent SOAP messages corresponding to that same user identity.

It should be noted that Figure 6 also propagates the identity between the Enterprise Search Service and one of the search provider Web Services. Because we didn't establish an SSL connection between the search service and the search provider Web Services in this example, WS-Security SOAP messaging would be used, where the Enterprise Search Service would need to sign the entire message using XML Signature, and would include the original signed assertion from the SAML issuer in the message.

Because of this, there are two message profiles that can be used for propagating identities - one based on a mutually authenticated connection and one based on basic WS-Security SOAP Messaging. The messaging profile for the former is seen in Figure 7.

It's important to note that the proposed model can only occur in an SSL session that's been established - otherwise the GUID returned wouldn't be confidential and identity spoofing could easily happen. Another important note is that for each user there must be a "user session" initiation in the SSL session, where the Web Service must gain explicit and non-repudiated trust of the sender's identity. Once the Web Service can validate that trust, it will return the GUID that can be used for that user.

Because a certain "user session" negotiation must also take place for each user, it's important to weigh this in considering using such a solution. If you don't anticipate a Web Service sending a significant number of messages on behalf of its users, you shouldn't use it. If, however, you're providing a solution where strong security and mutual authentication is needed, and where you believe performance would benefit from long-lived SSL connections between certain nodes in your solution, consider using this model.

Conclusion
This article has presented an approach for complementing Web Service Security solutions with long-lived SSL sessions. As with any approach, it's important not to choose security solutions blindly - much of this will depend on your security requirements and enterprise security policy, and the solution that this article presents is based on foreknowledge of the use of some Web Services in your enterprise. If you have similar security requirements, and if you know ahead of time that certain nodes in your Web Service chain will repeatedly communicate (like the enterprise search example presented here), consider using this model. Long-lived SSL connections between certain nodes in your solution could make a big difference in performance.