Category Archives: English

ASP.NET OpenID/OAuth Login With ASP.NET 4.5 – Part 1

With ASP.NET 4.5 it is very easy to enable users to login to your site with their accounts from Facebook, Google, LinkedIn, Twitter, Yahoo, and Windows Live. In this 7 part series I’ll show you how for each of the identity providers.

Note: Out-of-the-box this only works with WebForms and MVC4. MVC3 is not supported by default.

Part 1: Setting up your development environment

Create a website project in Visual Studio

You’re going to need a website project for any of this to work, and you may have to configure some of it later. So first, let’s create a project.

  1. Fire up Visual Studio (Express will work just fine).
  2. From the menu select FILE > New Project…
  3. Select one of the Web Application projects. In this example I’ll use ASP.NET MVC 4 Web Application.
  4. Click OK.
  5. Select Internet Application. This is the only template that includes the OpenID/OAuth stuff by default.
  6. Click OK.
  7. The project is ready. You may want to run it once just to make sure everything works. Be sure to click Register and then register for an account to see if the database is working.

Setting up your development environment

In most cases you need to register you website with the identity provider to be able to authenticate users with that identity provider. The provider will ask for several pieces of information, most notably a URL. The problem is that this can’t be an IP-address, and can’t be localhost. Most identity providers also don’t allow a port number, so you will have to ensure that your development website can be reached at port 80 (or port 443) and on a valid URL.

Getting a valid URL

Getting a valid URL is mainly about using a domain that an identity provider will recognize as valid and public. You can get one setup for your application in three ways:

  1. Modify your hosts-file to contain the desired URL.
  2. Open notepad as Administrator.
  3. Click File > Open and navigate to the C:\Windows\System32\drivers\etc folder.
  4. Select All Files (*.*) as filter so the files with no extension show up, as shown below.
  5. Open the hosts file.
  6. Add a line for IP-address with the domain you want to use with your application, as highlighted below.
  7. Save the file.
  8. Use a public domain of your own and modify add a DNS entry for your application. How this works depends on your hosting provider, so I won’t elaborate in this.
  9. Use the domain. This is a very neat trick by some clever guys. They’ve setup a DNS that will route any request to, your local computer. That includes the root domain itself, but any subdomain or sub-sub domain (or sub-sub-sub domain… you get the idea), will work. The only domain that doesn’t work is, because that’s where you can find the documentation and background. The great thing is that this works without registering or anything. For my demo’s I will use

Setting up IIS

Besides having a public domain, your application needs to run on port 80. Although this is possible with IIS Express, it is much easier using IIS (if you want to tinker with IIS Express, check Scott Hanselman’s post Working with SSL at Development Time is easier with IISExpress). The one proviso is that IIS can’t work with LocalDB, so you will have to use SQL Server (Express) instead. For the description below I will assume you have SQL Server Express installed. The best way to go about this is creating a new Web Site in IIS with a custom host header. The steps are easy:

  1. Start the IIS Manager.
  2. In the Connections pane navigate the tree to the Sites folder.
  3. Right click Sites and select Add Website…
  4. Set the Site name and under Physical path browse for the application folder created by Visual Studio.
  5. Under Host name set the host header, in my case
  6. Click OK.

Now you need to point Visual Studio to use IIS, instead of IIS Express when you debug.

  1. Open your project in Visual Studio (if not already open).
  2. Right click the project and select Properties.
  3. Select the Web tab, and scroll down to where it says Use Local IIS Web server.
  4. Uncheck Use IIS Express.
  5. You will be warned that you can’t use LocalDB with IIS with the dialog below. Click Yes.
  6. Enter the Project Url, in my case The settings now should look like the image below.
  7. Click Save.
  8. Start the project in debug mode to verify that everything is working under the specified URL.

Although IIS points to the right folder, it needs permissions to read the folder. If that is not the case, you will get a HTTP 500.19 error when you run the application. You can solve this as follows:

  1. Open Windows Explorer.
  2. Navigate to the application folder.
  3. Right click on the application folder and select Properties.
  4. Go to the Security tab and ensure IIS_IUSRS has read permissions. If so, skip the next steps.
  5. Click Edit…
  6. Click Add…
  7. Enter IIS_IUSRS and click OK.
  8. Click OK twice.

Book Review: Async in C# 5.0

Async in C# 5.0 (Alex Davies, O’Reilly) is good read of you plan to do parallel or async programming, although a bit theoretical. The book shows you why asynchronous programming is a little more than just using the new async and await keywords. These keywords make asynchronous programming syntactically simple, but as this book shows through meticulous explanation there is much more than meets the eye. The book starts of with just showing you how async and await works, and then shifts gear to show you how asynchronous programming worked before we had these keywords. This makes you appreciate all the heavy lifting done for you, but it also makes you understand why asynchronous programming is something you need to do with care. Then there’s several chapter about what’s going on and which pitfalls you can run into (and how to avoid them). The strength of this book is the excellent theoretical handling of the topic. The weakness is the lack of practical examples and a high-level view on when and how to use asynchronous constructs.

Intercepting a 404 in IIS 7 and up

Lately I’ve been working on a system that needs to serve flat files, which is what IIS is very good at. However, when a file does not exist (i.e. a 404 error occurs) there are several options:

  1. The file never existed: propagate the 404.
  2. The file did exist, but has been permanently removed: return a 410 (Gone).
  3. The file did exist, but a newer version is available. In our system a different version always gets a new identifier and as such a new URL, so this is a common scenario for us: redirect the user to the new version.

So the question is: How do we intercept the 404 error for any file?

The answer: With an IIS HttpModule, which is pretty much the same as an ASP.NET HttpModule, as the code below demonstrates.

using System;
using System.Net;
using System.Web;

namespace IisModule
    public class DemoModule : System.Web.IHttpModule
        public void Dispose()

        public void Init(System.Web.HttpApplication context)
            context.EndRequest += new EventHandler(context_EndRequest);

        void context_EndRequest(object sender, EventArgs e)
            var context = (HttpApplication)sender;
            if(context.Response.StatusCode == (int)HttpStatusCode.NotFound)

The only place where you can check for a 404 error is at EndRequest. Other events get bypassed, including the Error event. However, as you can see in the code, getting the response code is easy. And after checking it you can do a redirect or change the response and response code (don’t forget to clear the response stream). You need to add this code to a Class Library project in Visual Studio, to which you will have to add a reference to the System.Web assembly. Also, this does not work with .NET 4.0 and up (except in Windows Server 2012), so you’ll need to configure the project to target the .NET 2.0 runtime, which is the case for .NET 2.0 through 3.5, as is shown below.

Configuring IIS

First you have to create a /bin folder in the website you want the module to work in, and copy the DLL to the bin folder. If you want this on the Default Web Site, you need to add this to C:\inetpub\wwwroot (assumming C is your OS drive), as shown below.

Second, you need to fire up IIS Manager to add the Managed Module to the Web Site. Select the Website (in my case Default Web Site) and select Modules, as highlighted below.

Now click Add Managed Module… as highlighted below.

Finally, give the new module a name, so you can recognize it in the list of modules active for the website, and select the module in the dropdown, as shown below, and click OK.

That’s it! Now every 404 will redirect the user to the root of my blog.

Configuring IIS for all sites

If you don’t want to have a /bin folder in your site, and all sites hosted on the system require the same behavior, you can also sign the assemly, place it in the GAC, and configure the Module at server level.

Book Review: Programming Microsoft SQL Server 2012

Programming Microsoft SQL Server 2012 (Leonard Lobel and Andrew Burst; Microsoft Press) is an excellent book if you want to learn the ins and outs of SQL Server. The book is meticulous when it comes to explaining SQL Server features. Much of this is because of the elaborate examples and the detailed explanation of what’s going on. This attention to detail is however both its strength and its weakness. If you already know about database development, you already know much of what is being explained. For instance, you already know what transactions are for and how they work. Explaining the subject as if you’ve never seen a database feels a little overdone. This is also where the book is a little ambiguous. The chapter that deals with T-SQL, only covers the newer T-SQL statements, so you are expected to have prior knowledge. Of course finding the right balance is hard, and this is a good book regardless. It just means that if you already know the topic, you can just skip to where the content is new. It also means that the book is an excellent reference. In fact, reading this book from beginning to end might not be the best use. Explore it for new features, and then keep it around.

Book review: Building Hypermedia APIs with HTML5 and Node

Building Hypermedia APIs with HTML5 and Node (Mike Amundsen; O’Reilly Media) is an interesting little book. It covers designing an online system that operates well in a browser, but works equally well when talking to
from another type of application, which also has positive impact on automated testing. The strength of this book is absolutely the design theory, which is explained very well. The theory applies to pretty much any web development platform, which is where the weakness of the book comes in. If you are not an HTML5 or Node developer, and many of us aren’t, reading through the practical part of the book is somewhat tedious. That said, the book is only 244 pages, and the theory is an easy read. That means that if you are only interested in that you can get through pretty quickly. The examples in itself are simple, but already add up to quite a bit of code you need to wade through. Understanding all that’s going on takes a while.

Dealing with Token Timeout in Windows Identity Foundation

When a Security Token Service (STS) creates a token, that token has an absolute expiration. Usually this is about 60 minutes, after which the Relying Party (RP) has to send the user back to the STS to acquire a new token. When using Windows Identity Foundation (WIF) in ASP.NET (so for passive federation), this is the default behavior, because the SessionAuthenticationModule stores the token in the FedAuth cookie and checks that token on each request.

What’s the problem?

I hear you thinking “Cool, WIF takes care of all that for me”, and that is cool. But there’s also a nasty side effect, one which all web developers have encountered in a different context: sessions. If a user logs in, starts filling out some form, and then gets interrupted by a phone call, chances are that the session expires. This can lead to problems when the user submits the form, because the user has to log in again. The original posted data gets lost in the process, much to the frustration of the user. Because sessions use sliding expiration the problem is minor. But with absolute expiration, expiration can wreak havoc even if the user posts a form just a minute after the form was presented to the user.

Solving the problem

There are several ways to solve the problem outlined above:

  1. Don’t use the SessionAuthenticationModule.
  2. Modify the stored token to implement sliding expiration.
  3. Force reacquiring a token in the background, so you can control when this happens.

Ditching the SessionAuthenticationModule

Not using the SessionAuthenticationModule appears to be simple. Just remove it from web.config and you’re done. However, if you remove it, you have to ensure a user stays logged in after receiving the token, and you need to keep track of the received claims. This means you need to use a cookie or session data to keep track of the user. Basically you would be recreating what the SessionAuthenticationModule does for you for free.

Making token expiration sliding

This is actually easier than ditching the SessionAuthenticationModule. All you have to do is handle the SessionSecurityTokenReceived event and modify the ValidTo property of the token, as shown in this MSDN Forums post.
Tip: You can hookup the event in the Application_Start event in global.asx using FederatedAuthentication.SessionAuthenticationModule to point to the module.

Force reacquiring a token

The above methods work fine, but have some drawbacks. One of these is the fact that Single Sign-On (SSO) no longer works properly if a user spends too long in a single application. This is because the login session with the Identity Provider will expire at some point. Another issue arises if you want to use delegation or impersonation when you call a web service. WS-Trust 1.4 supports delegation (ActAs) and impersonation (OnBehalfOf). Even though WIF officially implements WS-Trust 1.3, WIF does support these constructs. When calling web services from a web application, using delegation is a recommended practice, because it greatly improves the security. The reason is that in order for the web application to make the web service call on your behalf, it needs to acquire a token from the STS, based on the original token. This means a malicious user would need that token in order to make the web service call. Breaking into the web application is not enough.

So, how can you ensure you get a new token once in a while? Although the implementation is somewhat more difficult, the principle is simple: logout of the RP. That triggers the RP to re-authenticate the user by redirecting to the STS. As long as the user is still known in the STS, a new token is transparently given out. You can do this in roughly two ways: in an invisible iframe that does this process under the covers or in the main request stream. The latter is more visible to the user and requires you to bring the user back to where he was before the logout was forced, which is slightly more complicated than a simple redirect. The iframe solution is more elegant, because it does not interrupt the main working process. Basically all you have to do is point the iframe to a handler that logs the user out if necessary, triggering the re-authentication process when necessary and coming back to the handler to produce an empty HTML page. The handler to do this is shown in the code below.

using System;
using System.Configuration;
using System.Globalization;
using System.IdentityModel.Tokens;
using System.Threading;
using System.Web;
using Microsoft.IdentityModel.Claims;
using Microsoft.IdentityModel.Web;
namespace WebApp
    /// HTTP Handler triggering token renewal when this is necessary.
    public class TokenRenewalHandler : IHttpHandler
        /// The default number of minutes before the token expires when renewal should be triggerd.
        private const int DefaultTokenRenewalWindow = 20;

        /// Value container for the TokenRenewalWindow
        private int m_TokenRenewalWindow = 0;

        /// Number of minutes before the token expires when renewal should be triggerd.
        /// Should be less or equal to the session timeout.
        protected int TokenRenewalWindow
                if (m_TokenRenewalWindow == 0)
                    int securityTokenRenewalWindow;
                    if (!int.TryParse(
                           NumberStyles.Integer, CultureInfo.InvariantCulture,
                           out securityTokenRenewalWindow))
                        securityTokenRenewalWindow = DefaultTokenRenewalWindow;
                    m_TokenRenewalWindow = securityTokenRenewalWindow;
                return m_TokenRenewalWindow;

        /// Handles the HTTP reqyest and forces a signout to renew the token if necessary.
        public void ProcessRequest(HttpContext context)
            SecurityToken token = null;
            IClaimsPrincipal principal = Thread.CurrentPrincipal as IClaimsPrincipal;
            if (principal != null && principal.Identities.Count > 0)
                token = principal.Identities[0].BootstrapToken;
                if (token != null)
                    DateTime tokenExpirationTime = DateTime.Now.ToUniversalTime().AddMinutes(TokenRenewalWindow);
                    if (token.ValidTo.ToUniversalTime().CompareTo(tokenExpirationTime) < 0)
                        if (FederatedAuthentication.WSFederationAuthenticationModule != null)
                            // Force sign-out.
                        // Redirect to this handler to force a new sign-in request to the STS
                        context.Response.Redirect(context.Request.RawUrl, true);
            // Return an empty HTML page
            context.Response.ContentType = “text/html”;

        public bool IsReusable
            get { return false; } }

Common Windows Identity Foundation misconceptions

I am on crusade to get Windows Identity Foundation (WIF) adopted by the Microsoft .NET community at large. Why? Because maintaining a user store within an application as is propagated by ASP.NET Membership is just plain stupid these days. Yes, I may be a little harsh with that judgment, but sparing the rod spoils the child. Applications should no longer be islands, but should be working together. And if applications such as Spotify and Flickr can (re)use a user’s identity from Facebook, Twitter, LinkedIn, and so on, why can’t yours?

“A thousand mile journey begins with one step” – Lao Tze

In the past couple of years I’ve been speaking about WIF on many occasions, both at conference and with individual developers. Across the board I can say that WIF is largely misunderstood. Hence my first step is to address some of the misconceptions surrounding WIF, and more in general the concepts underlying WIF.

Misconception 1: WIF is Microsoft-only and not interoperable.

WIF actually implements the WS-Federation standard. Microsoft is an active participant in the standards commonly known as the WS-* specifications, a host of web services specifications for security, transactions, and reliable messaging. The WS-Federation standard is implemented by many other platforms, and WIF can interoperate with these just fine.

Misconception 2: WIF can only be used to secure web applications, not web services.

The WS-Federation protocol defines two profiles: Active and Passive. Passive federation is for browser based applications, because browsers don’t support the full cryptographic stack required for WS-Federation to work. Active federation is used for web services and can be used with clients that do support the needed cryptographic capabilities. I’ll get back to what this all means in another post.

Misconception 3: WIF can only be used to secure web services, not web applications.

See misconception #2.

Misconception 4: WIF is only for cloud (Azure) applications.

WIF works with any application written in .NET 3.5 and up. You can host that application anywhere you like, in the cloud or in your own data center. In fact, there is nothing that prevents you from creating applications with WIF for use in just the local network and for internal use only.

Misconception 5: You can’t do role-based security with WIF.

Quite the opposite is true. You can still do role-based security if you want to, but you can do much more. The underlying protocol is much more flexible, and you can implement security checks in your applications based on the information you get about a use any way you like.

Misconception 6: WIF only adds complexity.

It is indeed true that properly connecting a WIF enabled application to a security token service can be a challenge. You need to get the protocol settings to match and need certificates for encryption and signing. However, inside your applications WIF is just as easy as role-based security as you are used to. If you want to do more elaborate things, things obviously get more complex, but this is true for any type of security.

Misconception 7: To use WIF in an existing application I need to re-architect the whole application.

WIF extends the IIdentity and IPrincipal interfaces. This means that your existing application will keep working if you migrate to WIF to get authenticate and authorize the user. The only thing you need to be aware of is the fact that because you don’t have a local user directory anymore, you can’t do things for which you require information about another user. This means you may have to provide a different way to deal with such scenarios. If you use ASP.NET Profiles for this kind of information, a custom provider may be all you need.

Book Review: Programming Amazon EC2

Programming Amazon EC2 by Jurg van Vliet and Flavia Paganelli is practical in nature and takes you through all the steps to create and configure accounts, develop applications, and deploy applications. If you’re new to Amazon EC2 (and related services) this is definitely a good place to start, because it goes through all the components Amazon offers, such as S3/Cloudfront and RDS for data storage. It also looks at how you can setup your application to scale up and down, and ensure your application has excellent uptime. The book takes you by the hand based on some applications the authors have created themselves. Although this approach makes the book practical, it sometimes reads as (irritating) marketing for their applications.

Who is running my Workflow Service?

Workflow Services in .NET 4 allow you to do long running processes. But when you do that, there’s an interesting question: when a workflow has been suspended, under which user is the workflow running when it is active again. To answer this question I created a simple workflow that writes the user in the current thread to a log. On the initial call, the user making the call was logged (in this case I used Windows Identity Foundation to authenticate, but this should be the same for all types of authentication). After a Delay of a minute that user was gone, and instead the user in the current thread was unauthenticated. This means that any code you call from the workflow can’t rely on Thread.CurrentPrincipal to get the proper authorizations. You have to save the user, and somehow reinstate principal so it runs under the original context. Alternatively you can use some form of delegation.

Solving: Could not establish trust relationship for the SSL/TLS secure channel …

Working with Windows Identity Foundation can be quite a minefield. Solve one issue, and the next creeps up. Because it’s all these little tweaks to make it work, I often find myself thinking “How did I solve that last time?” One of those issues is the following exception:
Could not establish trust relationship for the SSL/TLS secure channel with authority ‘somesite.runningunder.ssl’
There are two reasons why you can run into this exception, each discussed below.

The certificate isn’t trusted and/or the URL doesn’t correspond with the URL in the certificate.

If this is the case, you get certificate warnings when you browse to the service WSDL with a browser. The best way to solve the former is to have your (development) environment work with certificates it trusts. This means setting up a Certificate Authority (Active Directory Certificate Services), placing the root CA certificate in the Trusted Root Certificates of the machine your clients (and services) run on, issuing the needed certificates from the CA, and placing these where they are needed. Alternatively, you can just add a
single line of code to your client so it ignores certificate issues before you do any service call:

System.Net.ServicePointManager.ServerCertificateValidationCallback =
    ((sender, certificate, chain, sslPolicyErrors) => true);

If after you’ve done the above you still get an exception, the above code is likely not even being hit. That means you (also) have the problem below.

You’ve setup identity trust in your client, and the certificate reference is incorrect.

This often happens when you copied some configuration from somewhere, and forgot to change the corresponding certificate reference. The red stuff in the client configuration below (which is much longer in a real configuration) is the culprit. It should contain the encoded certificate.

    <endpoint address="https://YourServer/Service1.svc"
        <certificate encodedValue="MIIF5jCCBM6gAwIBAgIKYSt2tQA..."/>

To solve this, you need to get the base64 encoded certificate string, and paste it in place of what’s in there now. To get it you can do the following:

  1. Browse to the endpoint with your browser.
  2. View the certificate information.
  3. Save the certificate to file.
  4. Open the certificate with notepad.
  5. Copy the encoded value between the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– placeholders.