Sql – Forms authentication against multiple providers (SQl and AD)

active-directoryasp.netasp.net-membershipforms-authenticationsql

We have an application that is for both internal users and external customers. We would like to authenticate against AD for the internal users and against sql membership for the external customers. Has anyone taken a similar approach? Also what is the best way to authenicate against AD when in a DMZ? I would rather have a proxy of some sort that is in the dmz and handles authentication against the AD DCs on our internal network. Any suggestions?

TIA,
Kevin

Best Answer

We have a similar situation. Our Internal users go against AD the external guys against an ADAM store. Different than your database approach, but similar in that they have two user stores. Our authentication against AD occurs in the secure zone, the web servers in the DMZ make a webservice call into the secure zone for authentication. Don't know what you are rally looking for, but your approach sounds ok.

EDIT to answer comments:

  • The ADAM store is not synced with the database.
  • Basically there were two providers that the webservice was configured to use, one for each store. I fact, there were three for a period of time when users were migrated from the legacy system. To determine which store a user was in, the application simply asked the most common provider first (ADAM in our case) and if the user did not exist, it would move to the next provider.
  • The endpoint was the webservice, inside the firewall, running on a the middle tier server. That server did run IIS, so technically it was a webserver, but actually our middle tier server as it did not serve up any pages or host anything other than a few webservices.
  • So it sounds like you have 2 types of external users. Ones that are really internal users (in AD) and ones that are truely external (in DB). This is not very elegant, but you could ave 2 login screens, one for each. Don't publish the internal users external login screen to anyone but them, and publish the real external login screen to teh world. A little hacky but it would work. Otherwise, you login would process will need to identify the type of user.