Time for a new AuthType: "cert?"

["Thomas, Peter" <pt...@HPTI.com>]

I have been trying for some time to come up with a generalizable
solution from the "stock" mod_authnz_ldap that works in a environment
with X.509 certificate-based authentication and LDAP-based
authorization.  Unfortunately, mod_authnz_ldap was written in such a way
that it seems extremely difficult to authorize a user against an LDAP
directory if they were not first authenticated against the directory.
I've managed to cobble together a solution--only to find that the
additional attributes are not queried during authorivation--or if they
are, they are not populated into the AUTHENTICATE_* subprocess
environment variables.

I really want to make as much use of mod_auth_ldap as possible rather
than managing my own LDAP connection pool and cache.  The hacks that
I've had to do to make this work suggest to me that I don't want to
overload mod_auth_basic, but what is really appropriate is a new
authorization provider--notionally call it "cert" or "cert-ldap."

This provider should:

  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]
  2) for authorization:  like mod_authnz_ldap, support dn, group [to
include nested group], attribute, and filter require directives
  3) provide the same flexibility as mod_authnz_ldap with respect to
configuring the LDAP connection and working with various LDAP libraries
  4) be configurable to work with users' existing LDAP schemas without
requiring changes in the directory.

Most of the "prior art" 3rd party modules I've seen out there seem to
fall down in one of more of these respects.

I'm new to Apache module development, and I recognize that stepping
outside of "basic" and "digest" to create an entire new authorization
provider type might be a lot to bite off.  I invite any suggestions or
tips--especially if someone has already "cracked this nut" in an
generalizable way.
 <<Thomas, Peter L. (pthomas@HPTI.com).vcf>> 

Re: Time for a new AuthType: "cert?"

[Arturo 'Buanzo' Busleiman <bu...@buanzo.com.ar>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thomas, Peter wrote:
>> From: Eric Covener [mailto:covener@gmail.com] 
>> 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.

Funny. Thinking of implementing the Enigform (i.e mod_openpgp) session initiation protocol inside a
new AuthType. I'll be following this thread closely :)

- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - OWASP - SANS - OISSG
http://www.buanzo.com.ar/pro/eng.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAkuMb00ACgkQAlpOsGhXcE2DZgCeMCIdSR6cXVOFrPcMpRGRySMH
b4IAn38SYP3gsXNESbBfhBRuwUAicbFM
=dk9g
-----END PGP SIGNATURE-----

RE: Time for a new AuthType: "cert?"

["Thomas, Peter" <pt...@HPTI.com>]

> -----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.

Re: Time for a new AuthType: "cert?"

[Eric Covener <co...@gmail.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.

>
>   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?

>   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!

>   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.


> Most of the "prior art" 3rd party modules I've seen out there seem to fall
> down in one of more of these respects.
>
> I'm new to Apache module development, and I recognize that stepping outside
> of "basic" and "digest" to create an entire new authorization provider type
> might be a lot to bite off.  I invite any suggestions or tips--especially if
> someone has already "cracked this nut" in an generalizable way.

I think "AuthType cert" is reasonable as long as you can demonstrate
using the the traditional authz providers.

-- 
Eric Covener
covener@gmail.com