Can/Should I use Asp.Net Identity with Organizational Accounts?

Question

I would like my users to to login to my web app with their organizational accounts (AD, AAD, O365), and use Asp.Net Identity to store app-specific profile or role information locally in my application, information I don't want to soil my directory or that of my tenants with.

I'm not sure if this is scenario is realistic since I find so little information about it. In MVC 4 it was doable. I'd create an Empty MVC4 Web application, use the Identity and Access tool to setup federated authentication, and store the name claim in a Users table I'd set up with SimpleMembership (Like this.)

It seems however better to favor Asp.Net Identity over SimpleMembership for new development. But there it looks a lot more difficult. Looking at the ASP.NET Web templates in Visual Studio 2013 RTM I would have to combine bits from the Individual Accounts template with those of the Organizational Accounts template. I've seen that Asp.Net identity stores external login info in the AspNetUserLogins table out-of-the-box (which I can change with EF6 code first) but I can't figure out what information from my ClaimsIdentity I'd store best (tenantId and name claim?) or at what point in the code. The Organizational Accounts template references the Microsoft.Aspnet.Identity but never seems to call it.

Is my scenario viable? Will there be a sample I can build on with the VS2013 final release? Would it be better to use an own implementation to store role- and profile info instead of Asp.Net Identity?

Answer 1

This is a valid scenario and I've implemented something similar to this. Let's say you want to store a WAAD user's "metadata" in your local repository. By metadata, I mean basic identifying information that you can use to tie the user in your local repository to the same user's entry in WAAD. Here's what I would store:

IdentityProvider (WAAD, in this case)
TenantId (the format of this field can vary across identity providers but a string should suffice)
UserId (once again, the format of this field can vary across idPs but a string would work... name claim, in this instance - as long as it is unique across users within a tenant)

This is information you should be able to grab out of the ClaimsPrincipal/ClaimsIdentity. I implemented my application before VS 2013 came on the scene so I rolled my own but having read through the new "one" ASP.NET identity document, it looks fairly extensible and it might be a good idea to go with that. It even lets you plug in different storage providers (not just relational databases).