Friday, June 09, 2006

WS-?????

Quite a few standards exist that are used in the SOA arena. Here is a brief summary of the most common and pervasive.

Security with WS-Security
Security can be grouped into 3 types, MLS (Message level security), TLS (Transport level security) and Mixed.

MLS refers to when the message itself is secure. Real world example would be a document in a FedEx envelope that is sealed. TLS refers to making the transport secure, so perhaps the FedEx truck is locked, but if I was to get inside the truck, I could find and potentially read the document.

MLS usually involves data integrity, aka, how do we know the letter was not altered and data confidentiality, how do we know the data is not readable by unauthorized readers.

For the later we utilize encryption xml-Enc whereas for the former we using xml-DSig or digital signatures. Digital signatures are when you create a message digest, or a hash of the content you choose to sign and then encrypt this hash with a shared secret key.

To verify integrity, the reader can create the same hash, encrypt with the shared secret and then compare the signatures. If they don't match the message was tampered.

TLS is the common network security, either using HTTP with SSL or using HTTP authentication protocols, basic etc. TLS is generally faster since we don't have the computing overhead of signing the messages, but are not as secure as MLS especially in multi-hop and/or routing scenarios. (TLS only establishes a node-2-node secure channel).

Mixed is when we use a combination of both, so encrypted document inside a secure transport. Many developers choose to use a home-grown authentication scheme (Custom SOAP Headers) in conjunction with TLS.

Distributed transactions with WS-C(AT) or WS-C(BA)
Transactions are defined by the WS-Coordination and Atomic Transactions (AT)or Business Activity (BA). WS-Coordination defines how we enlist in a transaction and acts as the coordinator.

The AT or BA component defines whether we have a ATOMIC transaction so we "block" all participants until we have a ALL PASS, or BA when we have long running transaction and the "blocking" scenario wont work. With BA we opt for a compensation model.

In these cases, we assume success but provide a compensation mechanism so if we do need to roll back, we can manually do so if notified by the coordinator.

More on Reliable Messaging in my next post...

No comments: