The art of simplicity

While reviewing some code I noticed the following code snippet; I had no clue what Stage Markers where so time to dig in… What are stage markers? Stage markers play a rol when you are using OWIN in IIS. IIS has a specific execution pipeline containing a predefined set of pipeline events. If you want to run a specific set of OWIN middleware  during a particular stage in the IIS pipeline, you  can use the UseStageMarker method as seen in the sample above. Stage marker rules There are rules on which stage of the pipeline you can execute middleware and the order components must run. Following stage events are supported: By default, OWIN middleware runs at the last event ( PreHandlerExecute ). To run a set of middleware components during an earlier stage, insert a stage marker right after the last component in the set during registration. More information: https://docs.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-middleware-in-the-iis-integ...

At one of my clients we are (still) using ASP.NET MVC 5 and Web API 2. To secure these web applications we use the WSFederation OWIN middleware together with ADFS. This combination works nice and helps us keeping our applications secure. Today one of the teams contacted me and complained that the middleware no longer worked. The error message they got looked like this: Could not load type 'System.IdentityModel.Tokens.TokenValidationParameters' from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.0.0.127, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The root cause of the problem could be found in the version number, they accidently upgraded the System.IdentityModel.Tokens.Jwt assembly from version 4 to 5. It turns out that version 5 is no longer compatible with OWIN. After reverting back to version 4, everything returned back to normal…

After switching to Visual Studio 2017, one of the projects we were working on started to fail with the following error message: The following errors occurred while attempting to load the app. - No assembly found containing an OwinStartupAttribute. - No assembly found containing a Startup or [AssemblyName].Startup class. To disable OWIN startup discovery, add the appSetting owin:AutomaticAppStartup with a value of "false" in your web.config. To specify the OWIN startup Assembly, Class, or Method, add the appSetting owin:AppStartup with the fully qualified startup class or configuration method name in your web.config. In our case we don’t need the OWIN startup detection, so we followed the suggestion as mentioned in the error message and updated our config to: <appSettings>        <add key="owin:AutomaticAppStartup" value=" false " /> </appSettings> Strange that we didn’t...

After introducing Microsoft.Owin.Testing TestServer in a Test project we noticed that our test execution time increased from a few milliseconds for all tests to multiple seconds for each individual test. With the help of dotTrace I noticed that most time was spent inside Microsoft.Owin.Hosting.Tracing.DualWriter . This class is used by OWIN to write all OWIN related data to the console. After removing the related tracelistener using the line of code below, I noticed that the test execution time returned back to normal: Trace.Listeners.Remove("HostingTraceListener");

This week I lost some time searching where I could specify the ‘Home Realm’ when using the WIF components inside OWIN. I finally found it and decided to share the code:

I’m in the middle of switching between the ASP.NET WIF implementation and the OWIN WIF implementation. I had some unexpected issues, but the positive thing is I learned a lot about WIF and OWIN . I had an existing project where I wanted to start using OWIN. So I included the OWIN NuGet package and added a startup class. Afterwards I started my application. But no luck, the breakpoint inside the Startup class was never hit?! What did I do wrong? OWIN is just a specification and is host independent. If you want to run it on a specific host, you have to add some extra NuGet packages. In my case, I wanted to run OWIN on IIS inside the ASP.NET request pipeline. Therefore I had to add the Microsoft.Owin.Host.SystemWeb NuGet Package. After doing that, my breakpoint was hit and my OWIN middleware was called… More information: http://www.asp.net/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana

I’m in the middle of switching between the ASP.NET WIF implementation and the OWIN WIF implementation. I had some unexpected issues, but the positive thing is I learned a lot about WIF and OWIN . One of the issues I encountered was the following error message: “A default value for SignInAsAuthenticationType was not found in IAppBuilder Properties. This can happen if your authentication middleware are added in the wrong order, or if one is missing.” Fixing it is a one-liner: app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

If you like at the OWASP site, you’ll find a while list of common security-related HTTP headers that every web application should implement. These headers are an essential part of building a secure web application. If you are too lazy to click on the link, here is the full list: Strict-Transport-Security X-Frame-Options , Frame-Options X-XSS-Protection X-Content-Type-Options Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP Content-Security-Policy-Report-Only There are multiple ways to add these security headers to you application. You can configure IIS to include them, add some extra ASP.NET (MVC) configuration or you can build some OWIN middleware to add these headers to every HTTP request. If you decide to use OWIN, be aware that most of the work is already done for you. On GitHub I found the SecurityHeadersMiddleware project which implements most of the headers mentioned above. Get started The easiest way to get started is t...