Event Tracing for Windows (ETW) is cool. There is nothing like it, for instrumenting your app. ETW is interesting because at this time, it is not easy to find your way around. There is an excellent Pluralsight course by Kathleen Dollard and several blog posts and videos by Vance Morrison. .NET 4.5 has made ETW so easy. All you need to do is to create a custom event source by inheriting from the System.Diagnostics.Tracing.EventSource class. You can use the PerfView tool or logman command to start and stop a session and create an ETL file. ETL file is binary and contains pretty much all the info one would ever need but then getting the info out is not an easy task.

There is this TraceEvent API available in the form of NuGet package. This is very powerful and there is even a NuGet package for samples but then what you want to do is what is generally missing from what is available in the public domain or more complex for the time you have.

Then, there is this tracerpt command which generates an XML file from ETL file like this.

tracerpt etw_000001.etl -o etw.xml

The output XML contains all the system data but not the payload that I’m providing to log. It then dawned on me that tracerpt is probably not new enough to use the inline manifest and it might require installed manifest just like the event viewer. So, I set out to create a manifest file and install it.

Eventregister.exe creates the manifest file, which is an XML and a resource assembly. To get this exe, just install the NuGet package Microsoft.Diagnostics.Tracing.EventSource and Eventregister.exe will be in the tools directory.

eventregister.exe /dumpregdlls C:\Path\bin\Debug\MyAssembly.dll -forceall=true

Next step is to use wevtutil.exe and install the manifest using the man file and the dll file produced by eventregister.exe.

wevtutil.exe im C:\Path\bin\Debug\MyAssembly.Badri-MyEventSource.etwManifest.man

Okay, here is the important thing. Specify the absolute paths with wevtutil. Otherwise, manifest will not be installed correctly and tracerpt will not show your payload. Learnt it the hard way and hope these steps are useful to someone.

Authorization filters and action filters have been around for a while in ASP.NET Web API but there is this new authentication filter introduced in Web API 2. Authentication filters have their own place in the ASP.NET Web API pipeline like other filters. Historically, authorization filters have been used to implement authentication and there is ton of samples out there with all kinds of authentication implemented in authorization filters. Web API 2 introduces the authentication filter so that authentication concerns can be separated out of authorization filter and put into an authentication filter.
Read More…

Posted by: Badri | January 28, 2014

Detecting Extra Fields in ASP.NET Web API Request

This post is related to binding in ASP.NET Web API. Binding (parameter binding, to be exact) is the mechanism through which request body is bound to the action method parameter. Say you are using a DTO class as parameter and if you want to ensure a field is present in the request, you can apply Required attribute at the property level like so.
Read More…

Posted by: Badri | December 21, 2013

OWIN and Microsoft Katana 101 [Kindle Edition]

Happy to announce the availability of “OWIN and Microsoft Katana 101 (Kindle Edition)” in Amazon.

OWIN and Microsoft Katana 101

This short book is for .NET C# developers who are curious about the Open Web Interface for .NET (OWIN) specification and Project Katana and want to learn more. The ecosystem of OWIN-based components is undoubtedly the future of the .NET framework-based web development. As a pointer of things to come, Visual Studio 2013 creates references to the Microsoft.Owin.* packages by default, for most of the ASP.NET project templates. The objective of this book is to introduce you to OWIN and Katana, the middleware goodness, and hopefully betters your understanding of OWIN applications.

My sincere thanks to Chris Ross, Developer, Microsoft Katana, for providing valuable feedback on the content and answering all my questions with utmost patience.


A bit of History and Context
Creating the Obligatory Hello World Middleware
Hosting on a Custom Host (Console Application)
Hosting on IIS Using the ASP.NET Request Pipeline
Strong-Typing the Hello World Middleware
Chaining Middlewares
Conditionally Running Middlewares
Implementing Middleware as a Separate Class
Adding a Response Header from Middleware
Reading the Request Body from Middleware
Reading the Response Body from Middleware
Using a ‘Framework Middleware’ (ASP.NET Web API)
Composing Your App from Middlewares
Using the Built-in JWT Authentication Middleware
Creating a Custom Authentication Middleware
Using Stage Markers
Adding Middleware to Existing ASP.NET Application
Injecting Dependencies into Middleware
Testing OWIN Applications

Hawk Authentication in Thinktecture.IdentityModel can be hooked into your ASP.NET Web API through the message handler (HawkAuthenticationHandler) or the OWIN middleware (HawkAuthenticationMiddleware). The sample here is based on a self-hosted web API (WCF channel stack) using the message handler and another self-hosted web API (OWIN host adapter) using the OWIN middleware. It is possible to use the OWIN middleware and enable Hawk authentication for your ASP.NET Web API which is hosted in IIS. Of course, you can use the message handler, which is the simplest option but we will see how message handler measures up to OWIN middleware in the case of hosting in IIS.
Read More…

Posted by: Badri | November 4, 2013

Thinktecture.IdentityModel.Hawk NuGet Package

With Thinktecture.IdentityModel V.Next out, Hawk authentication implementation in Thinktecture IdentityModel gets its own NuGet package. It is currently in pre-release and here is the NuGet Gallery link. The OWIN middleware code that has been a part of the samples is now moved into Thinktecture.IdentityModel and is a part of this NuGet package.

Let’s now see how we can create a simple web API (ValuesController, of course) and OWIN-host it with hawk authentication plugged in using the OWIN middleware that is part of this NuGet package.
Read More…

Hawk authentication is designed to work without transport security. When TLS is used, replay protection is not much of an issue but it is an interesting thing to see how replays are handled in Hawk.

Similar to Hawk, HTTP digest authentication is also designed to work without TLS. Digest authentication uses a server-generated nonce and a nonce counter to defend against replays. How the server generates the nonce is left to the implementation. A server can store the nonce and look up a store to see if the nonce it received is a nonce it generated and take the corresponding timestamp (if stored together) and determine if the nonce is fresh or not. If the nonce is stale, a new nonce is generated and sent back with a 401.
Read More…

This is continuation of my previous post Basic Authentication with ASP.NET Web API Using OWIN Middleware, where I implemented HTTP basic authentication in a custom OWIN middleware class AuthenticationMiddleware that derives from the OwinMiddleware class. However, when it comes to implementing authentication in an OWIN middleware, the recommended approach is to use the authentication micro-framework that Katana has and derive from the out-of-box middleware class AuthenticationMiddleware<T>. Of course, this special authentication middleware also derives from OwinMiddleware, like so.
Read More…

One of the decisions to be made while implementing authentication for ASP.NET Web API is where to implement the authentication logic – message handler, authorization filter or HTTP module. Authorization filter is a bad choice for the obvious reason that it is for authorization and not authentication. For message handler versus HTTP module, a good read is the ASP.NET site itself. A rule of thumb is to use an HTTP module if Web API is going to be exclusively web-hosted and to use a message handler otherwise. One of the greatest advantages of a message handler is that it is host-agnostic but the downside is that the principal set in the message handler reverts back to the previous principal when the response leaves the web API pipeline. If you use IIS logs, for example, it will know nothing about the principal you set in the message handler. HTTP module locks you into IIS but it has it’s own advantage. Notable one being the fact that IIS/ASP.NET does recognize the principal set from the HTTP module. For host-agnostic reasons, in the book that I have written Pro ASP.NET Web API Security, I have extensively used message handlers. Read More…

This is continuation of my earlier post on implementing Hawk authentication for ASP.NET Web API using Thinktecture.IdentityModel.45.

One of the primary design goals of the Hawk scheme is to “simplify and improve HTTP authentication for services that are unwilling or unable to deploy TLS for all resources”. It is highly recommended to use TLS (HTTPS) even with Hawk but the design goal of Hawk is to ensure the working of the scheme in the absence of HTTPS as well. I covered the basics of Hawk and how the request payload can be protected by Hawk. In the absence of TLS, a man-in-the-middle (MITM) can tamper with the web API response even if the request is protected. One of the key aspects related to preventing the responses getting tampered is the response payload verification and it works like this.
Read More…

Older Posts »



Get every new post delivered to your Inbox.