I have a ProjectName.Core library containing all my business logic and my entities and their behaviour. There's currently no relation whatsoever to Entity Framework or any other DAL because I like to keep those things seperated. The Entity Framework configurations (using the Fluent API) reside in a ProjectName.Infrastructure project so that takes care of pushing my entities into EF. Basically I'm going in the direction of an Onion-like architecture.

However, when adding the ASP.NET Identity framework into the mix, I have to make my ApplicationUser entity inherit from the IdentityUser class but my ApplicationUser class has relations to other entities. In inheriting from IdentityUser I'm introducing a reference to Entity Framework in my entities project, the one place where I wouldn't want to do so. Pulling the ApplicationUser class out of the entities project and into the Infrastructure project (since it is using an Entity Framework based identity system) will result in circular references, so that isn't the way to go either.

Is there any way around this so I can keep the clean seperation between the two layers besides not using ASP.NET Identity?

Can you not create an IApplicationUser interface in your Core project and keep the implementation in Infrastructure? In my opinion, unless you are creating an API or you need to swap interface implementations at runtime, just keep all your non UI code in one project. Having a bunch of different projects just adds to your mental and code management overhead without much benefit.
– mortalapemanMar 17 '15 at 19:56

You'd have to also create classes for Role, UserClaim, and UserLogin. You can name them whatever you choose if you don't like the above names.

In the web layer, create a class called AppUser (Or another name if you choose). This class should implement the ASP.NET Identity IUser<TKey> interface, where TKey is the data type for the primary key (Guid in the above example).

Change all references to UserManager in the web project to UserManager<AppUser, Guid>.

Finally, create your own UserStore. Essentially, the custom UserStore will take in the AppUser object, convert it to an User entity object, then persist it. An example of one of these methods is shown below:

In the end, it's your choice. Measure the amount of effort it would take for you to maintain this implementation versus just referencing the Identity framework in your Core library. Personally, I thought of doing it the way I described above, however, I didn't because I'd potentially have to change my code every time the ASP.NET Identity framework is updated.