ApacheBasicAuthWithPAM

By admin
I recently wrote about how

Apache
PRODUCT

‘s HTTP Basic Authentication could do with more logging.

One
CARDINAL

of the reasons many other programs that do authentication have better logging is that they use

PAM
ORG

, and it’s the

PAM
ORG

modules and

PAM
ORG

framework that’s doing the logging. If

Apache
PRODUCT

could use

PAM
ORG

for HTTP Basic Authentication, it’d get (somewhat) better logging for free. As it turns out, you actually can do this in

at least three
CARDINAL

ways, with

three
CARDINAL

different

third
ORDINAL

party

Apache
PRODUCT

modules (at least based on their documentation, I haven’t tried any of them).

The most straightforward option is mod_authnz_pam, which provides authentication and authorization directly through

PAM
ORG

with the (

PAM
ORG

) service name of your choice. PAM-based authorization can potentially be used separately from authentication; you can authenticate through something else, then use

PAM
ORG

to obtain authorization (enabling you to play various

PAM
ORG

tricks).

The most general option is mod-authnz-external, which uses an external program, such as pwauth (also), and so can authenticate against

PAM
ORG

assuming that the external program uses

PAM
ORG

. Given an authenticated (Unix) user, you can then use their Unix groups for authorization. Since these are

two
CARDINAL

separate modules, I suspect that you could use the Unix groups stuff with any HTTP Basic Authentication mechanism if the accounts being authenticated are actual Unix ones,

Finally we have

mod_authn_sasl
PERSON

, which checks authentication through

Cyrus
PERSON

SASL (aka ‘

libsasl
PERSON

‘ or ‘

libsasl2
PERSON

‘). Cyrus SASL itself can check authentication through

PAM
ORG

, among many other things. People who are embarking on this path are hopefully already familiar with

Cyrus
PERSON

SASL, but if not, maybe the

Postfix
ORG

documentation can be of some help.

(All

three
CARDINAL

of these are currently packaged in Ubuntu

22.04
CARDINAL

and I believe in the current

Debian
ORG

, although that may change in the future.)

In general, doing HTTP Basic Authentication through

PAM
ORG

comes with some benefits and some potential limitations. You can play a lot of tricks with

PAM
ORG

, although some of them won’t necessarily work in a HTTP Basic Authentication environment, and it does have better logging than the non-logging of

Apache
PRODUCT

. The obvious drawback is that the users you need to authenticate against have to have passwd entries on your web server, and you’ll wind up using the password that they have there. But if you’re authenticating against your Unix logins anyway, this may be offset by the advantage of not having to build, maintain, and update your own htpasswd version of the same information; instead you get to reuse your existing password update mechanisms, and removing someone from Unix authentication automatically removes them from web server authentication as well (and has immediate effect, because of how HTTP Basic Authentication works).

The subtle drawback is that

Apache
PRODUCT

is going to make a

PAM
ORG

check on every HTTP request that’s guarded with

HTTP Basic Authentication
LAW

, and each

PAM
ORG

check is probably going to write

at least one
CARDINAL

log message about it. If people visit a bunch of URLs in your access restricted area, you’ll get a bunch of

PAM
ORG

checks and log messages. As a corollary to this, you’d better not have anything that rate-limits

PAM
ORG

authentications or you’ll get an unpleasant surprise.

(This is unlike both web cookie-based authentication schemes and conventional

PAM
ORG

authentication for logins and the like. In both cases you authenticate once and then the authentication is remembered, either explicitly in your cookie or implicitly in your SSH,

IMAP
ORG

, etc session. HTTP Basic Authentication re-checks the password on every HTTP request because of how the core mechanism works.)