Govind's WebLog : transport security

WCF Security Modes

govindr — Wed, 07 Feb 2007 08:41:00 GMT

WCF supports three types of Security. They are,

Transport Security
Mixed-Mode Security
Message Security

Let's discuss the various Security Modes below.

Transport Security is applied at the transport byte stream below the message layer. The message does not have a Security header and the message does not carry any user authentication data. It is the least flexible in terms of WS-Security usage and it is highly dependent on the transport. It is the fastest in terms of performance.

Message Security is applied at the message layer and it is transport independent. It is a point to point security model with maximum flexibility in terms of having the message routed over different transports. WS-Security defines different ways to secure a message and the tokens that can be used. Message Security provides the maximum flexibility in terms of that as well. Message Security is slowest in terms of performance.

Mixed-Mode Security is a hybrid between Transport and Message Security. The transport is encrypted and the message contains some user authentication tokens. If the token can provide a key (i.e., it is not a username/password token) then it will sign the timestamp in the security header. If the client token is a Asymmetric token then the 'To' header will be signed as well. It is faster than Message Security.

Federation and Bearer Tokens

govindr — Wed, 22 Nov 2006 14:06:00 GMT

The latest WS-Trust spec (yet to be ratified by OASIS) introduces a concept called Bearer Tokens. This basically is a keyless token that a client requests from an STS (Security Token Service). The only purpose this token serves is to provide more information about the client to the service while the client already has a way to secure its conversation with the service. (Read my other post on Federation for more details on how client uses that key obtained from a STS token.)

This introduces some qurikiness. The obtained issued token can now be added only as a supporting token. In case of transport secured messages this can just be a signed supporting tokens. In messages level security scenarios, this token should be added as a signed encrypted supporting token. Note, the client doesn't have a key so there is no need for the client to prove to the service that it did obtain the token for the STS and it does know some secret information of the token. So just adding the token as signed token in message level security will expose the token for a third party, who can just snoop the token and replay it to the service as if it is the client.

Bearer tokens issued by a STS should be some how verifiale by the service. For this purpose the Bearer token should be signed by the STS. A SAML 1.1, SAML 2.0 or a custom token fits well for this purpose. WCF will require a wsu:Id to be on the issued token to be able to sign it (In message level security case). A SAML 1.1 does not have a wsu:Id on it and its attribute list is not extendable by the schema and hence it is not possible to use SAML 1.1 as bearer tokens in WCF with message level security. The only choices are SAML 2.0 or a custom token that contains a wsu:Id on it.

The cool feature of Bearer tokens in my opinion is that it enables the client to get multiple such tokens from different STS and present all of it to the service. The service might need information from multiple sources to allow or deny permissions for a client and instead of doing multiple round trips the client can present all information to the service at once.

WCF v1 does not support this token type and we might be adding support for this in the future. The idea behind this post is to explain the issues involved in using such tokens and how it plays with message level and transport level security.

Using Binary Encoding in WCF

govindr — Tue, 10 Oct 2006 06:04:00 GMT

I recently had a question from someone on using Binary Encoding and how performance of their application relates to that. My answer was it depends...it depends on what is in your message body and if you are using message security or transport security.

Before talking about binary encoding, the first thing to understand is that it is not a interoperable encoding. If your clients and service are all built with WCF then go ahead and use Binary Encoding. Binary Encoding is great stuff if you are using Message level security. In message security 90% of the SOAP header is security! When you are working with Issued Tokens, like SAML, the size of these headers are even bigger. Using Binary Encoding in these cases really compacts the size of the message by substituting each text element with a equivalent integer. Now, when I say element it is only applicable to the set of know element and attributes in a SOAP message. Like the element name "Envelope", "Header", "EncryptedData", "Signature" will be encoded to a single integer. How well the Body contents will be compacted depends on what is in the contents. If the Body is encrypted, then the contents contain the well known "EncryptedData" element and this will be compacted. If the Body contents is not encrypted then it will appear in plain text. An exception to this rule would be the infrastructure messages like Request Security Token (RST) and Request Security Token Response (RSTR) which are all well-knows elements. If your body contents are not encrypted and have custom serialized objects or Data Sets or XML Documents then you will not see any compaction here. So consider your scenario carefully, check the size of your body to the rest of the SOAP message. The chances are you will see a Performance boost moving to Binary.