We live in 21st century, don’t we! I am a firm believer that from now on no user shall ever create a new username/password combination again. Ever! There are already enough existing online identity providers – such as Google, Yahoo, Facebook, Microsoft Account (formerly know as Live ID), Office365, OpenId, Twitter, LinkedIn, national identity providers such as NemID in Denmark, and so on, and so on.
I do believe that every single internet user has profile with at least one of these Identity Providers. And if you, dear reader, do not have any existing online profile, please do leave a comment, but be honest!
All of the developers, architects, decision makers, by all means we shall respect this fact!
I do respect it. In every single project I face I do my best to convince decision makers that it is always better to respect users and give them opportunity to use an existing online identity when there is a need to protect some parts of the application we develop. And way I do it, is by evangelizing Windows Azure Access Control Service, which is now part of Windows Azure Active Directory. I’ve written a number of articles on that subject (Introduction to Claims, Securing ASMX web services with Claims and SWT tokens, Online Identity Management via Windows Azure ACS, Unified Identity for Web Apps – the easy way, Creating custom login page for Federated Authentication with Windows Azure ACS) and yet I see people unaware of such service and do want to implement their own ASP.NET Membership Provider.
I also see people willing to embrace the service. They go their way through the Identity and Access Tool for Visual Studio 2012 and create their first web application with federated login. While the tool is great in its core – by doing what it is supposed to do, it yet hides a lot of process information and does not give you a complete log of what it did. There is one very neat option – create a local Controller with custom Login View:
While this option is great, it misses one very core feature – the log off feature! So you happily created your federated sign in, configured Identity Providers, etc. Now you login to test. Next you click the default [log off] link in your web app. And … you are still logged in! What the hack? You will ask.
Well, when using Federated Log-in, we also have to use a Federated Log-Off (or Sign Out). For this, we have to edit our default log-off method and add one single line. Imagine the default Log Off method looks like:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult LogOff()
{
WebSecurity.Logout();
return RedirectToAction("Index", "Home");
}
We only have to add:
FederatedAuthentication.WSFederationAuthenticationModule.SignOut();
So the final Log Off will be like this:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult LogOff()
{
WebSecurity.Logout();
FederatedAuthentication.WSFederationAuthenticationModule.SignOut();
return RedirectToAction("Index", "Home");
}
And voliah! We are done. Now we can also successfully log off the web application. Note that FederatedAuthentication type is part of the System.IdentityModel.Services assembly and you must add a reference to it.
Couple of things to pay attention to and remember:
- Identity And Access menu item (result of Identity and Access tool installation) will only be visible for web projects targeting 4.5 Framework!
- You have to reference System.IdentityModel.XX (4.0.0.0) assemblies and not Microsoft.IdentityModel.XX (3.5.0.0) assemblies in your project. Failing to do so, you may see unexpected behavior and even errors and failures. Very often if you upgrade your project from .NET Framework prior 4.5 to .NET Framework 4.5 there are references left to Microsoft.IdentityModel.XX – remove them explicitly!
- Do respect your users’ existing online identities! The users will respect you, too!
.