Clayton Hicklin wrote:
[...]
After doing some more reading, I really think this isn't going to work how I
want.
There, I think you are basically right.
IE is never going to send the password in clear (or even encoded as
Base64), unless you use Basic authentication, and in my opinion that
implies the ugly IE popup login dialog.
Unless we can somehow modify the 'domain\username' that IE is sending
before it is processed by the auth modules,
Now that in itself, is NOT a big issue.
Anything a browser sends to Apache can be intercepted, and modified, at
whatever stage you want (e.g. before any authentication module has a
chance to look at it).
The question is "does the browser send it ?".
The other question here is the choice of the tools to do it.
I do this regularly using either some Apache "built-in" C module (like
mod_headers, mod_setenvif, mod_rewrite,..), or an existing mod_perl
module (www.cpan.org) (which implies perl and mod_perl, but is
multi-platform as much as Apache), or using a custom mod_perl module
that I create myself (often by using an existing module as base), or a
combination of all the above.
It sounds ugly, but it is extremely effective, multi-platform, and you
can usually do exactly what you want.
and unless it is sending the
password in Base64 format (which we don't really know), it's just not going
to work.
That seems to be the main problem in your case.
Any web authentication mechanism worth it's salt, is not going to give
you access directly to the user's password.
And even if the mechanism allowed you to do that, you have 99%
probability that the sysadmins of the corporate network in which this
would run, would not let you install that. Unless of course you are the
sysadmin...
I have mod_auth_sspi working, but only because I'm running Apache on
Windows. The other option is Kerberos authentication with mod_auth_kerb.
It is not part of the standard Apache distribution, but I think this is
going to be your best bet if you're running on Linux.
Well, I have some alternatives left for what I want and need to do,
based on the above. But the main difference in my case is that I do not
need the user's password. I just need to make sure that the user-id I
get is valid and authenticated.
My own next stop is here :
http://cpan.uwinnipeg.ca/htdocs/Apache2-AuthenNTLM/Apache2/AuthenNTLM.html
(Unix/Linux only, but worth a look anyway).
In the worst case (which is probably a station on the Internet needing
an NTLM authentication to access an Intranet application running under
Unix/Linux), it is always possible to set up a separate "authentication
server" where you do what's needed, and have the client go there first
to get a token (via HTTPS for instance).
(A few of my corporate customers do that anyway, because otherwise you
are always dependent on IE and what its settings are).
Which is also pretty much what Kerberos does.
(Kerberos won't give you a user password either by the way, and is quite
heavy to set up).
You may also want to have a look here : http://openid.net/
That's a clever alternative.
And one last thing : for multi-browser, multi-platform,
multi-environment kind of web authentication/SSO needs, cookies are your
best friend. You can store whatever you want in them (preferably
encrypted) once your initial authentication is done, and re-use the
content to speed up subsequent accesses. You can also log a user out,
by resetting his cookie. That is something you don't get with the usual
"built-in" browser authentication mechanisms.
André
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
