No. You need to reverse your thinking. Clone the gatekeeper package (It's quite unfulfilling in it's present form, for many reasons, but it's mostly there,) and use it as a template to wrap your cgi server.
In wrapping (or writing) the cgi which will be ultimately called through the cloned gatekeeper, pay careful attention to hrefs in the produced html. They are tricky, and you'll likely need to muck about with the tcl code. I've yet to find a universal solution.
The key for authentication is to make ad_user be part of the uri. Then, you'll need to arrange so that the backend webserver trusts you (e.g. localhost only connections) and does not require a password (either muck with its source, or ensure that it's passwords can be empty.)
MOST IMPORTANT, put a requirement for the user being logged in to the acs at the beginning of your package.
Also important, consider a separate package (certainly a separate instance) for each cgi mediated uri.
To state the obvious, OpenACS will be performing authentication, and your backend database will be performing authorization based on the passed REMOTE_USER, which is really ad_user@uri
As an early attempt, I used some fixed passwords, and in the gatekeeper tcl code, I used uris of the form ad_user:PASSWORD@localhost/path/to/cgi. THat's not blessed W3C usage, but it seems to be supported by mozilla and IE still.
Here, I use the KSH for cgi scripting, and have a nice little functio that enables me to use method=POST with uris that have ? in them, and have all of the POST and GET style input in one place. IIRC PHP can do that trick as well. That makes it easy to let the CGI program know that you are coming from acs, viz: uri/path/to/cgi/relay=openacs. I use this to rewrite hrefs, btw, as there are some internal uses that don't go through the OpenACS, but instead stunnel, with plain passwords protected by ssl.
It'll likely be a while before I'm back here, so if you need and example, email me, and I'll dig up something from my initial testing.
Cheers!
