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.