-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
From: Pete Thomas [ptho...@hpti.com]
1) for authentication: depend upon mod_ssl configured with an
appropriate SSLVerifyClient option.
[i.e. decline to authenticate a user if no client cert was passed; be
configurable to fail or warn
stridently if a client cert was passed but SSLVerifyClient
optional_no_ca is in use]
With you here, the big descision is to whether impersonate
basic auth or to run before it.
I'm leaning against impersonating basic auth. Basic is quick to 401 with
note_basic_auth_failure headers if it hasn't received a basic auth header. I
don't want that; certificate authentication is a different beast. The nearerst
equivalent in the certificate-based paradigm to what Basic does would be to
tear down the SSL session and send back a client directive retry the original
client request. When entering a password, users make typographical mistakes,
and Basic Auth is set up to let them try again. I think for cetrificates this
would be a terrible idea--if a client doesn't present a valid certificate the
first time, they're not likely to come up with a valid one later. This is why
partitioning this into a new authentication type makes sense to me. Done
right, we set AuthCertAuthoritative off, and the user can fall back to basic
auth. This would behave as it always does without any pollution from the
certificate authorization process.
2) for authorization: like mod_authnz_ldap, support dn, group [to
include nested group], attribute,
and filter require directives
disagree here, why/where are you going to query this stuff?
Why not just use it in conjunction with LDAP authz?
I would love to use LDAP authz. The problem is that as a dual-provider of
both authn and authz, there is some tight coupling between phases. So long as
mod_authnz_ldap won't weigh in against a user's authentication if the current
auth provider isn't Basic, but mod_authz_ldap will work if Requre ldap-*
directives exist. My other side finding was that the AUTHENTICATE_*
variables get populated during authentication, not authorization. I still need
those values if we are using mod_authnz_ldap only for authz.
3) provide the same flexibility as mod_authnz_ldap with respect to
configuring the LDAP connection
and working with various LDAP libraries
-1 if it were going into the actual Apache distribution!
Would you be +1 if we could do this by actually USING mod_authnz_ldap [as I
contemplate above], with whatever minimally invasive changes [if/as required]
to allow a Cert auth provider to use the module [not changing any of its
behaviors as a Basic provider].
4) be configurable to work with users' existing LDAP schemas without
requiring changes in the directory.
sounds reasonable unless you're drawing a contrast with the current LDAP auth
modules.
Not drawing a contrast with the core. This is a problem I've had with other
3rd-party, non-distro modules. They point the right direction, but in a couple
of cases they didn't have the flexibility to use alternate schemas. For
example, mod_authnz_ldap lets you create arrays of group member attribute names
to augment or override the default member and uniqueMember. 3rd-party modules
often expect a set schema. My goal here is to make something that others can
use, not just solve my own problem. In enterprises, you frequently have to
live with the directory you're given--you don't get to roll your own.
I think AuthType cert is reasonable as long as you can demonstrate using
the the traditional authz providers.
Agreed. I'll think about what test cases are appropriate to demonstrate
functonality without impacting compatibility.
