views:

165

answers:

2

I am creating an Asp.net MVC application and I'm currently using the built in Authentication/Authorization code that comes with the sample MVC app. For the most part this is working ok and I kinda understand what's going on.

What's concerning me though, is that now I kind of have my users stored in two different tables across two databases. i.e. I have users in my App's database that represent the "Customer" entity in the application, as well as the "User" in the Authentication database that's used to log in someone to the app.

Should I take the logged in user's User.Identity.Name value and do look up in my Customers table or should I merge them into one table? What's the best practice way of handling this?

Please forgive my ignorance - this is the first time I'm working with a system like this.

Any feedback is greatly appreciated!

+2  A: 

You can extend the .Net Membership Provider to take all the information you want and post back in a single model I think.

See this one ASP.net Profiles and Membership - Custom Providers or should completely I roll my own?

And this one How to implement ASP.NET membership provider in my domain model

griegs
+4  A: 

It's helpful to think of credentials and the records that associate a person to application data as two very different things. Depending on the application, your Customer may not have credentials to log in or you may have an administrative User that logs in but isn't related to your application data.

Separate credentials are also useful if Users access more than one application with different rights for each.

For these reasons, I'd keep Customer and User separate and look one up from the other where appropriate.

Corbin March
Those are my thoughts as well. Still waiting to see if I hear other opinions.
Terry Donaghe