Musings from Gudge

Windows Workflow/Rules Designer Re-hosting

martin-gudgin — Thu, 13 Mar 2008 14:05:00 GMT

The design surface of the shipping Windows Workflow Designer can be re-hosted in applications other than Visual Studio. The team that owns building the vNext designer is looking for input around re-hosting scenarios. If you have an interest in this feature, you can help shape its future by filling out this survey, on or before March 19.

Update

martin-gudgin — Tue, 20 Nov 2007 08:10:00 GMT

Given that my grand-boss has exhorted me to update this page, I thought I'd better do something...

I've been working with all the folks Doug mentions since I re-located to Washington state from the UK, in August last year. I love working on this team, it's dynamic, exciting, there's plenty of variety, the people on the team are really smart (I'm learning lots) and the one month milestone approach really works well.

I've personally been doing a lot of work with XAML over the last 6-8 months (which I think is OK to mention) and will likely be working with XAML for the first half of 2008 too. I'll try to come up with some XAML related posts sometime soon.

Indigo STS Implementation

martin-gudgin — Mon, 19 Jun 2006 13:20:00 GMT

A couple of folks were giving talks at TechEd this week and used a little Security Token Service (STS) prototype I'd put together. I'm posting a version here so that folks can download it and play with it at their leisure. Any suggestions for improvements, new features, bug reports, post a comment.

Thanks to Tomek for posting the file. I was too inept to be able to figure out how to upload using winscp…

BTW - You'll need a fairly recent build of Indigo to compile and run this code.

Crypto Rap!!!

martin-gudgin — Tue, 23 May 2006 17:46:00 GMT

One of the devs on my team pointed me at this…

Priceless!

httpcfg Flag Weirdness

martin-gudgin — Tue, 16 May 2006 04:18:00 GMT

A while back, I wrote a couple of entries on httpcfg and using it to configure certificates when self-hosting Indigo services. The second entry talked about the various flags that could be passed using the -f parameter.

Unfortunately, I neglected to mention that you can't actually use the syntax with preceding 0x and zeros, despite the fact that the usage help you get from just typing httpcfg at the command line would lead you to believe that such syntax would work just fine.

It turns out you actually need to specify the values as straight decimal numbers, like this;

httpcfg <otheroptions> -f 1 (Gives you cert mapping to windows accounts)

httpcfg <otheroptions> -f 2 (Gives you client cert support)

httpcfg <otheroptions> -f 3 (Gives you both client cert support and mapping to windows accounts)

httpcfg <otheroptions> -f 4 (Turns off ISAPI routing)

httpcfg <otheroptions> -f 5 (Turns off ISAPI routing and gives you cert mapping to windows accounts)

httpcfg <otheroptions> -f 6 (Turns off ISAPI routing and gives you client cert support)

httpcfg <otheroptions> -f 7 (Turns off ISAPI routing and gives you both client cert support and mapping to windows accounts)

So if you want to use client certs you need -f 2 on the command line ( and NOT -f 0x00000002 )

More on Service Factory

martin-gudgin — Tue, 18 Apr 2006 16:45:00 GMT

Jason has an entry giving more details on the Service Factory.

Service Factory Open For Business

martin-gudgin — Tue, 18 Apr 2006 16:30:00 GMT

My friends and colleagues Jason Hogg and Don Smith, along with some other smart folk have recently opened up the Service Factory over on GotDotNet. They have a some cool Visual Studio 2005 tooling that provides guidance around building and securing web services. Their latest drops have WCF support. Go check it out!

WSE 3.0 Ships

martin-gudgin — Tue, 08 Nov 2005 13:26:00 GMT

WSE 3.0 has shipped. Hurrah! And congratulations to the team.

Will the real Steve Swartz please stand up…

martin-gudgin — Thu, 20 Oct 2005 08:13:00 GMT

I seem to remember Steve Swartz had a blog here at PluralSight for a while, but the content was somewhat, well, lacking ( and now gone ). I've recently found out why. The blog Steve devotes his time to is actually here.

Doug Walter is in the house!

martin-gudgin — Wed, 28 Sep 2005 23:42:00 GMT

My friend and colleague Doug Walter now has a blog on this esteemed site.

Doug is the lead development lead on the Indigo security team and I've had the pleasure of working with him on a bunch of things, including WS-SecurityPolicy and our claims-based authorization story in Indigo, over the past year or so.

I'm fairly sure that Doug and I will both be posting entries related to authorization over the next few weeks. It promises to be an interesting ride, so hop aboard!

wsu:Timestamp, first or last?

martin-gudgin — Sat, 10 Sep 2005 02:33:00 GMT

There seem to be two schools of thought as to where the best place is for the wsu:Timestamp element in the wsse:Security header. One approach is to put the timestamp at the end of the header;

<wsse:Security>
<wsse:BinarySecurityToken … >
…
</wsse:BinarySecurityToken>
<ds:Signature>
…
</ds:Signature>
<wsu:Timestamp>

<wsu:Created …>2005-09-08T10:05:27Z</wsu:Created>
</wsu:Timestamp>
</wsse:Security>

the other approach is to put the timestamp at the beginning;

<wsse:Security>
<wsu:Timestamp>

<wsu:Created …>2005-09-08T10:06:15Z</wsu:Created>
</wsu:Timestamp>
<wsse:BinarySecurityToken … >
…
</wsse:BinarySecurityToken>
<ds:Signature>
…
</ds:Signature>
</wsse:Security>

So which approach is best? Processing the timestamp in a security header usually involves checking message freshness. In other words, has the message arrived at its destination within a reasonable time period. Let's for the sake of argument assume that the message must be less than 5 minutes old in order for it to pass muster in this regard.

If the timestamp is at the end of the security header, then it's possible that a whole load of processing relating to token processing, keys, decryption, digest computation and signature verification might occur, only for the receiver to subsequently find out that the message is more than 5 minutes old, hence is stale and has to be thrown away…

If the timestamp is at the beginning of the security header, the service can check for freshness and immediately stop processing the message if it's found to be stale. Thus avoiding all that expensive cryptographic processing.

Now, the alert among you will be thinking to yourselves at this point, "didn't the service just make a decision based on unverified data?". That is, the service checked the timestamp for freshness before verifying that the timestamp hadn't been tampered with in transit. And you know what? You're quite right. But you know what else? It doesn't matter!

There are the following possibilities;

Message appears stale. Timestamp NOT tampered with.
Message appears fresh. Timestamp NOT tampered with.
Message appears stale. Timestamp tampered with.
Message appears fresh. Timestamp tampered with.

In cases 1 and 3 we can safely throw away the message as soon as we see the timestamp indicates the message is stale. Why? Because in case 1 it really is stale, and in case 3, if we don't throw it away due to it being stale, we'll throw it away due to signature verification failure. In case 2 we don't want to throw the message away, everything is fine. And in case 4, we'll throw the message away due to signature verification failure.

Net; it's much more efficient to have the timestamp be the first element in the security header because the service can avoid a whole bunch of processing.

More to come on security header layout in subsequent entries.

Don on WCF security

martin-gudgin — Sat, 10 Sep 2005 01:58:00 GMT

Don says some nice things about the claims based model at the core of WCF security. Doug and I will be doing our best to explain that model at PDC. And I'm sure we'll both be blogging about it in the weeks to come.

Mark Baker complains about Google

martin-gudgin — Thu, 08 Sep 2005 23:48:00 GMT

Specifically, about URL masquerading. Apparently Yahoo search does it too…

Dare I suggest Mark use http://search.msn.com ? Not a masqueraded URL in sight…

Actually, when I use Google, I don't see any URL masquerading, so perhaps it's been turned off already, as Mark requested :-)

httpcfg flags

martin-gudgin — Wed, 31 Aug 2005 14:45:00 GMT

Ian makes a reasonable point in his comment on my previous entry; the flags to httpcfg are somewhat arcane (which, according to my OED, means 'understood by few, mysterious' ).

The flags to httpcfg are actually a bit mask, which according to the information displayed by running httpcfg with no command line arguments, supports the following behaviour;

0x00000001 - Use DS Mapper.
0x00000002 - Negotiate Client certificate.
0x00000004 - Do not route to Raw ISAPI filters.

We already know what setting bit 2 does; it enables mutual authentication using a client certificate ( I should probably note at this point that it doesn't require mutual authentication ).

Setting bit 3 'prevents SSL requests being passed to low-level ISAPI filters', whatever that means… I know what an ISAPI filter is, but it's not clear from the description of the flag whether it stops SSL requests being routed to ISAPI filters, period. Or whether some ISAPI filters are considered more low-level than others and it only stops such routing for really low-level ISAPI filters.

Setting bit 1 means that presented client certificates are mapped, where possible, to Windows user accounts. The online help implies that this will only take into account mappings between certs and user accounts defined in Active Directory, but I suspect you may be able to get it to work with local user accounts too. This seems to be akin to configuring IIS Directory Security and under the Secure Communications, Edit… dialog, setting the 'Enable client certificate mapping' and defining some mappings from certs to Windows user accounts. In fact, I suspect that when you do this, the IIS Admin tool calls the same API that httpcfg calls, namely HttpSetServiceConfiguration.

By the way, I got most of the information about what httpcfg is up to from looking at the help for HttpSetServiceConfiguration, specifically the HTTP_SET_SERVICE_CONFIG_PARAM structure.

SSL mutual authentication and more httpcfg magic

martin-gudgin — Mon, 29 Aug 2005 22:16:00 GMT

I've been trying to get mutual authentication, where the client and service both have certificates, to work over SSL (specifically HTTPS) for a simple demo I'm doing at PDC. In an earlier entry, I mentioned httpcfg, the tool you use to configure the server side certificate (amongst other things). Unfortunately, while the command line I provided in that entry works just fine for server-only authentication, it doesn't work for mutual authentication. If you try mutual authentication, the client will probably get the helpful '403, Forbidden' error from the HTTP layer. In order for mutual authentication to work the flags parameter to httpcfg needs to be set to '2'. So the full command line needs to be something like;

httpcfg set ssl -I 0:0:0:0:8088 -h abcdefabcdefabcdef -f 2

Hopefully this will save someone some time if they're having trouble getting mutual authentication over HTTPS to work.

Thanks to Hao Xu from the Indigo core messaging team for helping me track this down.