I am trying to design a system with the below features, and am currently trying to figure out best way to handle Identity :

  1. There will be multiple decoupled parts of the system, with same customers accessing various parts
  2. I would like users organized by organizations/companies, i.e. user1 & user2 belong to ORG1
  3. I would like additional info to be stored within a user profile, info will originate from various systems, as well as global info such as address, etc
  4. For roles I haven't yet decided whether or not they will be handled by individual apps or globally and specialized in certain apps

My conundrum is whether to use the new MVC Identity released in ASP.NET Beta currently out, or use WIF or Active Directory. I am assuming that a centralized application handling users & their associated admin tasks and then federating to other applications is best. If I understand correctly any of the 3 are able to do that.

What I am wondering is which to use to be most flexible. Basically something that can be expanded later and doesn't have a huge learning curve, possibly to mobile & api use. I don't know enough about WIF or AD as I have never really used them, and ASP.NET Identity is still in beta and not really 100% documented. My experience with authentication systems is working with ones out of the box. I've never really had to deal with SSO or federation

One thing I wanted to add is there is no need for outside registration. Registration will be handled purely by admins, not sure if this ties in at all, but thought it may be of importance

  • If it helps from what I understand ASP.net Identity is WIF underneath. Sep 11, 2013 at 12:56
  • Yes I found that out as well :)
    – user60812
    Sep 11, 2013 at 17:37
  • @AlexKey Is this still an open question and are you still looking for an answer?
    – Omer Iqbal
    Jun 21, 2014 at 9:16
  • Hi @OmerIqbal I wasn't the person who asked the question, just someone who commented. You'll want to ask user60812. Thanks anyway. Jun 22, 2014 at 18:36
  • Yeah, sorry for the confusion. @user60812, is this still an open question and are you still looking for a resolution to this?
    – Omer Iqbal
    Jun 22, 2014 at 20:44

1 Answer 1


This application suite sounds sufficiently complex to warrant a business object layer. You need a separate project that contains your business models. Two of your business models would be User, and Organization. User would have an object reference to its Organization.

Design the User class to have all the properties you need ignoring the underlying provider. Once you have finished the class design, if MVC Identity is sufficient for your needs, I would recommend that you use it. If it is not, don't try to force it, roll your own.

Either way, your calls should looks something like this:

BusinessModels.MyUser user = MyUserRepo.GetUserByUsername(MVCIdentity.CurrentUser.Username);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.