2010-05-06 09:02

Configure WCF in IIS for anonymous access

This case may sound strange and I have seen loads of post that describes how to get out of this behavior. But we have a case where we want to allow anonymous access and the let a external component manage the security validation.

This turned out to be very hard to figure out and required some wizard-like skills of Anders Granåker amongst others.

OK – the case is very simple. I have a WCF Service that I want to allow anonymous access to. I don’t care about message and transport security (for now). Just allow anonymous access – I’ll take care of the authorization in code.

Here is what I had to do to get it to work on Windows 2003 R2:

1. Create a account on the server
2. Put that account into the IIS_WPG group
3. Create a virtual directory for my WCF service
4. Create an application in that virtual directory
5. Set the account as Identity on the application pool that the virtual directory is using (DefaultAppPool for example)
6. Set the account as the anonymous account the virtual directory is running under (Directory Security)
7. IISReset to get the settings to take

The last step is a bit interesting… In this time and age you could think that a simple recycling of the application pool would be enough but … no. Do an IISReset to be sure.

Another gotcha that confused us a lot was that when you set an account to be the anonymous account for the virtual directory, you’re prompted to set the password. And retype it to be sure. But that password is not check if it’s the right password! Beware – I locked out our administrator account due to this.

Now it works – and we have a build script that is doing regressions tests via SOAPUI.

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  WCF    Life of a consultant    MSBuild

2010-04-14 20:26

Calling SOAPUi Testscript from MSBuild

Yes, I know that I have written about this before, with several updates. But I have now solved some issues with setting different endpoints for different services and thought that I might need to update the MSBuild-script to be able to call with those parameters also.

Again – the script I am starting off is written by Todd of the Tar Pit. I’ve just tweaked it to take project property as input. That was the recommended way to change the endpoint for one service, to set the endpoint to a projectwide parameter.

So, here is what the new MSBuild targets looks like.

And here is a DOS-command that runs the MSBuild-target TestAll with the project property set to a endpoint.

Please note that I was running this on a 64-bit Windows 7 and got some strange paths (Framework64) that you want to change..

You can download my complete (now updated) project from here.

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Tools    .NET    WCF    MSBuild

2010-03-30 21:29

Changing endpoint from the command line when testing services with SOAPUi

I have been singing SOAPUi’s praises lately and it’s really great for testing services. In this post I describe how I made the whole thing work for testing WCF Services.

But, as stated in this post, there was still one more thing to be solved… The endpoints from the command line. You want to use different endpoints in different environments. And in my specific customer case I want one of them to stay the same all of the time, since that endpoint points (sorry, could not resist myself) to a “singleton” kind of service.

Luckily the SOAPUi team also have some great support (Thanks Ole, who replied in Swedish!). So here you have it – how to change the endpoint for one of your services under test from the command line – which in my case means the build script.

1. I first created a sample WCF service project (very vanilla, i didn’t touch the code just the default generated code).
   By the way; really cool hosting and test client stuff in Visual Studio 2010
2. I changed the binding to basicHttpBinding since that’s the only thing that work with SOAPUi. I used the WCF Service Configuration tool in Visual Studio of course.
3. I then created a normal SOAPUi project and let SOAPUi create testcases for me. I added asserts just to make sure that the I didn’t get an error back.
4. I started my service and ran the testcases – It worked!
5. I then, and here is the trick, created a project-wide property (Click project file and chose Custom properties in the lower part of the project window) to hold the endpoint value.
   1. I named the project wide property DemoServiceEndpoint
   2. I gave it the address of the service I was testing as value
6. I then opened the tree down to the test request in question and then chose the Test Property-tab in the lower part of the project tree
7. Here I entered this expression that reads the value from my project wide property:
       ${#Project#DemoServiceEndpoint}
8. I repeated for my other test request and tested. It still worked!
9. OK – we’re closing in now. Now I used the Test Runner to create my command (nifty stuff SOAPUi dudes!). Here I got the opportunity to set my parameter ${#Project#DemoServiceEndpoint}.
10. After some tweaking I managed to “harvest” the command into a .bat-file.
    

    "C:\Program Files (x86)\eviware\soapUI-3.5\bin\testrunner.bat" -sDemoTestSuite -PDemoServiceEndpoint=http://localhost:8732/Design_Time_Addresses/Marcusoft.SOAPUiDemo.WCFService/Service1/ C:\Dev\Marcusoft.SOAPUiDemo\EndPointOverrideDemo-soapui-project.xml 

11. And it worked!

So now I can change the endpoint from the command line! In my build script when I have deployed the service to the testing environment for example! Yeah!

You can download my example here.

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Tools    .NET    WCF    Life of a consultant    MSBuild

2010-03-03 13:11

SOAPUi and MSBuild

After my last post I cannot withhold you from this nugget. It’s a guy (Todd) that have created some MSBuild targets to call SOAPUi from a build script.

I am about to try it out… I’ll get back to you if I run into problems.

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Tools    .NET    WCF    MSBuild

2010-03-03 13:08

SOAPUi and testing WCF Services – how I made it work

I have already blogged about SOAPUi but then it was more me thinking and seeing it was a good idea to use SOAPUi to do testing of service.

Now I have actually done this – and I love it so far. In the last project where we our deliverable was a service I think we spent about 30% of our time creating and maintaining the test client.

Not to speak about all the time we had to spend explaining for the client that “no this is NOT the GUI you will see later on”.

So the thought of a general test client for SOAP services is very compelling. And SOAPUi has done a great job making your job easy and fun… Almost all of the time.

They have an amazing amount of documentation. I guarantee that everything I am about to tell you is in there somewhere… This is my short story for our case.

So the case is as follows – I have a quite simple WCF service. One trick is that we need to call a common security service (let’s call it SECI) to get a token that we have pass into our operations.

We have worked contract first and started with a WSDL-file. I used WSCF.blue (great tool) to generate the service stub. And then…

• I downloaded SOAPUi. Go on - do it now- it’s free!
• I created a new project by pointing the wizard to my WSDL-file. I also asked the tool to create a starter testcase for me.
  Beware of the location or endpoint address – it’s read from the WSDL-file and most likely you will need to change that to your computer or the server where your service is deployed.
• I then added a new WSDL to the SECI service to the project. This is needed to be able to call

I was now ready to create my test case with the test steps I need to call the SECI service and insert the token into the request I wanted to test.

• First I created some parameters for my test suite. This is actually hidden away a bit.
  • Open the test suite editor by right clicking it and chose “Show TestSuite Editor”
  • In the lower section of the editor you’ll find a “tab” that is named Properties

 

• Here you can add properties that will be visible for the whole test suite
• I added some inparameters to the SECI service and the token I will pass on
• I then called the SECI service, passing it values from the parameters I created in the earlier step.
• To get the values from the response of the SECI service into the request to my service I used a Property Transfer. In it I transferred the value of the token node into a variable that holds the property for the token.
  It’s a quite deep structure with dropdown boxes and namespaces in the UI here but it’s not to hard to understand.
• Finally I could easily insert the value of the token variable into my request, as before.

It wasn’t to hard after I got understanding about the variables for the testsuite. I sure beats having to code your test client manually…

Great work SOAPUi!

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  Tools    .NET    WCF    Agile

2008-12-01 23:28

AddressFilter mismatch at the EndpointDispatcher

The complete error message was: "The message with To '[my service address]' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher."

We got this message when we deployed our services to the production environment. In this environment we first encounter BIG-IP and clustering. And that's when we hit this brick wall.

The scenario was that BIG-IP had one DNS-name/Ip-address that "forwarded" request to two different servers. However when we accessed the servers with wsHttpBinding we ran into trouble and the above mentioned error message.

The strange thing was that it worked fine with basicHttpBinding, which puzzled us for a while.

Well, thanks to the excellent knowledge in the Avega Microsoft community, we got an answerer in matter of minutes.

As this post points out you can handle the problem by setting the AddressFilterMode to Any, which basic means - ignore addressfiltering.

As far as I understand WCF matches the address property for the client and the server and if it doesn't match (according to AddressFilterMode) the above mentioned error message is thrown.

And for the strange behavior that basicHttpBinding worked it must have to do with that basicHttpBinding doesn't care about that kind of matching. I believe that it has to do with WS-Addressing and that is not a part of basicHttpBinding.

I love to be challenged about this - this is just what we figured out in the project.

Thanks to all that helped us solve this.

Postad av Marcus Hammarberg

Kommentarer (1)   Kategorier:  .NET    WCF    Life of a consultant

2008-11-04 19:21

Configuration of WCF-binding

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  WCF

2008-11-04 19:20

WCF Self-hosting and configuration

Postad av Marcus Hammarberg

Kommentarer (0)   Kategorier:  WCF