ASP.NET Identity Lockout

This is another case for why naming things is hard. It might seem obvious to some but I definitely didn’t get this one right away, and I wasn’t the only one.

The LockoutEnabled flag in the ASP.NET Identity 2.0 model means that the user can be locked out, not that the user is locked out.

For a user to be locked out the LockoutEnabled must be true and LockoutEndDateUtc must be greater than the current date. To enable Locking out globally you must set UserLockoutEnabledByDefault to true on the UserManager:

public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)
{
    var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>()));

	// Enable Lock outs
    manager.UserLockoutEnabledByDefault = true;
    manager.MaxFailedAccessAttemptsBeforeLockout = 5;

    // if you want to lock out indefinitely 200 years should be enough
    manager.DefaultAccountLockoutTimeSpan = TimeSpan.FromDays(365*200);

	....
}

This one was easy to figure out. Because the Microsoft ASP.NET Identity Team is tracking discussions publicly I was able find a work item with a google/bing search. At least they didn’t name it LockoutManager.

Abstractions and IoT

With the click of a few buttons we can have a scalable website set up in minutes. By linking a few hardware components together we can make plants sing and coffee pots that tweet.

Abstraction

Over the years the abstraction level at which we can build our projects has been increasing. We are seeing this at the hardware level and the software level.

At the hardware level, we have composable boards that we can leverage to do heaving lifting such driving motors and providing GPS.

At the software level the abstractions are being provided in the libraries we use. For example, with SignalR we can provide real time capability to our applications with out having to worry about the protocols every device supports. Another exciting set of libraries that is enabling us to write complex asynchronous code simpler is ReactiveX.

Internet of Things (IoT)

There is a buzz in the air right now about the Internet of Things (IoT). It is on everyone’s minds and there is quite a bit of hype. Although tweeting coffee pots catches the media’s attention, there will be a lot more IoT devices that provide a lot of value.

Along with highly available internet access, smaller/faster devices and a host other energy and power saving advances, the abstractions that have been built over the years is one of the key components that is bringing around the IoT revolution. We don’t have to worry about how to communicate with GPS satellites or how to design a scalable infrastructure, it has been done for us.

As developers this is an exciting time. We have some amazing tools to work with and we get to focus on how to bring these abstractions together in new and exciting ways.

In what ways will you bring the powerful abstractions together?

ASP.NET Identity Custom Database and OWIN

This is a two post series. You may like to read the first post ASPNET Identity and Custom Database.

In the last post, we covered how to create a custom SigninManager. At first glance there was a lot of work to be down but after diving in we found that there were only a few simple classes we had to set up.

In this post, I will demonstrate how to use OWIN to load our SigninManager for each request. By the end of the post we will have a SigninManager that we can use to create an authentication cookie and sign a user into our system.

OWIN Middleware

The latest version of ASP.NET is setup to use the OWIN middleware. If we take a look the Startup.Auth.cs file in the App_Start folder we will find an example of the out-of-the-box SigninManager configuration:

public void ConfigureAuth(IAppBuilder app)
{
    app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
    app.CreatePerOwinContext<ApplicationSignInManager>(ApplicationSignInManager.Create);

	//left other configuration out for brevity
}

The app.CreatePerOwinContext<T>() creates one instance of the given type per request. This way we only have ApplicationUserManager and one ApplicationSignInManager around for each request. To configure our CustomUserManager and CustomSignInManager we need to create factory methods and add them to the Startup.Auth.cs.

It is important to note the order in which the app.CreatePerOwinContext<T>() is called in the configuration. Since a SigninManager requires a UserManger the call to create the SigninManager on the OWIN context must come after the call to create the UserManager

The app.CreatePerOwinContext<T>() can take two different types of methods (We will see each type of callback method when we create them):

  1. Func<T> createCallback
  2. Func<IdentityFactoryOptions<T>, IOwinContext, T>

UserManager Factory Method

The UserManager method is the first callback method type; a simple static method that returns a new CustomUserManager. It would be possible to configure a method that also returns the CustomUserDataContext and pass it to the store. To keep it simple and show both types of methods app.CreatePerOwinContext<T>() takes I have left it out.

public static CustomUserManager Create()
{
    var manager = new CustomUserManager(new CustomUserStore());
    return manager;
}

SignInManager Factory Method

The SigninManager has a the second callback type but is again not too complex:

public static CustomSignInManager Create(IdentityFactoryOptions<CustomSignInManager> options, IOwinContext context)
{
    return new CustomSignInManager(context.GetUserManager<CustomUserManager>(), context.Authentication);
}

OWIN Configuration

The configuration is very similar to the out-of-the-box configuration. In the Startup.Auth.cs file we add our custom managers:

public void ConfigureAuth(IAppBuilder app)
{
    app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
    app.CreatePerOwinContext<ApplicationSignInManager>(ApplicationSignInManager.Create);

	// Add our custom managers
	app.CreatePerOwinContext<CustomUserManager>(CustomUserManager.Create);
    app.CreatePerOwinContext<CustomSignInManager>(CustomSignInManager.Create);
}

Use in a Controller

And to use it in a Controller add the following property to the Controller class which uses the HttpContext to get our single instance per request. The private set allows you to create a Controller Constructor where you can pass a mock instance for testing.

private CustomSignInManager _signInManager;
public CustomSignInManager CustomSignInManager
{
    get
    {
        return _signInManager ?? HttpContext.GetOwinContext().Get<CustomSignInManager>();
    }
    private set { _signInManager = value; }
}

Now in your your Login Action use it:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
   // do model validations, password compare and  other checks then sign them in

	//creates and signs a cookie.
	 CustomSignInManager.SignIn(customUser, isPersistent: true, rememberBrowser: false);
}

Hope that helps clear up some of the steps that are required to create an authentication cookie against an existing database.

ASP.NET Identity 2.1 Custom Database

This is a two post series. You can read the second post at ASPNET Identity Custom Database and OWIN.

I have to admit when I first took a deeper look at the ASP.NET’s Identity model in version 2.1 I was a bit overwhelmed. I was looking for a way to authenticate a user against an existing database using Forms authentication to create an authentication cookie after verifying the user’s credentials. Looking at the template ASP.NET Individual User Accounts I found that the SignInManager was responsible for creating the authentication cookie and so I started there.

I found that the SignInManager constructor required a UserManager which in turned required an implementation of IUserStore. And so I went in search of a way to implement my own UserStore by look at the Entity Framework User Store. When I saw the number of interfaces Entity Frame works UserStore implemented I froze. Would I know what to implement and how?

IUser<TKey>

So I took a few deep breaths and when went back to the SigninManager. I would start there and see what was need to implement it. Using the existing SigninManager as a reference, I found I need to have a IUser<TKey>. This is easy enough:

public class CustomUser : IUser<string>
{
    public string Id { get; set; }

    public string UserName { get; set; }
}

UserManager<TUser>

Next the SigninManager constructor takes a Usermanager. Again this was a fairly simple implementation:

public class CustomUserManager : UserManager<CustomUser>
{
    public CustomUserManager(IUserStore<CustomUser> store)
        : base(store)
    {
    }
}

SigninManager<TUser, TKey>

Now we have all the piece to be able to put together the SigninManager:

public class CustomSignInManager : SignInManager<CustomUser, string>
{
    public CustomSignInManager(CustomUserManager userManager, IAuthenticationManager authenticationManager)
        : base(userManager, authenticationManager)
    {
    }
}

IUserStore<TUser>

The astute reader will have notice that we missed the implementation of the IUserStore<TUser> for the CustomerUserManager. This again is a very quick implementation of a few CRUD operations (I have left some of the implementation blank and the others are not production ready):

public class CustomUserStore : IUserStore<CustomUser>
{
    private CustomDbContext database;

    public CustomUserStore()
    {
        this.database = new CustomDbContext();
    }

    public void Dispose()
    {
        this.database.Dispose();
    }

    public Task CreateAsync(CustomUser user)
    {
        // TODO
        throw new NotImplementedException();
    }

    public Task UpdateAsync(CustomUser user)
    {
        // TODO
        throw new NotImplementedException();
    }

    public Task DeleteAsync(CustomUser user)
    {
		// TODO
        throw new NotImplementedException();
    }

    public async Task<CustomUser> FindByIdAsync(string userId)
    {
        CustomUser user = await this.database.CustomUsers.Where(c => c.UserId == userId).FirstOrDefaultAsync();
        return user;
    }

    public async Task<CustomUser> FindByNameAsync(string userName)
    {
       CustomUser user = await this.database.CustomUsers.Where(c => c.UserName == userName).FirstOrDefaultAsync();
        return user;
    }
}

Next Steps

We have now implemented all the parts required to create a Custom SigninManager. The initial feeling of being overwhelmed with the number of interfaces to implement has gone away. It was actually quite simple to create all the pieces to create our own SigninManager. Stay tuned for the next blog post where I show how to hook it into the OWIN Middleware so we can use it to sign our user in and create our Authentication Cookie.

Visual Studio Extensions AceJump

This week I released my first Visual Studio Extension AceJump. I was inspired by a version of AceJump build by John Lindquist for the JetBrain tools. I first saw him use AceJump in his tutorial video’s on egghead.io and after installing it on JetBrains Webstorm I knew I needed to have the same functionality in Visual Studio. I searched around the plugins in Visual Studio and didn’t find anything, so I built it.

Visual Studio AceJump

As of this blog post it is a fully functional and has a few rough edges but I decided to ship it anyways. Getting software out to real users is important for the feedback loop. Besides I wanted to start using it myself because it such a cool productivity tool.

It was my first Visual Studio extension so I floundered around in the SDK a bit. It was quite the learning experience and I am not sure I did everything the ‘correct way’. I found once you get beyond displaying a purple square in the top right corner of the editor things get tougher. I have shared the AceJump Code so that you can see something a little more complex or maybe show me a better way.

Usage

It is a really simple to use:

  1. Use shortcut Ctrl + Alt + ; to display a key selector.
  2. Press any letter to highlight occurrences of that letter in the text editor.
  3. Press the new letter in the box that is over the letter you want to jump too.
  4. Your cursor jumps to that spot and you keep coding!

I hope you find this tool as useful as I did when I first used it in Webstorm. Happy Coding!