ASP.NET Identity Security

The new ASP.NET Identity framework provides membership features for your application – well kind of. Compared to the previous membership providers there appears to be not much there. However, do not be fooled. Although, many of the typical membership method calls just don’t’ exist, this new membership implementation is very extensible – which allows you the developer to customize the implementation to your specific needs. You can use SQL Server as your data store, but there are a lot more options now, especially the integration with other social platforms. This ain’t your dad’s membership provider.

Typically, you would create an ASP.NET MVC web application and implement the new ASP.NET Identity within the web application – this means making calls directly from the controllers to the database using the new Entity Framework IdentityDbContext<IdentityUser>. I think for most demos and simple applications this may work fine. However, I like a little more abstraction between the UI, business, and data access “parts” of my application. Therefore, since this new version doesn’t have any dependencies on any web assemblies – I can implement and customize my security in a separate class library.

I start by creating a new C# Class Library project and add the required packages from NuGet to support my custom implementation of AspNet.Identity.

https://www.nuget.org/packages/Microsoft.AspNet.Identity.EntityFramework/1.0.0

image

The NuGet installer also installs other required packages for Identity.

image

IdentityUser :: The ApplicationUser

I start by creating a new entity called ApplicationUser. This entity implements the IdentityUser interface from the Microsoft.AspNet.Identity.EntityFramework namespace. You will need to reference the namespace with a using statement.

image

The IdentityUser interface is shown below with its implementation of the IUser interface – these interfaces provide the default structure for the new user in the Identity framework.

image

image

It is interesting to note that the Id property is a string type. The value stored in the database from the Identity framework looks like a GUID – it is the string representation of a GUID value. It appears that you would have to re-implement the IUser interface and the IUserStore of the Identity framework to make a change to an Id property using an int. I’m not sure if I’m ready to tackle this task yet. I’m trying to leverage as much as possible from the default implementation. See StackOverflow.

UserManager

The AccountController creates an instance of the UserManager<TUser> through its constructor. This class provides all of the methods to manage a specific user via the ApplicationUser class. When the UserManager is created it requires a new UserStore<TUser> where TUser is of type IdentityUser. The UserStore object requires an instance of the IdentityDbContext<TUser>. I would consider the UserStore as the “repository” that uses Entity Framework for database transactions since it depends on the IdentityDbContext. The UserManager is the business end of the managing users. You can imagine that this is where additional data validation and business rules are implemented before making a call to the database using the UserStore<ApplicationUser>, right?

This is why the ApplicationUser entity is so important. It is used to create generic implementations of the UserManager, UserStore, and IdentityDbContext. In the code below, I’m beginning to refactor the Register() method to use the entity defined in my custom project, I will then implement the CreateUser() call using my new SecurityService (code currently commented out).

image

Enterprise Patterns :: Vergosity Framework

I have quite a bit of infrastructure setup already complete using the Vergosity Framework that includes: Business Actions for implementing business logic and the rule engine to take of processing my data validation and business rules. I’m also experimenting with a new set of pattern that take advantage of dependency injection. Therefore, I’m relying a lot on the Autofac DI container to do this for me. The framework also includes Logging of an application error or failed business rule evaluations.

This implementation confirms to me that I can abstract the ASP.NET Identity references from my ASP.NET MVC web application and put the implementation into a new project – this will allow me to reuse the new implementation in other applications.

Code First without dropping the database

I have been using the Entity Framework code first options for a prototype application architecture. I have the database initializer setup called from my unit tests to validate the integration work I’m doing. This is working fine for me now. However, in most enterprise applications the developer would not be responsible for generating the database – much less dropping and re-creating the database and all of the table objects.

Therefore, I’m going to change the approach a little bit. I still want to do code first in terms of setting up my entity classes. However, I want a little more flexibility in working in a team environment where there is a dedicated DBA who is responsible for managing the database objects. The sample database that I’m using for the code first EF contains a table called EdmMetadata. I’m going to remove this table from the database – so that it is not used as part of the initialization. This means my database will not be dropped when the initializer is called.

image

image

I will also remove the call from my unit test Setup() method.

image

The unit test runs and passes – this is good news. Now I do not have the dependency on the database initialization process.

image

Now, I’d like to add a new entity item that maps to a new table in my database. I can define the entity first and create the table object later. You might be wondering why I’m not using the EF tooling. My data access doesn’t contain an .edmx file – I am using a generic Entity Framework Repository<T> pattern with the future possibilities of code generating the plumbing classes later using the entity class as a meta file for the code generator.

New Entity and Database Table

I am now creating a new entity with a matching table in the database.

image

The Coder entity uses a base class for default entity behavior and implements the IEntity interface – which means that there must be an Id property for the entity.

image

Generic Entity Framework Repository

I have some infrastructure repository classes that provide the default implementation of the EF calls for a specified entity. To do the wire-up, I create an interface called ICoderRepository that implements the IRepository<T> class. This will allow me to add an extended behavior not already contained or implemented in the generic repository classes. I also create a CoderRepository class which is the concrete implementation for the Coder entity’s repository. It implements the GenericRepository<T>

image

I do have a DbContext class that the generic repository is using for data access. I just need to let it know about the new entity that I have created. Therefore, I create a partial class for my context CodeDb and add the DbSet<Coder> public property. Note: the name of the DbSet<Coder> property should match the name of the database table – if your database table has a different name, I am sure you can just attribute the table name on the entity itself.

image

Now my CodeDb context will know about my new entity and will be able to perform data access.

image

So, if you are keeping track, we have added (2) classes and (1) interface to implement the EF Repository for the Coder entity. Using this approach will allow me to later generate these plumbing classes and wire-up entity repositories with ease. But without the code generator, it still isn’t that much wire-up. I like the convenience of the Generic Repository and the partial classes to add to the core infrastructure of the DbContext and Repositories. Now that the repository is configured, I can create another partial class that will enable access to the repository from business logic classes. There is no .edmx file to manage or now specialized EF connection strings – we can just use a standard connection string name (note: I send in the name of the connection string only) in the configuration file and the DbContext constructor does the rest.

image

The Wire-Up using Dependency Injection

Now for really cool part. It is all wired-up using dependency injection. The DI container will scan the assembly for specific repository implementations and initialize the concrete repositories during runtime.

My business object BusinessProvider contains the injected repository CoderRepository – with the ability to use the GenericRepository methods to add the entity to the corresponding database table.

image

I run my unit test and everything is good – the data made it into the database.

image

image

Conclusion

So, after creating the entity, I added some partial classes to onboard the entity into the generic repository and the DbContext – I consider this plumbing/infrastructure code. Then I added another partial class to add the CoderRepository reference to the BusinessProvider business class. Then with a single method call, no additional coding required, I was able to perform the data transaction to the specified database.

The implementation details only took a few minutes to setup. There is definitely a recipe here to make sure that all of the infrastructure classes are setup. These are there primarily for extensibility in the case you need to add some specialized behavior that is not already implemented in the generic repository. I like the approach of having a single repository for each entity in your solution. Using the partial classes enables that. What I didn’t include in this post is how the Generic Repository<T> works and how dependency injection is used to perform the wire-up.