Decoupling Microsoft.AspNet.Identity.*

Question

I am working in Visual Studio 2013 RC and am testing Forms Authentication using new Microsoft.AspNet.Identity.* packages.

I would to integrate these con

Answer 1

Yes this is a fully supported scenario, basically you will want to use exclude using the Microsoft.AspNet.Identity.EntityFramework dll which has the default EF implementation, but you should be able to reuse the Manager classes and just implement your own custom Stores using your own POCOs which the manager will use just fine via the interface. For RTM its been streamlined and simplified a bit more, I believe the RC version was not quite as streamlined yet.

Updated You can get early access to the RTM bits here: MyGet

Answer 2

Just in case. Maybe I can help someone. exorcising entity framework from asp.net.Identity

I'd created separate project(class library), then add ref to asp.identity.core, then I'd implemented my UserStore class there, and feed it my Identity config in Web project.

It works fine in project with complex n-tier architecture.

Answer 3

I have updated my sample project which you can find here: Identity RC1 sample

It now implements an entity framework model, it still require a reference to the Microsoft.AspNet.Identity.EntityFramework as I didn't want to reimplement all the Store classes also. But the sample shows how you can use your own POCO classes for the model.

If you want to completely remove the dependency on Microsoft.AspNet.Identity.EntityFramework from your model assembly you need to implement an class implementing the IIdentityStore interface which has properties of the following interfaces:

• IUserLoginStore
• IRoleStore
• IUserSecretStore
• ITokenStore
• IUserClaimStore
• IUserManagementStore
• IUserStore

The IIdentityStore class should be in an assembly separate from your model assembly, with a reference to your model assembly. The IIdentityStore assembly would be dependent on ASP.Net Identity core.

Your custom implementation of IIdentityStore would need to somwhow be able to convert to and from your POCO classes to ASP.Net Identity interfaces such as IUser, IUserSecret etc.

Seems to me to be a lot of work for little gain, if you are using EF for your stores anyway.

Taking a dependency on the AspNet.Identity.Core assembly and have some of your POCO classes implementing one tiny interface each, seems a lot simpler to me.