1

I am starting a new ASP.Net MVC 3 app and I'm hoping to be able to use the built in Membership provider.

The issue I have is that my application can be used by various organizations and it is important that the information shown is only applicable to the organization the user is working for.

The no brainer approach would be to insist all users use their email addresses as their username so everyone is unique and can be associated with their respective organizations. The problem is, some users don't have email addresses so there is no reliable way of ensuring unique names and I don't want people to know the Usernames already in use by different organizations. (USernames should only be unique to the Organization, not the entire app)

Ideally, I would want the User to enter their organization name in one field, then their username in another (and then the password!)

So we could have Jane login from one organization.....

Organization   Company1
Username       Jane
Password       ********

and then someone else also called Jane could login from a different organization.. 

Organization   Company2
Username       Jane
Password       ********

So my question is, what is the best way of modifying the Membership system to allow for this extra field?

Mitch
  • 2,471
  • 8
  • 38
  • 46
  • this is an overkill for the default membership provider in my opinion. It's quite a lot of work to make it working outside of the default provider too because of the requirement to allow same usernames across companies. What you are essentially introducing here is a combined ID for a user which consits of (CompanyID, UserID). This will complicate things all over the place (e.g. your application) – mare Jul 05 '11 at 14:51

4 Answers4

4

I'd go about writing a custom MembershipProvider to suite the requirement.

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

Illuminati
  • 4,539
  • 2
  • 35
  • 55
2

The built-in (default ASP.NET) membership provider does not provide a concept of an Organization/Company/Firm or Department. You will have create your own tables in the database for those with a foreign key to the aspnet_users table to be able to store that additional information (I wouldn't go changing the default aspnet_users table because it might make it incompatible with the current default provider or future ones). You will then need to use the default provider for the default functionality and create a Service class to support the extended functionality. I know, I have done it. It gets complicated and dirty, takes time but it's completely doable.

Most likely you will end up creating your own provider and that starts with the requirement to support Users in Companies. In case you thought that changing the default provider to support that wouldn't be necessary. The requirement about uniqueness within the company is another one you will have to implement.

mare
  • 13,033
  • 24
  • 102
  • 191
2

The provider pattern used by membership is designed so that you can extend it. You can inherit from the default provider and from the default membership use class to add the fields you need. This saves you from having to write a provider from scratch. As @mare pointed out, there are potential pitfalls though.

I would overcome these by perhaps having a login form that prompts for organisation, username & password, but behind the scenes combine the org & username & use that as the internal username.

Simon Halsey
  • 5,459
  • 1
  • 21
  • 32
  • yes i would do that too, combine the organisation and the username into one complete username (ID). Or, if the company does not provide emails, introduce ones myself. Like "name@company.com", doesn't mean they have to exist in the mail system or anything like that... – mare Jul 05 '11 at 15:09
  • +1 for suggesting something simple (like combining username/org behind the scenes) before attempting to write your own custom membership provider (as suggested by @Bumble Bee) – Hector Correa Jul 05 '11 at 15:52
  • @hector: he will end up with a custom provider for sure. Unless his requirements will get changed. – mare Jul 05 '11 at 18:51
  • @Simon +1 I have already experimented with combining the Org/User details and then splitting it back out which seems to work so it's encouraging to see your suggestion. I'll probably work with this approach. @Mare Thanks for your suggestion too, user@company.com is always an option if all else fails! – Mitch Jul 05 '11 at 18:53
0

I think there is a built in option in the membership. look into the APPLICATION field in table my_aspnet_users. reference here: http://msdn.microsoft.com/en-us/library/system.web.security.membership.applicationname.aspx

Guy
  • 1,001
  • 2
  • 12
  • 20