Anders,

There are two parties participating in a security scenario, the server and
the client. Let me give you a simple example for HTTP parlor. I'll then
follow up with WebServices specifics.

When you use HTTPS (SSL) in a webserver, you're using a server certificate
and whenever a client connects to that webserver he's in fact validating the
server is who he says he is by following the certificate chain of the server
certificate. The webserver is in fact presenting the client with the public
key allowing the client to send information encrypte with that public key
which only the webserver can decrypt with its private key.

When/If the client uses a client certificate, he'll be authenticating
himself to the server, and the server will use the same methodology to
validate the credentials. He'll then authorize the client the way it sees
fit.

Now, all this HTTP talk mentioned a single security token supported by the
HTTP protocol - X.509 certificates. HTTP supports other authentication
modes, like Negotiate (SPNEGO/NTLM), NTLM, Digest and Basic Authentication.

WebServices present us with a richer protocol able to handle multiple
security tokens, the ability to use multiple security tokens in a single
message and the ability the secure different parts of the message with
different security tokens for different recipients. The security tokens
supported are - Username Token (similar to Basic Auth), Kerberos Token
(similar to SPNEGO), X.509 (similar to certificates) and SAML.

When you create a WebService you define the binding (basicHttpBinding,
wsHttpBinding, netTcpBinding, NamedPipeBinding, others ...). All these
bindings support the latest WS standards (except basicHttpBinding which
supports only some of the standards) and allow you to specify the security
settings of your choosing.

When selecting security settings you must choose how the server will
authenticate to client and how the client authenticates to the server. Only
some combinations are possible, ex:
client (Username) + server (X.509)
client (X.509) + server (X.509)
client (Kerberos or Windows) + server (Kerberos or Windows)
(more)

You also have the option of choosing where (with constraints) the security
tokens are set, the message (SOAP) or the transport protocol (HTTP/TCP.IP)

SAML is a different beast, where you have 3 participants. The client
contacts an STS (issuer) to get a SAML authenicating himself with any
combination of the above, and presents the SAML to the server on every
operation allowing the client to present himself in a uniform way to any
server able to validate the SAML.

Anyway, I think you already have a lot to chew on.
You can browse examples of the WebService security scenarios here:
http://msdn2.microsoft.com/en-us/library/ms730301.aspx

Finally, choosing your security settings can be (almost) independent of the
chosen binding. That is one of the beauties of WS-* :)

By the way, with Windows (Kerberos) on both sides (client and server) the
communication is already encrypted and signed because Kerberos already makes
use of session keys/tickets.

hope it helps
Tiago Halm