I saw this rather interesting question in StackOverflow. Thought I’ll try to answer it in the form of a post here. Okay, the question is how to access the identifier of the identity established by FormsAuthentication (ASP.NET Membership Provider). I’m not going to discuss the suitability of Forms Authentication for Web API but just try to get a solution to the problem.

Happy to announce that the book I have written for Apress, “Pro ASP.NET Web API Security” is published and is available in Amazon.

My heart felt thanks to Dominick Baier, thinktecture for all his help and guidance, including taking time from his busy schedule to write the foreword for this book. Thanks to Ewan Buckingham, lead editor  and Mark Powers, coordinating editor from Apress for all the help in getting this book published. Special thanks to Barbara McGuire, our developmental editor.

Cross-site Request Forgery (CSRF) is typically linked to cookies. When you develop RESTful services with ASP.NET Web API, chances are likely that you are keeping away from cookies. Yet, ASP.NET Web API based services can be prone to CSRF attacks.

So, you have made the decision to use SWT token as bearer token to access OAuth 2.0 protected ASP.NET Web API. If you are not that specific about SWT and any access token is okay, head out to DotNetOpenAuth. To the best of my knowledge and belief, DNOA does not support SWT tokens but if that is no concern, DNOA is the best path to take – no point in reinventing the wheel. If you are keen on using SWT as bearer token through OAuth 2.0, do stick around.

Kinect and Reactive Extensions (Rx) are made for each other – one pumps events and the other one handles them. I was working on a WPF application using Kinect. One of the screens have to (a) track the user in front and show him/her in motion more like an infrared image, (b) show a ticking timer and (c) track the skeletion points and continously compute angles and apply some business logic. Too much for one screen! Doing everything in the UI thread will be a disaster and I was in need of more threads to handle these things but ultimately the end result of all the processing is UI getting updated. Doing this by creating my own threads will result in sub-optimal code. Rx to the rescue.

This is the final installment of the series of posts on digest authentication. I have covered the basics or theory in the first post and some C# code in the second post. In this, I’ll cover the security aspect, especially how we can try to break the digest authentication.

This is continuation of my earlier post. Similar to basic authentication, we will use a delegating handler to implement digest authentication with ASP.NET Web API. When the handler returns a 401, it generates a server nonce and sends that back as part of the WWW-Authenticate header payload. Sequence is below.

We have seen basic authentication in one of my previous posts. Basic authentication is simple. It just sends the user credentials in the HTTP header. If HTTPS is not used, the credentials will be available for every one to see. ASP.NET Web API that uses basic authentication can be tested through the browser itself. When the browser makes a GET request, it first gets a 401 response with WWW-Authenticate : Basic header. No body knows HTTP better than a web browser! So, my browser now knows that it has to send the credentials in the HTTP header using basic scheme. So, my browser, IE in this case, pops up a dialog, gets the credentials, packages the same  in the correct format and sends it to the server.

SQL Server Express is free and ideal for development purposes. When a developer exclusively uses the SQL instance, there is tighter control over the queries executed and there is no real need for a tool to trace the queries. This is typically the case, when the developer hand codes the queries. However, the situation is different when an ORM like Entity Framework is used. There are times when a developer has to understand the queries generated by the EF. Regular SQL Server comes with a profiler but unfortunately SQL Express lacks the same. It is a problem but can be easily solved.

Simple Web Token – name says it all. It is a token, it is for web (read HTTP) and it is simple! Then, there is good old SAML token, which is XML based. If there be light, then there is darkness; if cold, heat; if height, depth… If XML, JSON; so, there is a JSON web token (JWT) as well. SAML is more SOAP-ish and SWT and JWT are REST-ish.

Naturally, SWT is a good choice for ASP.NET Web API. Using OAuth 2.0, SWT can be sent in the HTTP authentication header (bearer scheme). That topic is too big for a single blog post. So, let’s focus on just SWT and look at using SWT as a bearer token through OAuth 2.0 hopefully in a future post. There is a great open source library for OAuth 2.0 – DotNetOpenAuth but my understanding, as of the time of writing this blog post is, SWT is not supported by DotNetOpenAuth for OAuth 2.0.

Anyways, let’s get on with dissecting a SWT.