0

I need some advice. I'm currently using MVC 4 & SimpleMemberhip with LDAP to authenticate users. The issue is, I don't want to store their usernames and passwords in the webpages_Membership table due to security concerns. The second issue is I want to provide user-editable profiles.

Here's what works so far:

  1. User logs for the first time and a new entry is created in webpages_Membership
  2. An individualized link to edit the user profile is displayed on the homepage
  3. Username is added to the UserProfiles table when profile is accessed for the first time
  4. Certain user details are fetched from LDAP server and written to profile
  5. Users can then customize their profiles

I'm currently using SimpleMembership with an override to the ValidateUser method. Everything works as it should but I don't need to store the LDAP usernames & passwords. Can this be done?

p.s. I know there is a better way to create new users & profiles besides on first time log in but I'm still working on it.

nouptime
  • 9,929
  • 5
  • 22
  • 37

2 Answers2

1

If you don't want to store the passwords (which SimpleMembership would do by default), you are better off deriving your own custom provider from ExtendedMembershipProvider (or maybe from SimpleMembership, but that would get complex) and write the LDAP implementation, or using one of the ones on NuGet. There's no built-in LDAP support in SimpleMembership, so any approach you do would be a nasty hack which will probably bite you later on.

As for the UserProfile, it doesn't sound like your requirement is that different to the usual UserProfile use case - create custom properties on the UserProfile model, update the database accordingly, and build a UI to allow the user to edit whichever of those properties they should be able to directly edit.

(edit)

Footnote. In my answer to "How do I use my own database with SimpleMembership and WebSecurity? What is MVC4 security all about?" I examine the history of membership, how ExtendedMembershipProvider fits into this, and how the new classes such as WebSecurity work on the basis of a provider being a concrete implementation of ExtendedMembershipProvider (which SimpleMembershipProvider is, for example). For anyone looking to derive their own provider to use with WebSecurity, that answer is worth reading.

Community
  • 1
  • 1
Andy Brown
  • 18,961
  • 3
  • 52
  • 62
  • Thanks for the reply, much appreciated. I have not tried Extended Membership before but looks like its worth a shot. I did try out the nJupiter packages but need to explore them in further detail. FYI, in case I didn't mention, the UserProfile works fine. I'm able to edit profiles and save them. Just a matter of solving the Membership issue. – nouptime Jun 07 '13 at 06:42
  • @nouptime. `ExtendedMembershipProvider` is the base for `SimpleMembershipProvider`, so it is the one to derive from if you want to use your provider with `WebSecurity`. I wrote an extensive account of how `WebSecurity` and `ExtendedMembershipProvider` came about [in this answer](http://stackoverflow.com/a/16734651/1945631) which is probably worth you looking at. – Andy Brown Jun 07 '13 at 08:38
0

I've managed to bypass storing user details in the Membership provider by creating the required tables with Code First. I'm now able to create new users and store them in the UserProfile table.

nouptime
  • 9,929
  • 5
  • 22
  • 37