The art of simplicity

In our move to improve security in our api landscape, we configured a global redirect rule in IIS to redirect calls to HTTPS. An unforeseen consequence was that for our (old) WCF services, the WSDL endpoints were no longer accessible. When someone clicks on the WSDL link, a redirect happens but on the https endpoint no metadata is available. To fix it, I had to update the WCF configuration to explicitly enable the metadata endpoint on HTTPS:

Great news for everyone who has still some WCF services running. Until recently only BasicHttpBinding and NetTcpBinding were supported . This limited the usefulness as most WCF services I encountered where using WSFederationHttpBinding (or the more recent WS2007FederationHttpBinding). These bindings were typically used in scenarios where users authenticate with a security token service (like Active Directory Federation Services). Last month, the System.ServiceModel.Federation package was released, adding client(!) support for WSFederation. Remark: You cannot use this binding yet through dotnet-svcutil or the Visual Studio’s WCF Web Service Reference Provider Tool but this will be added in the future.

A colleague shared with me the following strange error message he got when he tried to use a .NET Standard library I created: An unhandled exception occurred while processing the request. TypeLoadException: Type 'generatedProxy_5' from assembly 'ProxyBuilder, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' is attempting to implement an inaccessible interface. System.Reflection.Emit.TypeBuilder.CreateTypeNoLock() · TypeLoadException: Type 'generatedProxy_5' from assembly 'ProxyBuilder, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' is attempting to implement an inaccessible interface. o System.Reflection.Emit.TypeBuilder.CreateTypeNoLock() o System.Reflection.Emit.TypeBuilder.CreateTypeInfo() o System.Reflection.DispatchProxyGenerator+ProxyBuilder.CreateType() o System.Reflection.DispatchProxyGenerator.GenerateProxyType(Type baseType, Type interfaceType) o System.Reflection.DispatchProxyGenerator.GetPr...

In an ASP.NET Core application(using the full .NET framework) we had to consume a WCF service. Should be easy right? Unfortunately it turned out that be more work than I expected. In a first post I explained the steps how to generate a Client Proxy, this post is about  setting the configuration. WCF configuration can be a daunting beast with a lot of options and things that can go wrong. The code generated by the proxy hardcodes (some part) of the configuration in the WCF proxy and provides you a partial method to override it but that’s not the approach we want to take. I know we’ll host the WCF service in IIS, so adding a web.config and putting the configuration logic over there sounds nice… Let’s try that: Open the generated proxy reference file  and remove the call to Service1Client.GetDefaultBinding() and Service1Client.GetDefaultEndpointAddress() in the constructor. ( Note: this is only for testing purposes) Right click on your ASP.NET Core proje...

In an ASP.NET Core application(using the full .NET framework) we had to consume a WCF service. Should be easy right? Unfortunately it turned out that be more work than I expected. I right clicked on my project and searched for an Add service reference… option. No luck, instead I saw a Connected Services section. Maybe that will do it? I right clicked on the Connected Services section and choose Add Connected Service . This opened up the Connected Services window but no option was available to connect to an existing WCF service Maybe the Find more services… link at the button will help me? This brought me to the Visual Studio Marketplace. And yes… a search for ‘WCF’ showed up a Visual Studio Connected Services plugin that allows to add a WCF Web service reference to .NET Core projects. Exactly what I needed. I clicked on Download, closed Visual Studio after which the installer appeared and I could install the extension. After the installat...

On one of our servers we have the following situation: We have 2 websites configured in IIS; one for development and one for internal testing. Both of these websites expose HTTP endpoints. These endpoints are using the same ports but are separated by using different host headers. The problem started to appear when we tried to do enable the TCP binding on both sites. Although we didn’t get an error message, we noticed that when we invoked our service through the TCP endpoint, we always got data back from the development environment. To fix it, we have to update our bindings in IIS. Open the IIS Manager Select the first site. Click on Bindings . Choose net.tcp binding from the list and click on Edit… Update the Binding Information from 808:* to 808:dev.sample.be Repeat the same steps for the second site but this time change the Binding Information to 808:test.sample.be

I’m talking to a WCF service and use a bearer token to authenticate to the service. The bearer token is provided by a custom STS (during testing). However when I tried to invoke the service, I got the following error message back: The X.509 certificate CN=LocalSTS chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. And indeed this error makes sense as the tokens generated by the local STS are signed by an untrusted certificate. As we are using it for testing purposes only, it’s OK to disable the certificate validation. Open the configuration of your webservice. Add a serviceCredentials block to your serviceBehavior. Inside this block add an issuedTokenAuthentication section and set the certificateValidationMode to “ None ”. That should do ...

By default WCF uses symmetric encryption for token validation. However in our situation we were using a custom STS that created bearer tokens. This means that we don’t provide any proof about our identity. When we tried to use the token to call a WCF service we got the following error message: The signing token Generic XML token:    validFrom: 10/31/2016 10:52:49    validTo: 10/31/2016 11:52:49    InternalTokenReference: SamlAssertionKeyIdentifierClause(AssertionId = '_129cb505-83f0-4af0-a455-c51b51926d3a')    ExternalTokenReference: SamlAssertionKeyIdentifierClause(AssertionId = '_129cb505-83f0-4af0-a455-c51b51926d3a')    Token Element: (Assertion, urn:oasis:names:tc:SAML:1.0:assertion) has no keys. The security token is used in a context that requires it to perform cryptographic operations, but the token contains no cryptographic keys. Either the token type does not support cryptographic operations, or th...

Last week I helped a colleague who couldn’t understand why the initialization logic of his WCF service wasn’t invoked. He created a WCF service that he wanted to host in IIS and had put the initialization logic inside the Application_Start method inside the global.asax. The Application_Start method is called when the application is started as part of the ASP.NET pipeline. To be more precisely, it is called when the HttpApplication type is instantiated. This happens when the first HTTP arrives into the application. However the WCF service wasn’t using HTTP binding but used the net.tcp binding instead(which works perfectly fine in IIS). This also meant that the Application_Start method is never invoked as no HTTP call will ever arrive. Fortunately, ASP.NET provides a simple hook that works in a protocol agnostic way. The hook is based on the following method: public static void AppInitialize(); This method can be put in any class that is defined in a C# file in the applicatio...

Aaah, security errors, you have to love them. When deploying a new service on IIS, I got the following error: Server Error in '/SampleService' Application. The profile for the user is a temporary profile. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Security.Cryptography.CryptographicException: The profile for the user is a temporary profile. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [Cryp...

After a long trip in REST land, I’m back in the SOAP and WSDL world. While creating a WSDL and XSD schema for a project I was asked to check the WSDL for WS-I compliancy. I removed the dust from SoapUI and loaded the WSDL: Create an empty project Right click on the project and choose Add WSDL : Click on Browse… and select the WSDL you want to import. Click OK . Right click on the loaded WSDL and choose Check WSI Compliance .

If you try to create a WCF Data Service using the Visual Studio Template(see image below) with an Entity Model created using Entity Framework 6, you’ll end with an exception like the following: Expression of type 'System.Data.Entity.Core.Objects.ObjectContext' cannot be used for return type 'System.Data.Objects.ObjectContext' The problem is that the WCF Data Services template does not offer support for the new Entity Framework 6 classes. In EF6 the ObjectContext is completely decoupled from the .NET framework. As a result the class no longer lives in the same namespace explaining the exception above. WCF Data Services Entity Framework Provider This does not mean you cannot use WCF Data Services with Entity Framework 6. There is a new NuGet package called WCF Data Services Entity Framework Provider . This NuGet package bridges the gap between WCF Data Services 5.6.0 and Entity Framework 6+. Here are the things you need to do to get this working: In...

To setup a 2 way trust between my WCF service and (web) client I’m using SSL and X509 certificates. The problem was that I got the following exception on the client: CryptographicException 'Keyset does not exist'. I had this error before so I knew I had to give my application pool user access to the private key of the client certificate. So I opened MMC, loaded the Certificates snap in, right clicked on the certificate and saw… no ‘Manage Private Keys’ option . It took me some time to figure out that I had to add the Certificates snap-in using the "Computer account" option instead of the default "My user account" option . After doing that, the “Manage Private Keys” option was available:

The last months my laptop started to act strange, 2 or 3 random crashes a day, USB ports that started to fail, extreme CPU usage and so on… And yes, all doctors gave the same diagnosis, my pc was dying. So I took a backup almost every day until it finally happened, one final crash and my system was gone. After getting a new laptop I started to reconfigure my development environment. After installing IIS I tried to open an existing WCF service and was welcomed by the following yellow screen of death: “Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.” This error occured because I installed IIS the .NET Framework 4. Solving this problem isn’t hard, just open up the ASP.NET IIS Registration Tool (Aspnet_regiis.exe,) to register the correct version of ASP.NET. This can be accomplished by using the –iru parameters when running aspnet_regiis.exe ...

WCF has it’s own security model build in. This security model has some overlap what WIF(Windows Identity Foundation) has to offer. Starting from .NET 4.5 you can replace the WCF security pipeline with a WIF equivalent.  This means that we can start using class like ClaimsAuthenticationManager and ClaimsAuthorizationManager to manage claims security in our WCF service. To enable this new model, you have to set the UseIdentityConfiguration property on the ServiceCredentials behavior to true. This tells WCF to get its token handling configuration from the <system.identityModel> configuration section. Internally this replaces the standard ServiceCredentials with FederatedServiceCredentials .

When using the new and improved WIF functionality in .NET 4.5 in a WCF service I noticed that although the OperationContext.Current.ClaimsPrincipal was set correctly, the Thread.CurrentPrincipal was null. To tell WCF to put the ClaimsPrincipal coming from the token handler on Thread.CurrentPrincipal you have to add the following service behavior to your configuration : The end result is a ClaimsPrincipal containing the username, authentication method and authentication instant claims. Also the claims transformation/validation/authorization pipeline will be called if configured.

Adding a WCF service to an ASP.NET MVC project, just choose Add new item and choose the WCF Service item. However when you try to connect to your WCF service(e.g. http://localhost:8000/sampleservice.svc ), you’ll end up with the following exception: “Resource not found” The WCF service URL interferes with the default MVC routing so instead of loading up the WCF service, the ASP.NET MVC framework tries to find a matching controller and action. To fix this, extend the routing with 2 extra ignores:

In an application, we are consuming an OData feed. In development, this worked without any issue but the moment we deployed the application to our test environment, it started to fail with the following exception: The type initializer for 'System.Data.Services.Client.TypeSystem' threw an exception. Looking in the logs on the server, we found the following stacktrace: Sync.exe Information: 0 : Error occured during synchronization: The type initializer for 'System.Data.Services.Client.TypeSystem' threw an exception. Sync.exe Information: 0 : Stacktrace:    at System.Data.Services.Client.TypeSystem.IsPrivate(PropertyInfo pi)    at System.Data.Services.Client.ResourceBinder.PatternRules.MatchNonPrivateReadableProperty(Expression e, PropertyInfo& propInfo, Expression& target)    at System.Data.Services.Client.ResourceBinder.VisitMemberAccess(MemberExpression m)    at System.Data.Services.Client.ALinq...

One of the nice features of Windows Azure Service Bus is the ability to expose an internal WCF service through Azure without any extra configuration on the firewall/network level. This means that a user connects to your service through the Azure Service Bus. You can even take this one step further and change the relay binding to ‘Hybrid’ mode. This means that the Azure Service Bus tries to ‘upgrade’ the connection to a peer to peer connection between the client and the WCF service without going through the Azure Service Bus anymore. This sounds like a little bit of magic, and it actually is(at least for me). Configuring this can be done through the connectionMode property on the binding element: Relayed (default): All communication is relayed through the relay service. The SSL-protected control connection is used to negotiate a relayed end-to-end socket connection that all communication flows through. Once the connection is established the relay service behaves as a socket ...

The WCF Data Service client component works great out-of-the-box. However for a project we wanted to send some extra header data which each request. On the server-side we could handle this by adding a custom WCF behavior on top of the data service, but on the client side this is not possible. How can we do this on the client side? The MSDN site brought the answer: http://msdn.microsoft.com/en-us/library/gg258441.aspx The DataServiceContext exposes a SendingRequest event. By subscribing to this even we can add a new header to the request message before it is sent to the data service. // Create the DataServiceContext using the service URI. NorthwindEntities context = new NorthwindEntities(svcUri); // Register to handle the SendingRequest event. context.SendingRequest += new EventHandler<SendingRequestEventArgs>(OnSendingRequest); The following method handles the SendingRequest event and adds an Authentication header to the request. private static void OnSendingRequest(obj...