So, given that I’m into motorcycles and that I’ve had to put away my bike for the winter I’m yearning for all stuff bike related. One of those things are motorcycle films. Combine this with my newfound addiction to MotoGP I want to see the films Faster and the follow-up Fastest. What I found was that I couldn’t see or buy them, even if I wanted to pay for it!

What’s the deal with not releasing your merchandise ASAP around the world?

Now, in my book that’s one of the problems fueling piracy….

(BTW, I sent an email to the production company asking about the availability and they told me they would get back to me when I can get it… *yawn*.)

This exact same thing annoys me about certain web shops, specifically the ones that have the product, but won’t ship it to Sweden (or any other European country for that matter) for some unknown reason. It’s called e-commerce for a reason, right?

So, it’s been quite a while since I posted something on this blog. A lot has happened since then, too.

• I’ve started a club (where I DJ as well, apart from the serious amount of work it demands).
• I got myself a new motorcycle (a Triumph Tiger 800 Venom Yellow, for those of you wondering).
• There’s a new project I’ve been working on since January (no more BizTalk for now).
• I’ve been to the North Cape and back (on my new Triumph – it was awesome!).
• Wall climbing is my way of trying to stay fit during the winter.
• I sold my car and joined a car pool.
• I’ve grown a beard (not sure how that happened really…).
• I canceled my gym card.
• I got hooked on MotoGP and in the end of this years season the dude I found the most interesting died while racing.

There are a lot of reasons why I haven’t had the energy to keep going with the blogging, but I’m hoping that by increasing the personal touch and decreasing the demands I put on myself might help with that. I’m thinking shorter posts about more or less anything. Also, I’ll try to not feel so bad about switching languages as well.

The other day I released a library (BizUnitCompare) for simplifying the testing of integrations in BizTalk using BizUnit.

Let’s say that you know what a message should look like when the integration is working like it’s supposed to. Using BizUnit you could drop a message into BizTalk and let BizTalk have its way with it. When BizTalk is done with it it might put the result somewhere on your file system.

Wouldn’t it be wonderful if you had a tool that compared the message BizTalk just put on your file system with another message containing the data like it should look and then tell you the differences – if there were any? Some of you might say that this is entirely possible using BizUnit as it is. Well, yes. It is possible. But only if you want to put in hours and hours of work configuring an XPath expression for each and every element and attribute with its expected result for your complete message (is that the echo of slowly dying BizUnit tests that aren’t being maintained?).

This is where BizUnitCompare enters the stage. With BizUnitCompare all you have to do is to tell it what the expected result is (a file stored somewhere on your file system), where to look for the newly generated file (created by BizTalk perhaps using BizUnit) and what elements/attributes/parts of a flat file it shouldn’t look at (e.g. time stamps and so on).

The whole idea behind this is that it’s probably less work to exclude the parts of a file you’re not interested in comparing rather than including everything you are interested in comparing.

Now go, get started building your BizTalk tests!

With the recent appearance of the tool Firesheep being used for hijacking peoples cookies I noticed that a lot of people began installing tools in their browsers which forced connections to migrate from HTTP to HTTPS for certain web sites. One complaint was that these tools weren’t available for each and every browser they were using.

(Update: it seems that some of these browser plug-ins will actually allow an unsecured request to go out before the plug-in manages to rewrite the request. It seems that this problem is mostly tied to some sort of bug within Chrome. So that’s another reason to use a system wide proxy which gets it right from the very beginning instead.)

So I started thinking along the lines of building something on top of the ad blocker I’m using on my Mac – GlimmerBlocker.

So now you can add a subscription to the set of filter I’ve built by adding this URL: http://diktator.org/sslify.xml. For a description of how to add subscriptions to filters check out this page: http://glimmerblocker.org/wiki/Filters#Howtosubscribetoafilter.

It’s just a beginning (and probably reeks of ugly hack), so any additions would be welcome! Just comment on this post.

Enjoy!

During the past day I’ve been struggling with a rather peculiar problem. It involves the following ingredients:

• BizTalk Server 2006 R2
• WCF (Windows Communication Foundation)
• A web service running on an IIS platform requiring NTLM as the authentication method
  • No authentication requirement for downloading the service metadata (WSDL)

I’ll spill the beans right away – you won’t succeed. At least not without building something involving unmanaged code (see this article for further information). This here, rather lengthy, article aims at explaining the reasons why you won’t succeed – it won’t give you a solution in the end, sorry about that. The only solution which might work is the one previously linked, haven’t tried it though. In the end we ended up opting for another authentication mechanism.

Here’s the whole story:

Due to the fact that generating the WCF client required no authentication the following problem didn’t surface until rather late in our development process, actually as late as when we were doing final tests in the BizTalk test environment.

So, what happens is this: the WCF port in BizTalk tries to send a SOAP message to the web service it’s configured to connect to. The web service states that the client (the BizTalk server in this case) is unathorized (HTTP 401, to be specific). Along with this message it says that the allowed authentication method is NTLM. As a result of the fact that downloading the service metadata required no authentication the generated configuration for the WCF port in BizTalk states nothing about how it should proceed to actually authenticate. What to do?

By now you’ll be digging around the various dialogs in the WCF adapter configuration in BizTalk looking for a place to enter a user name and a password. Depending on the port type chosen (WCF-Custom, WCF-BasicHttp or WCF-WSHttp) and the chosen binding (wsHttpBinding, basicHttpBinding or customBinding) the dialogs might look a little different. How ever, the end result is this:

• For any other port type than WCF-Custom there’ll be a tab called Security allowing you to enter credentials – but only if the authentication method chosen is set to “Basic” (or “Digest”, but that’s not really interesting for this scenario). For “NTLM” the Edit button allowing you to configure the credentials will be disabled.
• If you’ve chosen WCF-Custom as your port type there’ll be a tab named Credentials where you can enter a user name and password. Only problem is that this information will be ignored if you set the clientCredentialType to “NTLM” within the binding configuration for your endpoint. So no luck there either.
• Not even if you add the clientCredentials extension as a behavior and configure that behavior to be used for your endpoint you get settings for user name and password. What you do get though is a truck load of options for configuring client certificate authentication. Yay.

Just for fun one could try to set the authentication method (clientCredentialType) to “NTLM” within the binding, and never mind the fact that won’t be able to enter a desired user name and password. This only gets interesting with web proxy that’ll show you what is exchange between your client and the server. An excellent program to use for this is Fiddler. What you’ll notice after running the test is that the WCF port will try to authenticate with the service using the credentials held by the host process (the BizTalk host instance in this case). Of course the server hosting the web service won’t know anything about that account and therefore it’ll deny the request.

So how would you go about overriding the credentials sent by the WCF adapter in BizTalk? Should you be presented with this problem in a regular .NET run time environment (such as a console application or windows service) you’d probably end up doing it in one of the following ways:

• Creating a class which inherits the ClientCredentials (MSDN link) type in which you would explicitly set the Windows.ClientCredential.Username property along with the Windows.ClientCredential.Password property and the Windows.ClientCredential.Domain property to what ever you like. This type would then be pointed out in your WCF client configuration as the type to be used by the clientCredentials behavior extension for providing credentials (see this link for documentation about the ClientCredentialsElement.Type property, and see this screenshot for an explanation of how to set it up).
• Another way of doing it is to do it directly on your generated client proxy within your applications code. A slightly more hard coded approach, but certainly viable:

serviceProxy.ClientCredentials.Windows.ClientCredential.UserName = “HelloKitty”;

Trying to send a SOAP message from your regular .NET application using any of these methods will result in the WCF client sending the correct (as in, desired) credentials to the server and thus succeeding in authenticating.

Why all the fuss with putting the user name and password in code and not in the WCF section (<system.serviceModel>) of your configuration file? Well, it’s been decided that giving the option of declaring credentials in a configuration file is insecure and therefore should not be supported out of the box. Not a totally stupid thought, actually. Worth noting here is that your code implementing any of the two solutions above could of course read the user name and password from anywhere you want – a database, a text file, basically anything.

Considering that the actual WCF configuration in BizTalk allowed me to specify a custom type for providing clientCredentials (as seen in this screenshot) I decided to go with the first alternative. Now that I had created a type that inherits the ClientCredentials (MSDN link) type I added it to the GAC, I added the fully qualified assembly name to the type-property of the clientCredentials extension for the newly created client behavior which I had added to the endpoint (screenshot shown again here). After doing all these things the setup is ready for another test. Nota bene: these configuration options require you to use WCF-Custom as your port type.

This test will fail! The Event Viewer will have an entry in its Application log saying this:

System.InvalidOperationException: The ClientCredentials cannot be added to the binding parameters because the binding parameters already contains a SecurityCredentialsManager ‘System.ServiceModel.Description.ClientCredentials’. If you are configuring custom credentials for the channel, please first remove any existing ClientCredentials from the behaviors collection before adding the custom credential.

Yes, this will be confusing to you (and me) since we in the configuration are only allowed to specify one custom type for providing our ClientCredentials. So where did the other instance come from, and why did it get there before our custom one?

Thinking about this I came to the following conclusion: the developers of BizTalk had a problem they needed to overcome. Remember what I said about storing user names and passwords in WCF configuration files? Since this was deemed to be unsafe by the WCF team this meant that the developers building the WCF adapter for BizTalk weren’t able to solely rely on the WCF configuration file structure to provide all the data needed for the WCF port to actually execute, especially if any credentials would be required by the service in the other end. You might also remember that you, as a developer configuring the WCF options of your WCF port in BizTalk, are allowed to enter credentials if “basic” is chosen as the authentication method. My guess here is that those credentials entered in that dialog end up somewhere in the SSO database used by BizTalk. But how do they get from the SSO database to the WCF runtime when the WCF port needs to send a message?

This is where the secret sauce enters the stage! The only explanation I’ve come up with is that the wrapper code for the WCF adapter in BizTalk dynamically generates a ClientCredentials instance which is populated with any data entered by the BizTalk administrator in the port configuration. This instance is then added to the generated WCF client in BizTalk and thus disabling any other instances of the same type to be added to the same client.

So, to sum this up I’d say the following:

• The credentials implementation for the WCF adapter in BizTalk 2006 R2 is broken. Possibly in more ways than one:
  • It won’t allow you to successfully specify user name and password for NTLM authentication.
  • It won’t allow you to successfully specify a custom type providing credentials for NTLM authentication.
  • It seems to have a hard coded behavior where it insists on sending the host processes’ account details as authentication credentials when NTLM is chosen as the authentication method. This may be by design or standard – I don’t know.
• The decision to deny developers the ability to store credentials in an application configuration file is not bad – but it should be more “out in the open” that there is a security reason behind this decision. During these days I’ve seen dozens of forum threads with people trying to figure out why they can’t find a place to configure their user name and password for the service they’re accessing, all of them assuming that they have missed something, somewhere.

The solution (which I said I didn’t have)?

Use any other authentication mechanism than NTLM, atleast if the host process account has no chance of being granted access to the target service. Or try out the linked article in the beginning of this post. Good luck!

Since I began riding motorcycles I haven’t really thought much about the noise levels accumulated inside the helmet. I guess I’ve always thought that if everyone else can do it I can too. But then one day I realized that the small amount of tinnitus that I already have was being more and more easily provoked by the noise in my helmet. That’s when I started riding with ear plugs and the more I asked around among other bikers it turns out that quite a few of them also wear varying types of ear protection.

Given that my ear canals are on the small side I’ve had troubles finding protection that won’t make my ear canals hurt like h**l after a while (especially inside a helmet). After some research I found a company (EARfoon – Swedish site) which will make molded forms of your ear and produce custom made ear plugs which they then fit with filters specifically made for bikers. About three weeks ago I had my molds made and now they’ve arrived at the shop. Going to pick them up at 11 – happiness! =)

- update -

Oh my, this is some good stuff I’ve gotten my hands on! They fit like a glove on the first try and no more turbulence induced noise in my ears. I’m still able to hear people talk with the plugs in (although at a slightly lower volume) and the engine is still slightly hearable. Sure, you can feel that you’ve got something in your ears, but it’s not nearly as painful as regular plugs. Plus that these plugs won’t move around in your ears (and thus causing noise/acoustic pressure) as the helmet moves on your head (due to road conditions and so forth). Given the fact that these will allow me to keep my hearing even though I’m riding bikes this might be the best investment in the motorcycle equipment department for a long time to come!

If you care for your hearing even the slightest bit – get a set of these!

So, it’s been a while since I mangled out some information using this here fine blog. There are perfectly valid reasons for it being so, like me getting a motorcycle drivers license. And getting a motorcycle as well. =)

These things make you value the time when the sun shines a wee bit more than you might usually do. I got my license the 1st of July and I got the bike the 6th of July and since then I’ve driven a bit more than 5000 km. It’ll still be some time before I hit the 5000 miles line, but until then I can always think about being the man that falls down at your door.

The bike I’ve got is a black 2010 Yamaha XJ6, the naked version with ABS (ABS was an absolute requirement when looking for a bike).

During these 5000 km I’ve already managed to get a screw in the rear tire. There seems to be something with me, vehicles and getting wheels punctured by screws within the first 30 days of ownership. For those of you not in the know, the exact same thing happened with my car less than a month after I had bought it. The funny thing is that I had a conversation with my dad before getting the car about how usual (or unusual) it is to have a tire punctured. He told me that he’s had two punctures in his life and that this was nothing to worry about. So, by his count I should be done with repairing tires by now. =)

Share

I had the opportunity to assist one of my co-workers today in troubleshooting a web service + Silverlight client I had built for a customer a while back. The combination of the two enables users to upload large files to a server over intermittent internet connections. My co-worker mentioned that she got an error message in a message box from the Silverlight client stating that something was wrong with the parameters sent to it.

In the end it turns out that the parameter for the maximum file size allowed to upload had been set to 3 GB. The specification I received when building this stated that the maximum file size that the system should be able to handle would not exceed 1 GB. So I figured a regular int would suffice for managing the maximum file size restriction.

So what this malconfiguration gave was that the Silverlight client tried to stuff the value of 3GB into an int – this is a no go. My co-worker is not to blame for this, she just got this particular setup handed to her from someone else.

What you specify is what you get.

The past couple of months I’ve had reason (more than usual) to sit back and think about all the different frameworks and patterns available out there. One specific example of this is the following:

Imagine that you would want to build a web service whose role it is to impersonate a SharePoint list. This list is then supposed to be consumed by an Outlook clients calendar tool. The data you want to fill this calendar with is stored in a database containing approximately two tables. The reason I got in touch with this was that I was asked to solve some problems regarding the switch from regular time to daylight savings time and calendar items tagged as all day events. Upon hearing about this existing system I thought something along the lines of “How hard could this be? It’s just a bunch of tables and a web service contract to fulfill.”. Well, as it turns out – the joke’s on me.

I’m not kidding when I say that the code base in the repository for this project consists of ~200 files! Factories, Repositories, Providers, Containers and god knows what! When you open a project and within the time frame of about five minutes can’t figure out where approximately to begin solving a specific problem there has to be a problem with how the code is organized. And I don’t see myself as an under qualified developer. What I ended up doing was setting a breakpoint in Global.asax at the start of a request and then step my way from there. And the funny thing is that all the database access code was hand written. NHibernate (or any other OR-mapper for that matter) hadn’t crossed the mind of the previous developer (or at least wasn’t implemented).

Grossly over engineered. That’s what comes to mind when I look back at this.

A couple of days ago I was recommended the following article: Joel On Software – Why I hate frameworks. Read it! It’s quite a funny read and I can definitely relate to this problem. I also think that this specific issue should be more widely discussed. Somehow it seems that the software development world has moved away from solving real problems to solving problems related to the problem solving. Not quite sure how that adds immediate value for the customer. Also not quite sure how it relates to working agile. If we extrapolate the current situation just a liiittle bit more we’d end up with architects and developers adding a bunch of frameworks to their project and organizing them according to some new patterns (which are bound to appear) they’ll expect the code to write itself!

And I haven’t even mentioned the frameworks managing the other frameworks.

Today I realized that something from my past as a systems administrator has passed on. The NewSID tool has been retired by it’s founder himself, Mark Russinovich.

As it turns out it’s impact was pretty nominal, and might even be detrimental in some cases where software has been installed before the SID is changed. This is a scenario I have experienced myself actually. My intention was to prepare a fully installed BizTalk server which I could clone whenever I needed a new instance of it.

As it turns out the Enterprise Single Sign-On data becomes unavailable after the SID is changed. I’m guessing that the SID is somehow used to encrypt the data, and therefore the decryption fails with the new SID.

To read the specifics about why the tool has been retired head over to Marks own blog where he goes through all the gory details.