Musings from Gudge

PDC 2008

2008-08-01T18:38:00Z

I've been in the U.S. nearly two years now, working away on various things with the rest of the folks on my team. Soon I'll be able to talk about what I've been working on in public; Chris Sells and I will be delivering a talk at PDC 2008, currently entitled "Oslo": Repository and Schemas, catchy, huh?

Windows Workflow/Rules Designer Re-hosting

2008-03-13T14:05:00Z

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

2007-11-20T08:10:00Z

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

2006-06-19T13:20:00Z

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!!!

2006-05-23T17:46:00Z

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

Priceless!

httpcfg Flag Weirdness

2006-05-16T04:18:00Z

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

2006-04-18T16:45:00Z

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

Service Factory Open For Business

2006-04-18T16:30:00Z

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

2005-11-08T13:26:00Z

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

Will the real Steve Swartz please stand up…

2005-10-20T08:13:00Z

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!

2005-09-28T23:42:00Z

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?

2005-09-10T02:33:00Z

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

2005-09-10T01:58:00Z

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

2005-09-08T23:48:00Z

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

2005-08-31T14:45:00Z

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.