httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas, Peter" <ptho...@HPTI.com>
Subject RE: Time for a new AuthType: "cert?"
Date Mon, 01 Mar 2010 18:39:43 GMT
> -----Original Message-----
> From: Eric Covener [mailto:covener@gmail.com] 

> > From: Pete Thomas [pthomas@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.

Mime
View raw message