On Wed, Dec 13, 2000 at 04:50:06PM -0600, Ben Collins-Sussman wrote:
>...
> 1. Authentication: "prove who you are".
>
> My understanding is that Apache has the ability to authenticate in
> many ways. In the simplest case, it has it's own local passwd and
> group file. (Right?)
Correct. The standard distro can store the groups/users/passwds in a plain
text file, or in a *DBM file.
> * How does this simple built-in authentication system work? Can I
> hear some details or see some examples?
Each HTTP request contains the authentication information for that request.
How this is specified is dependent upon the particular style/mechanism for
authentication. Basic/Digest is different from Kerberos is different from
NTLM.
At one point in the request processing, Apache passes the auth stuff out to
anybody interested. Those modules will see if the auth information
identifies a particular user, then record that information in the request
processing record.
Details? Examples? Hmm. I'd say RTFM for examples :-), and hope the above
gives a basic overview of the mechanics. I'd be quite happy to explain in
more detail -- just ask.
> * How does one make Apache authenticate against external
> user databases?
You install other Apache modules. For example, I use "mod_auth_mysql" which
uses a MySQL database to hold the user/passwd information. It plugs into the
standard authentication framework and responds to Apache's "here is some
auth information" query.
> * Once Apache authenticates you, how does it "hold on" to the
> identity? How does it know that multiple HTTP requests all
> belong to the same authenticated user? (Sorry, these are basic
> httpd questions!)
Each *request* must carry its own authentication information. Therefore,
Apache does not hold it across requests. So you connect, and pass auth info
on all N requests thru that connection.
This is a bit different when you're using SSL client certificates, however.
The client cert authentication is done at connection time. I'm not sure how
that integrates with the normal per-request stuff, though. Because it is
also possible to use SSL w/o certs, and then use normal HTTP auth via the
encrypted pipe.
> * What encryption options are there? (i.e. SSL from Neon)
The "https" scheme refers to SSL. Within SSL, I believe there are different
options that fall under acronyms like TLS and crap (or maybe SSL and TLS are
sister alternatives that fall under "https"). Dunno much about it, other
than "let Neon and Apache deal with it; it's outside of my scope of interest
at this point." That is one of the coolest parts about using Neon on the
client, and Apache for the server: there is a bunch that we can simply punt
and not worry about :-)
I hope that starts you on the right path. Please ask further questions as
needed!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006