4

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

mefisto
  • 669
  • 4
  • 9
user60812
  • 401
  • 1
  • 3
  • 11
  • If it helps from what I understand ASP.net Identity is WIF underneath. – Alex KeySmith Sep 11 '13 at 12:56
  • Yes I found that out as well :) – user60812 Sep 11 '13 at 17:37
  • @AlexKey Is this still an open question and are you still looking for an answer? – Omer Iqbal Jun 21 '14 at 09:16
  • Hi @OmerIqbal I wasn't the person who asked the question, just someone who commented. You'll want to ask user60812. Thanks anyway. – Alex KeySmith Jun 22 '14 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 '14 at 20:44
  • Hi @OmerIqbal I no longer need an answer but if you'd like to add one to help someone landing here from Google feel free, I'll accept it – user60812 Aug 07 '14 at 12:38
  • If you authenticate against users in Active Directory, I believe you'll need a CAL license for each account. Thus if you allow people to connect from the internet and create accounts, you'd have to pay for each account if you create them in AD. If this is an internal organization site, they'll probably have AD accounts anyway and thus you'd be fine. – Andy Aug 11 '15 at 15:05

1 Answers1

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);
TheCatWhisperer
  • 5,231
  • 1
  • 22
  • 41