ASPNET Membership w/ unrelated ASP.NET apps

[hfdev]

Hello,

I am in the process of rewriting my company's Supplier Extranet, Customer
Extranet and Intranet applications.

I am looking at leveraging the ASP.NET 2.0 Membership Provider and possibly
the Profile Provider.

General Requirements:
1) Store/Manage user account information, all created by us, not by the
users themselves
2) Forms based authentication for Supplier Extranet & Customer Extranet and
hopefully Windows Authentication for the Intranet
3) House and manage user specific data outside the built-in fields provided
in the default ASPNETDB schema

Question 1:
Can I, and should I, use a single ASPNETDB SQL Server database or should I
use separate ASPNETDB databases for each application? If it is possible to
use the same database for all three applications, can you mix authentication
models: Forms & Windows for the 2 extranets and intranet respectively?

Question 2:
Can you import a list of existing users into this ASPNETDB database using a
built in import utility or by building one yourself using the API? It looks
lihe the API would support this.

Question 3:
Is it possible to house additional information (user type info) in custom
designed tables that are joined on userID (FK). I was thinking of building
some custom management screens that use the Membership API and my own
business objects that wrap these custom tables. Does this sound feasible?

Thanks very much,

Josh Blair
HydraForce, Inc.

 

[Andreas Kraus]

Hi,

1) I would use a centralized Membership Database. You can do this by adding
an additional connectionstring for the centralized membership DB and point
your membership provider to this connectionstring in web.config.

2) You could easily write an importer, I don't think this is supported out
of the box.

3) Sure, just create relational tables based on the UserID (uniqueidentifier).

 

[hfdev]

Thanks Andreas.

I have gone down this route and this seems to work pretty well.

One of the fields that I maintain outside of the original user fields is a
logo image (path). My custom management screens allow you to specify and
optional logo image for a Supplier and then the image is uploaded to a
/images/ folder for the Supplier Extranet and the path is saved to the
supplemental Supplier Detail record. I used the UserId unique identifier
for the key into this supplemental table and my procs were modeled somewhat
after the aspnet_* procs that ship with the membership and role providers.

Maybe I should have extended the membership provider instead of adding my
functionality around it...

I guess that is always another option I can evaluate. Any insight on how
difficult this is?

Thanks,

Josh Blair
HydraForce, Inc.

 

[Andreas Kraus]

Hi Josh,

it's perfectly ok to build on top of the asp.net membership provider, I
would not try to modify the asp.net membership provider itself.

A pretty good example on how to build on top of the membership provider is
CommunityServer (hit google with it if you don't know it). Check out the SDK
and the SQL structure, they even gone one step further and use an own
memberid which is connected to the ASP.NET Membership uniqueidentifier.

hth,
Andreas