Nielsen's Weblog

WWF

Wed, 09 Apr 2008 17:32:02 GMT

Just back from Vietnam yesterday, jetlag... darn tired. Next week I am taking some time off, going to London on a small vacation...so what's up in London ?

Essential Windows Workflo w Foundation

what else is there to do in London ?

:-D

IncomingMessageHeaders

Wed, 23 Jan 2008 12:39:41 GMT

The project we're working on currently is using ServiceAuthorizationManager for authorizing incoming request.

The current implementation is expecting the RequestMessage.Headers.Action field to contain the incoming soap action. Here is the catch, if you have a method that is decorated with IsOneWay=true, then guess what the RequestContext is null!...

This makes sense as one way calls is not the usual request/response pattern, but it sure did break our implementation :).

So a quick fix would be to look at the IncomingMessageHeaders instead like this:

for (int i = 0; i < operationContext.IncomingMessageHeaders.Count; ++i)

{

MessageHeaderInfo h = operationContext.IncomingMessageHeaders[i];

if (h.Name == "Action")

{

XmlReader xr = operationContext.IncomingMessageHeaders.GetReaderAtHeader(i);

action = xr.ReadElementContentAsString();

BTW. Happy new year!, we spend the holidays in New York. We stayed at the Hilton Millenium on 54^th floor. Amazing view, we had the governor suite (I think it was called that way). On my right side we could see the Brooklyn bridge, strait out the window we could see the Empire State Building (upper Manhattan) and on our left side we had the Statue of Liberty and of course Ground Zero.

Okay I don't get it, what fun is it standing on Times Square from 13.00 to 23.59 waiting for a ball drop ?!? J. Well glad I was watching this from my room instead J. We're definitely going to visit New York again.

Start spreading the news I'm leaving today … .

UserNamePasswordClientCredential

Sat, 22 Sep 2007 08:41:57 GMT

Say you are doing a banking SmartClient application, people finally got tired of phissing and "fat" clients is the answer here.

Now my SmartClient uses WCF (duh) as the communication infrastructure between the end user and the bank. The end user is presented with the usual login box + some extra security id RSA key she must enter.

The credentials is then stored in memory and each time I call out to my WCF proxy I pass in those credentials + the extra rsa custom token. I am holding on to the username token in memory using SecureString of course.

So here is my concern, say I am holding on to my session aware channelfactory for many reasons, performance amongst other things. Obviously I have to set the Username and Password on the channel, fine but the UserNamePasswordClientCredential class uses string to hold my identity!! WTF. Great eh, out goes the SecureString idea.

We're not talking about securing the token when it crosses the wire, that part is secured, but I am talking about the fact that my password and username is visible to prying eyes in memory, the second I set my credentials on the channelfactory.

Might not be a big deal, but why not use SecureString on the UserNamePasswordClientCredential in the first place!.

I might be missing the obvious reason as why UserNamePasswordClientCredential is designed like this, comments are welcome here.

Btw: a possible implementation of the cached identity could be written like this (given the fact that UserNamePasswordClientCredential uses System.String ;-)).

public sealed class CacheClientCredentials

{

private static SecureString usr = new SecureString();

private static SecureString pwd= new SecureString();

public static string UserName

{

get { return SecureStringToString(usr); }

set

{

char[] chars = value.ToCharArray();

foreach (char c in chars)

usr.AppendChar(c);

usr.MakeReadOnly();

}

public static string Password

{

get { return SecureStringToString(pwd); }

set

{

char[] chars = value.ToCharArray();

foreach (char c in chars)

pwd.AppendChar(c);

pwd.MakeReadOnly();

}

private static string SecureStringToString(SecureString value)

{

IntPtr bstr = Marshal.SecureStringToBSTR(value);

try

{

return Marshal.PtrToStringBSTR(bstr);

}

finally

{

Marshal.FreeBSTR(bstr);

}

The average, healthy, well-adjusted adult gets up at seven-thirty in the morning feeling just plain terrible.
-- Jean Kerr

SecurityAccessDeniedException

Wed, 19 Sep 2007 14:43:54 GMT

Sigh, it's the client proxy that throws the exception.

We have setup the usual universal error handler implementing the IErrorHandler interface, all good I figured.

The ProvideFault implementation is strait forward, if any exception occurs, wrap it up in a FaultException and return that to the client. I believed that this was it, no faulted channels on my shift and client was happy.

The problem we ran into was the implementation of the ProvideFault. The symptoms was that, when ever a SecurityAccessDeniedException was thrown, the client would catch that exception and show a localized message to the enduser, except the client never got the SecurityAccessDeniedException, it got an untyped FaultException!.

The reason why is actually obvious, if the exception thrown by the service is already an exception derived from the CommunicationException aka a FaultException, the ProvideFault should of course not wrap that fault up into yet another FaultException, it should simply just return from the ProvideFault and let the faultexception travel.

So the implementation must have the following check:

public void ProvideFault(Exception error, System.ServiceModel.Channels.MessageVersion version, ref System.ServiceModel.Channels.Message fault)

{

if (error is FaultException)

return;

this way the faultexception is propagated to the client proxy and then the client proxy will turn the FaultException into the SecurityAccessDeniedException and then re throw it.

My theory is that all of Scottish cuisine is based on a dare.
-- Mike Myers

Custom binding

Sat, 15 Sep 2007 19:38:38 GMT

Back from Vietnam. I survived the first 6 days without any stomach trouble, but then oh boy... for another 5 consecutive days I was in deep shit sort of speak. Long live Coca Cola!.

Okay we ran into the TimeStampHasCreationTimeInFuture, cool. Now it's not possible to extend the default bindings with the maxClockSkew setting, so you have to resort to custom bindings.

We are using basicHttpBinding for maximum interoperability, so creating a similar custom binding given this default binding here:

</security>

</binding>

</basicHttpBinding>

is strait forward converting this into a custom binding like this:

</security>

</binding>

</customBinding>

First you apply the security element which enables you to set the maxClockSkew values.

MaxClockSkew has a default value of 5 minutes and using svcutil to generate the client config, it stays that way ;-), correct svcutil does not pick up the server side values so you would have to set them manually afterwards.

Next we setup the mandatory encoding element and the soap version, in our case we use text encoding and soap 1.1 for maximum interoperability with external clients.

We finish our custom binding with specifying the mandatory transport element, which in our case is HTTPS securing a username token.

Off topic:

Say you're not concerned about interoperability but instead are picking a battles with the paranoid it-guys responsible for the all the firewalls in the company. These guys tends to lock down every port but port 80, 443. <rant>They even close port 1433 behind firewalls forcing us to write "rpc" services! don't get me started. ;-)</rant>

In situations like that I would recommend using a custom binding also but with a binary encoding instead.

For example given the above bindings you could build your custom binding exactly the same way but with a binary message encoding instead.

</security>

</binding>

</customBinding>

Performance is optimal with the binary encoder and you keep the it-guys happy.

"As long as you're going to be thinking anyway, THINK BIG."

- Donald Trump