title: Best practices for integrating ASP.NET Identity - do they exist?
body: <p>I'm using ASP.NET Identity with a new website and there don't seem to be many (any?) examples of how to do this in a decoupled manner. I do not want my domain model's <code>DomainUser</code> class to have to inherit from <code>Microsoft.AspNet.Identity.EntityFramework.User</code>, so I've created a class that looks like this:</p>
  
  <pre><code>public class IdentityUser : User
  {
      public virtual DomainUser DomainUser { get; private set; }
  }
  </code></pre>
  
  <p>I've moved the <code>DbSet</code>s required by ASP.NET Identity into the same derived <code>DbContext</code> class as my domain models <a href="https://stackoverflow.com/questions/19308959/set-oauth-connectionstring-property-in-net-4-5-1/19913398#19913398">as illustrated in this answer</a>. I've linked the <code>IdentityUser</code> unidirectionally to the <code>DomainUser</code> via Fluent API like so:</p>
  
  <pre><code>modelBuilder.Entity&lt;IdentityUser&gt;().HasRequired(iu =&gt; iu.DomainUser).WithRequiredPrincipal();
  </code></pre>
  
  <p>This allows me to mostly separate the concerns of authorization and authentication from the behaviors defined in the <code>DomainUser</code> class. This is better than combining them into one class, but it still feels ugly. I still have references to the required ASP.NET Identity assemblies in my Domain project. I could create yet another project that held only my IdentityUser class and a reference to my Domain assembly to allow for the navigation property, but that starts to feel convoluted. </p>
  
  <p>I feel like there should be a better, cleaner, more modular way to link Identity up to the domain without it resulting in tight coupling. </p>
  
  <p>Has anyone come up with a better way of handling this? I'm hoping to garner the attention of those involved in the ASP.NET Identity project (<a href="https://stackoverflow.com/users/1459890/hao-kung">Hao Kung</a> et al) to provide direction here.</p>