Storing ASP.net membership and openid users in a new user table

Question

In order to store user information from people who login with OpenId I plan on creating a user table.

My problem is that this new user table will contain new fields that I want the asp.net membership users to be able to fill in too (profile data).

My plan is when a user wants a username and password, they register and the information is inserted into asp.net_Membership and then duplicate their guid,username,createDate into the new user table so that in the code I can just lookup data in the user table and it will not matter if they registered with OpenId or asp.net membership.

I would like to override Membership.GetUser so that it looks up my new user table and I would add in the web.config profile properties.

Would it be better performance to instead of using Membership.GetUser to use (where I would call the new User table):

User user = _repository.GetUser(userId);

My application is already working and I would need to add references to some pages to support _repository so am just thinking of performance.

Is my plan to create a new user table ok? I don't like the idea of the duplication but if in the future I want usernames to change, it's no hassle to update the new user table and the asp.net_Membership table.

Should I override GetUser and add profile properties in the web.config or call my own User object?

Is creating a new user table and duplicating core data the best way to go?

Answer 1

Create a new table that maps the providerUserKey to a user's OpenID. When a user registers using their OpenID, add the OpenID to providerUserKey mapping to this new table. When the user returns to your site and logs in using their OpenID, look up their providerUserKey from the mapping table. Use the providerUserKey to log them in using their providerUserKey.

This approach has a number of advantages.

1. It allows a user the register and log in using username/password.
2. It allows a user to register multiple OpenID's to their profile.
3. The mapping table is independent from the rest of the membership API, so you can change it in any way you'd like without breaking the provider.
4. The mapping table can be as simple as two columns with an index on the OpenID column.

You might consider hashing the user's OpenID, converting it to a Guid, and storing the Guid rather than the full URL. This will make the database column & index smaller and faster.

Answer 2

Overriding the Membership.GetUser with your own class would make it a bit more ".Net", and would probably be easier for someone else to pick up. Don't forget that you will need to modify the stored procedures and views too.

Though I am confused, what is wrong with the built in Profile provider? Once you have a username you "just" call Profile.GetProfileByUsername(username) and you have access to the "custom" attributes you are looking for.

If you are concerned about using the current asp.net Profile provider due to the need to query / filter / sort users . . .

Why not use the membership provider and the Table based (individual columns for each profile property) Profile provider?

http://www.asp.net/downloads/sandbox/table-profile-provider-samples/

I implemented this for a site I developed, one of functions was ability to "find" people like yourself, think social networking. It required some modifications to get working, but it does a great job.