Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

[William A Rowe Jr]

On Mon, Jun 19, 2017 at 5:49 PM, Jacob Champion  wrote:
> On 06/19/2017 03:44 PM, William A Rowe Jr wrote:
>>
>> None at all, I have moderation and will push it on.
>
> They are on their way over to you. Thanks for the suggestion.

... and moderated. Thanks!

Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

[Jacob Champion]

On 06/19/2017 03:44 PM, William A Rowe Jr wrote:

None at all, I have moderation and will push it on.

They are on their way over to you. Thanks for the suggestion.

--Jacob

Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

[William A Rowe Jr]

On Mon, Jun 19, 2017 at 5:41 PM, Jacob Champion  wrote:
> On 06/19/2017 03:35 PM, William A Rowe Jr wrote:
>>
>> Not to announce@httpd? users@ and dev@ aren't particularly
>> broadcast channels.
>>
>> announce@a.o might be too wide an audience, but that's why
>> we document the CVE's with short notes in the foundation-wide
>> release announcement. At least, used to document them.
>
>
> I was following Jim's lead on the first CVE announcement. I'm not opposed to
> a [SECURITY] announcement for all five; just timid. :)
>
> Any opposed to me copying all five to announce@httpd?

None at all, I have moderation and will push it on.

Just FYI you must always send-from your @apache.org identity
when pushing mail to any announce@ list, because all other posts
are pre-filtered before moderation.

Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

[Jacob Champion]

On 06/19/2017 03:35 PM, William A Rowe Jr wrote:

Not to announce@httpd? users@ and dev@ aren't particularly
broadcast channels.

announce@a.o might be too wide an audience, but that's why
we document the CVE's with short notes in the foundation-wide
release announcement. At least, used to document them.


I was following Jim's lead on the first CVE announcement. I'm not 
opposed to a [SECURITY] announcement for all five; just timid. :)


Any opposed to me copying all five to announce@httpd?

--Jacob

Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

[William A Rowe Jr]

Not to announce@httpd? users@ and dev@ aren't particularly
broadcast channels.

announce@a.o might be too wide an audience, but that's why
we document the CVE's with short notes in the foundation-wide
release announcement. At least, used to document them.


On Mon, Jun 19, 2017 at 5:08 PM, Jacob Champion <jchamp...@apache.org> wrote:
> CVE-2017-3167: ap_get_basic_auth_pw authentication bypass
>
> Severity: Important
>
> Vendor: The Apache Software Foundation
>
> Versions Affected:
> httpd 2.2.0 to 2.2.32
> httpd 2.4.0 to 2.4.25
>
> Description:
> Use of the ap_get_basic_auth_pw() by third-party modules outside of the
> authentication phase may lead to authentication requirements being
> bypassed.
>
> Mitigation:
> 2.2.x users should either apply the patch available at
> https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-3167.patch
> or upgrade in the future to 2.2.33, which is currently unreleased.
>
> 2.4.x users should upgrade to 2.4.26.
>
> Third-party module writers SHOULD use ap_get_basic_auth_components(),
> available in 2.2.33 and 2.4.26, instead of ap_get_basic_auth_pw().
> Modules which call the legacy ap_get_basic_auth_pw() during the
> authentication phase MUST either immediately authenticate the user after
> the call, or else stop the request immediately with an error response,
> to avoid incorrectly authenticating the current request.
>
> Credit:
> The Apache HTTP Server security team would like to thank Emmanuel
> Dreyfus for reporting this issue.
>
> References:
> https://httpd.apache.org/security_report.html

CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

[Jacob Champion]

CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
httpd 2.2.0 to 2.2.32
httpd 2.4.0 to 2.4.25

Description:
Use of the ap_get_basic_auth_pw() by third-party modules outside of the
authentication phase may lead to authentication requirements being
bypassed.

Mitigation:
2.2.x users should either apply the patch available at
https://www.apache.org/dist/httpd/patches/apply_to_2.2.32/CVE-2017-3167.patch
or upgrade in the future to 2.2.33, which is currently unreleased.

2.4.x users should upgrade to 2.4.26.

Third-party module writers SHOULD use ap_get_basic_auth_components(),
available in 2.2.33 and 2.4.26, instead of ap_get_basic_auth_pw().
Modules which call the legacy ap_get_basic_auth_pw() during the
authentication phase MUST either immediately authenticate the user after
the call, or else stop the request immediately with an error response,
to avoid incorrectly authenticating the current request.

Credit:
The Apache HTTP Server security team would like to thank Emmanuel
Dreyfus for reporting this issue.

References:
https://httpd.apache.org/security_report.html

Fwd: RFC 7804 on Salted Challenge Response HTTP Authentication Mechanism

[Roy T. Fielding]

For folks looking for a new feature to develop,

Roy


> Begin forwarded message:
> 
> From: rfc-edi...@rfc-editor.org
> Subject: RFC 7804 on Salted Challenge Response HTTP Authentication Mechanism
> Date: March 9, 2016 at 11:01:55 AM PST
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: drafts-update-...@iana.org, http-a...@ietf.org, rfc-edi...@rfc-editor.org
> Reply-To: i...@ietf.org
> List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>RFC 7804
> 
>Title:  Salted Challenge Response HTTP Authentication 
>Mechanism 
>Author: A. Melnikov
>Status: Experimental
>Stream: IETF
>Date:   March 2016
>Mailbox:alexey.melni...@isode.com
>Pages:  18
>Characters: 39440
>Updates/Obsoletes/SeeAlso:   None
> 
>I-D Tag:draft-ietf-httpauth-scram-auth-15.txt
> 
>URL:https://www.rfc-editor.org/info/rfc7804
> 
>    DOI:http://dx.doi.org/10.17487/RFC7804
> 
> This specification describes a family of HTTP authentication
> mechanisms called the Salted Challenge Response Authentication
> Mechanism (SCRAM), which provides a more robust authentication
> mechanism than a plaintext password protected by Transport Layer
> Security (TLS) and avoids the deployment obstacles presented by
> earlier TLS-protected challenge response authentication mechanisms.
> 
> This document is a product of the Hypertext Transfer Protocol Authentication 
> Working Group of the IETF.
> 
> 
> EXPERIMENTAL: This memo defines an Experimental Protocol for the
> Internet community.  It does not specify an Internet standard of any
> kind. Discussion and suggestions for improvement are requested.
> Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 

mod_auth_fixup -- check authentication, update user's login for subsequent authorization

[Jan Pazdziora]

Hello,

I'd like to ask for feedback about module that I called mod_auth_fixup.
It is available at

https://fedorapeople.org/cgit/adelton/public_git/mod_auth_fixup.git/

and I'd like to know if the Apache HTTP Server team would find
it useful for inclusion in httpd's distribution, and if not, whether
in general people find it as good idea, to be able to post-process
results of (for example) mod_ssl authenticaion, when the user
identifier that you might get is not directly usable for subsequent
authorization operations.

In the future I plan to add a way to retrieve the username from
external identity sources, for example via SSSD as Apache's
counterpart of new feature

https://fedorahosted.org/sssd/ticket/2596

Thank you.

The README of the module:

Apache module mod_auth_fixup


Apache module mod_auth_fixup uses results of previous authentication
and other phases and checks that user was authenticated, optionally
updating the user identifier with a substring based on regular
expression match.

Possible use is processing result of mod_ssl's operation on Apache 2.2.
Module mod_ssl has SSLVerifyClient require mechanism which sets the
user identifier and it is not proper authentication module to the rest
of Apache HTTP Server internals. That makes it hard to combine
mod_ssl with authorization modules to check additional attributes
of the authenticated user.

Module configuration


Let us assume we have mod_ssl configured with client authentication:

Location /login
SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StrictRequire
SSLUserName SSL_CLIENT_S_DN_CN
/Location

The access will only be allowed if the client certificate can be
verified by mod_ssl, and the authenticated user identifier will be
the content of client's Subject DN's common name. In access log
we will see the CN value as the user identifier.

Often, there are two issues with that situation:

1) On Apache 2.2, when we try to use the result of such authentication
   for example with Require, like

Require group admins

   or even plain

Require valid-user

   we will get an error:

configuration error:  couldn't perform authentication.
AuthType not set!

   It's because mod_ssl does not run the standard authentication
   handler.

   By adding

AuthType Fixup

   to the configuration, mod_auth_fixup takes the role of the
   authentication handler, even if it does not do anything else than
   checking that the result of the mod_ssl operation, the user
   identifier it has left in the internal r-user, set.

   Of course, any other module could have set the user identification,
   not just mod_ssl, and mod_auth_fixup would process it just fine.

2) The Common Name field of the Subject DN is often filled with
   structured information, and for the subsequent authorization phase,
   only a substring of that might be the actual user identification
   in the identity management setup used.

   For that, AuthFixupRegexp directive can specify regular expression
   to match the user identifier against, and substitution string. When
   the user identifier matches, it is the updated with the new value,
   and this new value will be then shown in the access log and
   available to later authorization phases. So for example,

AuthFixupRegexp userid=(.+?); user$1

   will make sure the user identifier contains substring

userid=the-identifier;

   and the nonempty string between userid= and the first semicolon
   will replace the $1 part in the substitution string. Note that
   the first part of the requirement matched by the above
   AuthFixupRegexp example could be handled by

SSLRequire %{SSL_CLIENT_S_DN_CN} =~ m/userid=.+?;/

   But there is no way to extract the identifier with SSLRequire (and
   to add Require to it in Apache 2.2).

   When AuthFixupRegexp is not specified, it is effectively equivalent
   to

AuthFixupRegexp .+ $0

The full example configuration might then be:

Location /login
SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StrictRequire
SSLUserName SSL_CLIENT_S_DN_CN

AuthType Fixup
AuthFixupRegexp userid=(.+?); user$1
Require group admins
/Location

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

[PATCH RESEND 1/2] mod_authn_ldap: Allow authentication with SASL

[Lubomir Rintel]

From: Lubomir Rintel lubo.rin...@gooddata.com

---
 docs/manual/mod/mod_authnz_ldap.xml   | 34 -
 docs/manual/style/scripts/prettify.js |  2 +-
 include/util_ldap.h   |  5 +-
 modules/aaa/mod_authnz_ldap.c | 14 +-
 modules/ldap/util_ldap.c  | 94 +++
 5 files changed, 111 insertions(+), 38 deletions(-)

diff --git a/docs/manual/mod/mod_authnz_ldap.xml 
b/docs/manual/mod/mod_authnz_ldap.xml
index de59a0b..1a99079 100644
--- a/docs/manual/mod/mod_authnz_ldap.xml
+++ b/docs/manual/mod/mod_authnz_ldap.xml
@@ -183,6 +183,14 @@ for HTTP Basic authentication./description
 tdAn optional password to bind
 with during the search phase./td
   /tr
+
+  tr
+tddirective
+module=mod_authnz_ldapAuthLDAPBindSASLMech/directive/td
+
+tdAn optional SASL mechanism to use for bind
+with during the search phase./td
+  /tr
 /table
 /section
 
@@ -903,8 +911,8 @@ to perform a DN lookup/description
 
 usage
 pAn optional DN used to bind to the server when searching for
-entries. If not provided, modulemod_authnz_ldap/module will use
-an anonymous bind./p
+entries. If not provided, and simple bind (not SASL) is used,
+modulemod_authnz_ldap/module will use an anonymous bind./p
 /usage
 /directivesynopsis
 
@@ -943,6 +951,28 @@ AuthLDAPBindPassword exec:/path/to/otherProgram argument1
 /directivesynopsis
 
 directivesynopsis
+nameAuthLDAPBindSASLMech/name
+descriptionOptional SASL mechanism to use in binding to the LDAP 
server/description
+syntaxAuthLDAPBindSASLMech emsasl-mech/em/syntax
+contextlistcontextdirectory/contextcontext.htaccess/context
+/contextlist
+overrideAuthConfig/override
+
+usage
+pAn optional SASL mechanism used to bind to the server when
+searching for entries. Multiple mechanisms can be used,
+separated with commas. If not provided,
+modulemod_authnz_ldap/module will use simple bind./p
+
+examplepre
+#Authenticate with Kerberos GSSAPI
+AuthLDAPBindSASLMech GSSAPI
+/pre/example
+
+/usage
+/directivesynopsis
+
+directivesynopsis
 nameAuthLDAPCharsetConfig/name
 descriptionLanguage to charset conversion configuration file/description
 syntaxAuthLDAPCharsetConfig emfile-path/em/syntax
diff --git a/docs/manual/style/scripts/prettify.js 
b/docs/manual/style/scripts/prettify.js
index 2fa959a..f1ab2e6 100644
--- a/docs/manual/style/scripts/prettify.js
+++ b/docs/manual/style/scripts/prettify.js
@@ -132,7 +132,7 @@ var prettyPrint;
   var SH_KEYWORDS = [FLOW_CONTROL_KEYWORDS, case,done,elif,esac,eval,fi, +
   function,in,local,set,then,until,echo];
   var CONFIG_ENVS = 
[User-Agent,HTTP_USER_AGENT,HTTP_REFERER,HTTP_COOKIE,HTTP_FORWARDED,HTTP_HOST,HTTP_PROXY_CONNECTION,HTTP_ACCEPT,REMOTE_ADDR,REMOTE_HOST,REMOTE_PORT,REMOTE_USER,REMOTE_IDENT,REQUEST_METHOD,SCRIPT_FILENAME,PATH_INFO,QUERY_STRING,AUTH_TYPE,DOCUMENT_ROOT,SERVER_ADMIN,SERVER_NAME,SERVER_ADDR,SERVER_PORT,SERVER_PROTOCOL,SERVER_SOFTWARE,TIME_YEAR,TIME_MON,TIME_DAY,TIME_HOUR,TIME_MIN,TIME_SEC,TIME_WDAY,TIME,API_VERSION,THE_REQUEST,REQUEST_URI,REQUEST_FILENAME,IS_SUBREQ,HTTPS,REQUEST_SCHEME];
-  var CONFIG_KEYWORDS = 
[Macro,UndefMacro,Use,AuthLDAPURL,AcceptFilter,AcceptPathInfo,AccessFileName,Action,AddAlt,AddAltByEncoding,AddAltByType,AddCharset,AddDefaultCharset,AddDescription,AddEncoding,AddHandler,AddIcon,AddIconByEncoding,AddIconByType,AddInputFilter,AddLanguage,AddModuleInfo,AddOutputFilter,AddOutputFilterByType,AddType,Alias,AliasMatch,Allow,AllowCONNECT,AllowEncodedSlashes,AllowMethods,AllowOverride,AllowOverrideList,Anonymous,Anonymous_LogEmail,Anonymous_MustGiveEmail,Anonymous_NoUserID,Anonymous_VerifyEmail,AsyncRequestWorkerFactor,AuthBasicAuthoritative,AuthBasicProvider,AuthDBDUserPWQuery,AuthDBDUserRealmQuery,AuthDBMGroupFile,AuthDBMType,AuthDBMUserFile,AuthDigestAlgorithm,AuthDigestDomain,AuthDigestNcCheck,AuthDigestNonceFormat,AuthDigestNonceLifetime,AuthDigestProvider,AuthDigestQop,AuthDigestShmemSize,AuthFormAuthoritative,AuthFormBody,AuthFormDisableNoStore,AuthFormFakeBasicAuth,AuthFormLocation,AuthFormLoginRequiredLocation,AuthFormLoginSuccessLocation,
 
AuthFormLogoutLocation,AuthFormMethod,AuthFormMimetype,AuthFormPassword,AuthFormProvider,AuthFormSitePassphrase,AuthFormSize,AuthFormUsername,AuthGroupFile,AuthLDAPAuthorizePrefix,AuthLDAPBindAuthoritative,AuthLDAPBindDN,AuthLDAPBindPassword,AuthLDAPCharsetConfig,AuthLDAPCompareAsUser,AuthLDAPCompareDNOnServer,AuthLDAPDereferenceAliases,AuthLDAPGroupAttribute,AuthLDAPGroupAttributeIsDN,AuthLDAPInitialBindAsUser,AuthLDAPInitialBindPattern,AuthLDAPMaxSubGroupDepth,AuthLDAPRemoteUserAttribute,AuthLDAPRemoteUserIsDN,AuthLDAPSearchAsUser,AuthLDAPSubGroupAttribute,AuthLDAPSubGroupClass,AuthLDAPUrl,AuthMerging,AuthName,AuthnCacheContext,AuthnCacheEnable,AuthnCacheProvideFor,AuthnCacheSOCache,AuthnCacheTimeout,AuthnProviderAlias,AuthType,AuthUserFile,AuthzDBDLoginToReferer,AuthzDBDQuery,AuthzDBDRedirectQuery

[PATCH 55178 1/2] mod_authn_ldap: Allow authentication with SASL

[Lubomir Rintel]

From: Lubomir Rintel lubo.rin...@gooddata.com

---
 docs/manual/mod/mod_authnz_ldap.xml   | 34 -
 docs/manual/style/scripts/prettify.js |  2 +-
 include/util_ldap.h   |  5 +-
 modules/aaa/mod_authnz_ldap.c | 14 +-
 modules/ldap/util_ldap.c  | 94 +++
 5 files changed, 111 insertions(+), 38 deletions(-)

diff --git a/docs/manual/mod/mod_authnz_ldap.xml 
b/docs/manual/mod/mod_authnz_ldap.xml
index de59a0b..1a99079 100644
--- a/docs/manual/mod/mod_authnz_ldap.xml
+++ b/docs/manual/mod/mod_authnz_ldap.xml
@@ -183,6 +183,14 @@ for HTTP Basic authentication./description
 tdAn optional password to bind
 with during the search phase./td
   /tr
+
+  tr
+tddirective
+module=mod_authnz_ldapAuthLDAPBindSASLMech/directive/td
+
+tdAn optional SASL mechanism to use for bind
+with during the search phase./td
+  /tr
 /table
 /section
 
@@ -903,8 +911,8 @@ to perform a DN lookup/description
 
 usage
 pAn optional DN used to bind to the server when searching for
-entries. If not provided, modulemod_authnz_ldap/module will use
-an anonymous bind./p
+entries. If not provided, and simple bind (not SASL) is used,
+modulemod_authnz_ldap/module will use an anonymous bind./p
 /usage
 /directivesynopsis
 
@@ -943,6 +951,28 @@ AuthLDAPBindPassword exec:/path/to/otherProgram argument1
 /directivesynopsis
 
 directivesynopsis
+nameAuthLDAPBindSASLMech/name
+descriptionOptional SASL mechanism to use in binding to the LDAP 
server/description
+syntaxAuthLDAPBindSASLMech emsasl-mech/em/syntax
+contextlistcontextdirectory/contextcontext.htaccess/context
+/contextlist
+overrideAuthConfig/override
+
+usage
+pAn optional SASL mechanism used to bind to the server when
+searching for entries. Multiple mechanisms can be used,
+separated with commas. If not provided,
+modulemod_authnz_ldap/module will use simple bind./p
+
+examplepre
+#Authenticate with Kerberos GSSAPI
+AuthLDAPBindSASLMech GSSAPI
+/pre/example
+
+/usage
+/directivesynopsis
+
+directivesynopsis
 nameAuthLDAPCharsetConfig/name
 descriptionLanguage to charset conversion configuration file/description
 syntaxAuthLDAPCharsetConfig emfile-path/em/syntax
diff --git a/docs/manual/style/scripts/prettify.js 
b/docs/manual/style/scripts/prettify.js
index 2fa959a..f1ab2e6 100644
--- a/docs/manual/style/scripts/prettify.js
+++ b/docs/manual/style/scripts/prettify.js
@@ -132,7 +132,7 @@ var prettyPrint;
   var SH_KEYWORDS = [FLOW_CONTROL_KEYWORDS, case,done,elif,esac,eval,fi, +
   function,in,local,set,then,until,echo];
   var CONFIG_ENVS = 
[User-Agent,HTTP_USER_AGENT,HTTP_REFERER,HTTP_COOKIE,HTTP_FORWARDED,HTTP_HOST,HTTP_PROXY_CONNECTION,HTTP_ACCEPT,REMOTE_ADDR,REMOTE_HOST,REMOTE_PORT,REMOTE_USER,REMOTE_IDENT,REQUEST_METHOD,SCRIPT_FILENAME,PATH_INFO,QUERY_STRING,AUTH_TYPE,DOCUMENT_ROOT,SERVER_ADMIN,SERVER_NAME,SERVER_ADDR,SERVER_PORT,SERVER_PROTOCOL,SERVER_SOFTWARE,TIME_YEAR,TIME_MON,TIME_DAY,TIME_HOUR,TIME_MIN,TIME_SEC,TIME_WDAY,TIME,API_VERSION,THE_REQUEST,REQUEST_URI,REQUEST_FILENAME,IS_SUBREQ,HTTPS,REQUEST_SCHEME];
-  var CONFIG_KEYWORDS = 
[Macro,UndefMacro,Use,AuthLDAPURL,AcceptFilter,AcceptPathInfo,AccessFileName,Action,AddAlt,AddAltByEncoding,AddAltByType,AddCharset,AddDefaultCharset,AddDescription,AddEncoding,AddHandler,AddIcon,AddIconByEncoding,AddIconByType,AddInputFilter,AddLanguage,AddModuleInfo,AddOutputFilter,AddOutputFilterByType,AddType,Alias,AliasMatch,Allow,AllowCONNECT,AllowEncodedSlashes,AllowMethods,AllowOverride,AllowOverrideList,Anonymous,Anonymous_LogEmail,Anonymous_MustGiveEmail,Anonymous_NoUserID,Anonymous_VerifyEmail,AsyncRequestWorkerFactor,AuthBasicAuthoritative,AuthBasicProvider,AuthDBDUserPWQuery,AuthDBDUserRealmQuery,AuthDBMGroupFile,AuthDBMType,AuthDBMUserFile,AuthDigestAlgorithm,AuthDigestDomain,AuthDigestNcCheck,AuthDigestNonceFormat,AuthDigestNonceLifetime,AuthDigestProvider,AuthDigestQop,AuthDigestShmemSize,AuthFormAuthoritative,AuthFormBody,AuthFormDisableNoStore,AuthFormFakeBasicAuth,AuthFormLocation,AuthFormLoginRequiredLocation,AuthFormLoginSuccessLocation,
 
AuthFormLogoutLocation,AuthFormMethod,AuthFormMimetype,AuthFormPassword,AuthFormProvider,AuthFormSitePassphrase,AuthFormSize,AuthFormUsername,AuthGroupFile,AuthLDAPAuthorizePrefix,AuthLDAPBindAuthoritative,AuthLDAPBindDN,AuthLDAPBindPassword,AuthLDAPCharsetConfig,AuthLDAPCompareAsUser,AuthLDAPCompareDNOnServer,AuthLDAPDereferenceAliases,AuthLDAPGroupAttribute,AuthLDAPGroupAttributeIsDN,AuthLDAPInitialBindAsUser,AuthLDAPInitialBindPattern,AuthLDAPMaxSubGroupDepth,AuthLDAPRemoteUserAttribute,AuthLDAPRemoteUserIsDN,AuthLDAPSearchAsUser,AuthLDAPSubGroupAttribute,AuthLDAPSubGroupClass,AuthLDAPUrl,AuthMerging,AuthName,AuthnCacheContext,AuthnCacheEnable,AuthnCacheProvideFor,AuthnCacheSOCache,AuthnCacheTimeout,AuthnProviderAlias,AuthType,AuthUserFile,AuthzDBDLoginToReferer,AuthzDBDQuery,AuthzDBDRedirectQuery

how to use authn_provider for password-less authentication within a module ?

[Daniel Kahn Gillmor]

Hi, i'm trying to revive mod_gnutls and bring it up to date with current
apache module practices, and i'd like to use apache 2.4's mod_auth
framework for user authentication via client-side certificates.  i'm
limiting the scope of this question to authentication because i do not
have a good use case for mod_gnutls for authorization at this point.

It seems like mod_gnutls should use:

 ap_register_auth_provider(p, AUTHN_PROVIDER_GROUP, …)

but it's not clear how it should be done.

In particular, the authn_provider struct doesn't seem well-suited to
non-password-based authentication mechanisms.  Should I avoid that part
of the framework altogether, not call ap_register_auth_provider at all,
and just manually set r-user via ap_hook_check_authn(), or should I be
thinking about this a different way?

Looking at the codebase, it looks to me like the authn_provider makes
some basic assumptions that an authentication provider will verify a
username and a password against some source.  This doesn't make sense in
the context of client-certificate-based authentication.  There are other
contexts in which a module could provide authentication (verifying a
given identity, or associating an identity with a given request) without
doing the sort of password authentication that the authn_provider struct
seems to assume.

include/mod_auth.h has:

--
typedef enum {
AUTH_DENIED,
AUTH_GRANTED,
AUTH_USER_FOUND,
AUTH_USER_NOT_FOUND,
AUTH_GENERAL_ERROR
} authn_status;

/*  [...] */

typedef struct {
/* Given a username and password, expected to return AUTH_GRANTED
 * if we can validate this user/password combination.
 */
authn_status (*check_password)(request_rec *r, const char *user,
   const char *password);

/* Given a user and realm, expected to return AUTH_USER_FOUND if we
 * can find a md5 hash of 'user:realm:password'
 */
authn_status (*get_realm_hash)(request_rec *r, const char *user,
   const char *realm, char **rethash);
} authn_provider;
--

Any recommendations for how to best think about password-less
AUTHN_PROVIDER_GROUPs, or pointers to documentation that should clear it
up would be welcome.

Regards,

 --dkg


pgpbZBWSVNE_1.pgp
Description: PGP signature

Re: how to use authn_provider for password-less authentication within a module ?

[Eric Covener]

 In particular, the authn_provider struct doesn't seem well-suited to
 non-password-based authentication mechanisms.  Should I avoid that part
 of the framework altogether, not call ap_register_auth_provider at all,
 and just manually set r-user via ap_hook_check_authn(), or should I be
 thinking about this a different way?


That is the conclusion I came to for a similar mod.  I use an
alternate proprietary SSL module and do not like fakebasic or
SSLUsername:

https://github.com/covener/apache-modules/blob/master/mod_authn_cert.c

This relies on ssl_var_lookup via the expression parser. Hopefully
mod_gnutls implements these ssl optional functions.

Re: [PATCH 55178] mod_authnz_ldap SASL authentication support

[Stefan Fritsch]

Hi Lubomir,

On Friday 12 July 2013, Lubomir Rintel wrote:
 I'm have submitted the following-up patches adding SASL
 authentication to LDAP modules. Some wise person on an IRC channel
 suggested that I'm breaking API and it's a good idea to take this
 to the list as an extra work might be needed.
 
 Would someone be kind enought to take a look at the patches and let
 me know what would need to be chaged for them to be accepted into
 httpd tree?

if the change should go into 2.4 (as opposed to 2.6 or 3.0), it must 
not modify the API/ABI in an incompatible way. This means that you may 
only add new members at the end of public structs (see 
util_ldap_connection_t), and that you may not remove functions. So you 
have to keep the old uldap_connection_find() interface available, and 
add a new uldap_connection_find_ex() interface that supports sasl.

Another problem is that you use additional ldap functions like 
ldap_sasl_interactive_bind_s() that may not be available in some LDAP 
libraries (I assume you use openldap). The correct way would be to add 
configure tests for those functions and use #ifdef in the code to 
ensure that it compiles with other LDAP libraries (or even old 
versions of openldap).

Another issue is the use of a synchronus function 
ldap_sasl_interactive_bind_s().  We have removed any use of 
ldap_simple_bind_s() because not all ldap libraries support setting a 
timeout for that operation, which caused significant problems in 
practice. Either the code needs to be changed to use 
ldap_sasl_interactive_bind() instead of the _s function, or it should 
only be compiled in if LDAP_OPT_TIMEOUT is available. In openldap this 
has been introduced in version 2.4.4. But given the compatibility 
problems between ldap libraries, I would lean towards only enabling 
the new code on openldap = 2.4.4 anyway, and support other ldap 
libraries only when they have been actually tested to work.

Note that I haven't done an in-depth review of the code and don't have 
time for that at the moment. In general httpd developers are rather 
busy. So even if you do the suggested changes, it could take quite 
some time until the patches get reviewed and included.

Cheers,
Stefan

[PATCH 55178] mod_authnz_ldap SASL authentication support

[Lubomir Rintel]

Hi,

I'm have submitted the following-up patches adding SASL authentication to LDAP 
modules. Some wise person on an IRC channel suggested that I'm breaking API and
it's a good idea to take this to the list as an extra work might be needed.

Would someone be kind enought to take a look at the patches and let me know what
would need to be chaged for them to be accepted into httpd tree?

Thank you!
Lubo

--
Lubomir Rintel, GoodData random furniture movement coordinator

[PATCH 55178 1/2] mod_authn_ldap: Allow authentication with SASL

[Lubomir Rintel]

---
 docs/manual/mod/mod_authnz_ldap.xml   |   34 +++-
 docs/manual/style/scripts/prettify.js |2 +-
 include/util_ldap.h   |5 +-
 modules/aaa/mod_authnz_ldap.c |   14 -
 modules/ldap/util_ldap.c  |   92 ++---
 5 files changed, 110 insertions(+), 37 deletions(-)

diff --git a/docs/manual/mod/mod_authnz_ldap.xml 
b/docs/manual/mod/mod_authnz_ldap.xml
index 358115f..85e626c 100644
--- a/docs/manual/mod/mod_authnz_ldap.xml
+++ b/docs/manual/mod/mod_authnz_ldap.xml
@@ -183,6 +183,14 @@ for HTTP Basic authentication./description
 tdAn optional password to bind
 with during the search phase./td
   /tr
+
+  tr
+tddirective
+module=mod_authnz_ldapAuthLDAPBindSASLMech/directive/td
+
+tdAn optional SASL mechanism to use for bind
+with during the search phase./td
+  /tr
 /table
 /section
 
@@ -890,8 +898,8 @@ to perform a DN lookup/description
 
 usage
 pAn optional DN used to bind to the server when searching for
-entries. If not provided, modulemod_authnz_ldap/module will use
-an anonymous bind./p
+entries. If not provided, and simple bind (not SASL) is used,
+modulemod_authnz_ldap/module will use an anonymous bind./p
 /usage
 /directivesynopsis
 
@@ -929,6 +937,28 @@ AuthLDAPBindPassword exec:/path/to/otherProgram argument1
 /directivesynopsis
 
 directivesynopsis
+nameAuthLDAPBindSASLMech/name
+descriptionOptional SASL mechanism to use in binding to the LDAP 
server/description
+syntaxAuthLDAPBindSASLMech emsasl-mech/em/syntax
+contextlistcontextdirectory/contextcontext.htaccess/context
+/contextlist
+overrideAuthConfig/override
+
+usage
+pAn optional SASL mechanism used to bind to the server when
+searching for entries. Multiple mechanisms can be used,
+separated with commas. If not provided,
+modulemod_authnz_ldap/module will use simple bind./p
+
+examplepre
+#Authenticate with Kerberos GSSAPI
+AuthLDAPBindSASLMech GSSAPI
+/pre/example
+
+/usage
+/directivesynopsis
+
+directivesynopsis
 nameAuthLDAPCharsetConfig/name
 descriptionLanguage to charset conversion configuration file/description
 syntaxAuthLDAPCharsetConfig emfile-path/em/syntax
diff --git a/docs/manual/style/scripts/prettify.js 
b/docs/manual/style/scripts/prettify.js
index a27abe4..97c69c1 100644
--- a/docs/manual/style/scripts/prettify.js
+++ b/docs/manual/style/scripts/prettify.js
@@ -132,7 +132,7 @@ var prettyPrint;
   var SH_KEYWORDS = [FLOW_CONTROL_KEYWORDS, case,done,elif,esac,eval,fi, +
   function,in,local,set,then,until,echo];
   var CONFIG_ENVS = 
[User-Agent,HTTP_USER_AGENT,HTTP_REFERER,HTTP_COOKIE,HTTP_FORWARDED,HTTP_HOST,HTTP_PROXY_CONNECTION,HTTP_ACCEPT,REMOTE_ADDR,REMOTE_HOST,REMOTE_PORT,REMOTE_USER,REMOTE_IDENT,REQUEST_METHOD,SCRIPT_FILENAME,PATH_INFO,QUERY_STRING,AUTH_TYPE,DOCUMENT_ROOT,SERVER_ADMIN,SERVER_NAME,SERVER_ADDR,SERVER_PORT,SERVER_PROTOCOL,SERVER_SOFTWARE,TIME_YEAR,TIME_MON,TIME_DAY,TIME_HOUR,TIME_MIN,TIME_SEC,TIME_WDAY,TIME,API_VERSION,THE_REQUEST,REQUEST_URI,REQUEST_FILENAME,IS_SUBREQ,HTTPS,REQUEST_SCHEME];
-  var CONFIG_KEYWORDS = 
[Macro,UndefMacro,Use,AuthLDAPURL,AcceptFilter,AcceptPathInfo,AccessFileName,Action,AddAlt,AddAltByEncoding,AddAltByType,AddCharset,AddDefaultCharset,AddDescription,AddEncoding,AddHandler,AddIcon,AddIconByEncoding,AddIconByType,AddInputFilter,AddLanguage,AddModuleInfo,AddOutputFilter,AddOutputFilterByType,AddType,Alias,AliasMatch,Allow,AllowCONNECT,AllowEncodedSlashes,AllowMethods,AllowOverride,AllowOverrideList,Anonymous,Anonymous_LogEmail,Anonymous_MustGiveEmail,Anonymous_NoUserID,Anonymous_VerifyEmail,AsyncRequestWorkerFactor,AuthBasicAuthoritative,AuthBasicProvider,AuthDBDUserPWQuery,AuthDBDUserRealmQuery,AuthDBMGroupFile,AuthDBMType,AuthDBMUserFile,AuthDigestAlgorithm,AuthDigestDomain,AuthDigestNcCheck,AuthDigestNonceFormat,AuthDigestNonceLifetime,AuthDigestProvider,AuthDigestQop,AuthDigestShmemSize,AuthFormAuthoritative,AuthFormBody,AuthFormDisableNoStore,AuthFormFakeBasicAuth,AuthFormLocation,AuthFormLoginRequiredLocation,AuthFormLoginSuccessLocation,
 
AuthFormLogoutLocation,AuthFormMethod,AuthFormMimetype,AuthFormPassword,AuthFormProvider,AuthFormSitePassphrase,AuthFormSize,AuthFormUsername,AuthGroupFile,AuthLDAPAuthorizePrefix,AuthLDAPBindAuthoritative,AuthLDAPBindDN,AuthLDAPBindPassword,AuthLDAPCharsetConfig,AuthLDAPCompareAsUser,AuthLDAPCompareDNOnServer,AuthLDAPDereferenceAliases,AuthLDAPGroupAttribute,AuthLDAPGroupAttributeIsDN,AuthLDAPInitialBindAsUser,AuthLDAPInitialBindPattern,AuthLDAPMaxSubGroupDepth,AuthLDAPRemoteUserAttribute,AuthLDAPRemoteUserIsDN,AuthLDAPSearchAsUser,AuthLDAPSubGroupAttribute,AuthLDAPSubGroupClass,AuthLDAPUrl,AuthMerging,AuthName,AuthnCacheContext,AuthnCacheEnable,AuthnCacheProvideFor,AuthnCacheSOCache,AuthnCacheTimeout,AuthnProviderAlias,AuthType,AuthUserFile,AuthzDBDLoginToReferer,AuthzDBDQuery,AuthzDBDRedirectQuery,AuthzDBMType,AuthzProviderAlias

Re: Authentication/Authorization module vs. Basic Authentication

[Christoph Gröver]

Hello Niq, Hello List,

I have been able to solve this issue. Well, I should say, I have found
a workaround.

I suspected mod_auth_basic to be doing something wrong, so I had a close
look at the sourcecode.
It is only run in the check_user_id phase.

I tested whether the problem still exists if my module is hooked in at
the beginning of the check_user_id phase and returns with status DONE,
thus preventing mod_auth_basic to be run at all.

The problem is immediately gone, so I'm sure this module is the cause.
But I haven't found out what exactly goes wrong.

Doesn't matter. This way it works.

Thank youfor your time.

Greetings

-- 
Christoph Gröver

Re: Authentication/Authorization module vs. Basic Authentication

[Christoph Gröver]

Hello Nick,

 You'd want the err_headers_out to set that for an error return.

OK. Good point. Changed that.
 
  Instead of sending back to the client a 302 or a 301 the next thing
  that happens the apache sends back a 401.
 
 Have you traced and/or stepped through execution of your own code?

I have a lot of debugging code in my module. The last thing that my
module does in the access checking phase is returning
HTTP_MOVED_TEMPORARILY (this is logged to the errorlog).

For debugging purposes I have a short code segment hooked up into
the phases check_user_id and auth_checker.
Those are not run.

So. This leads to my conclusion that some other module must be doing
something in the access checking phase.

 
 Could it be that your errordocument itself authenticates the client?

The problem arises when the client sends POST data to the webserver.
The client sends authentication information and my module does a 
redirection to either a failed login page or a successful welcome page.

Without any Basic Authentication / require  lines in the
configuration this works.

If I add a require valid-user it doesn't work anymore.

 
  I tried to find out with LogLevel debug.
  But this actually leads to nearly no extra lines in the log files.
 
 My usual tool in that situation is gdb.
 

I guess the other modules are not logging much if not compile for
verbosity?
If I'd use gdb I would have to compile every module with debugging
support, I guess?

Thank you for your answer,
Greetings

-- 
Sitepark Gesellschaft für Informationsmanagement mbH
Rothenburg 14-16, 48143 Münster

Telefon: +49 251 482655-0, Telefax: +49 251 482655-55
http://www.sitepark.com
http://www.facebook.com/sitepark

Geschäftsführer: Thorsten Liebold
Amtsgericht Münster, HRB 5017

Authentication/Authorization module vs. Basic Authentication

[Christoph Gröver]

Dear mailing list,

I have written a rather complex module which deals with authentication
and authorization among other things. It checks for example for the
existence of a valid kerberos ticket, it checks a mysql database for
information which user is allowed to see which URL of a website. Later
it filters out unwanted content or removes part of the content
delivered to the user based on the id of the user.

I didn't want the module to be dependent on any require ... line and
I found out these lines are essential for a module which uses the
auth_checker hook. So I use some of the other hooks.
The main authentication and authorization parts are done in
ap_hook_access_checker.

Below there's the part of the code which registers functions for the
hooks.

The module was first created for Apache 1.3, transferred to Apache 2.0
and is now used with Apache 2.2. But lately there seem to be some 
compatibility problems with Basic Authentication.

In the past it was possible to use Basic Authentication and this module
at the same time. Now this gives us some Error 401 although we have a
satisfy any and an allowed IP address configured.

After the code in the acess_checker phase is run and returns a
HTTP_MOVED_TEMPORARILY the user is prompted with a password/login
popup. This is not coming from my code. I guess it's coming from the
module that implements Basic Authentication.

So while I cannot give you an example snippet of code, because it's a
complex module which I cannot boil down to a few lines of code, I hope
you still have an idea what might be going wrong or in which direction
I should analyse this.

Any help is greatly appreciated. Thank you very much.



==
static void SumpfRegisterHooks(apr_pool_t *pool)
{
 static const char * const Succ[] = { mod_php.c, NULL };
 
  // This is the hook that is called initially at the server start
  // after the configuration is read
  ap_hook_post_config(SumpfInit, NULL, NULL, APR_HOOK_MIDDLE);
  // or APR_HOOK_LAST ?
 
  // This is the hook that is called after reading each request
  ap_hook_post_read_request(SumpfStartPerRequest, NULL, NULL,
APR_HOOK_MIDDLE); // or APR_HOOK_LAST ?

  // We cannot use the auth_checker hook, cause it depends on
  // 'require valid-user' in the configuration
  ap_hook_access_checker(SumpfAuthChecker, NULL, NULL, APR_HOOK_FIRST);

  // 
  ap_hook_check_user_id(SumpfCheckUserID, NULL, NULL, APR_HOOK_MIDDLE);

  // auth_checker hook will only be used if we have a 'require ...'
  option // if we use the require option the basic auth module can't
  use it !!! ap_hook_auth_checker(SumpfCheckAuthorization, NULL, NULL,
  APR_HOOK_FIRST);

  // For Kerberos we cannot run in auth_checker phase because
  mod_auth_kerb // prevents this by returning OK, which means no other
  module is run here // So we run as first in fixup hook
  ap_hook_fixups(SumpfKerberosChecker, NULL, NULL, APR_HOOK_FIRST);

  // For PHP a normal hook_handler doesn't do anything,
  // presumably because mod_php ends with return(OK)
  // We need the hook_fixups !!
  ap_hook_fixups(SumpfHandleSpecialRequests, NULL, NULL,
  APR_HOOK_MIDDLE);

  // Not needed anymore  15.12.2006
  // ap_hook_handler(SumpfSpecialURLs, NULL, NULL, APR_HOOK_MIDDLE);

  ap_hook_insert_filter(SumpfInsertFilter, Succ, NULL, APR_HOOK_MIDDLE);

  ap_register_output_filter(SumpfFilterName, sumpf_filter, NULL,
  AP_FTYPE_RESOURCE); }
===




-- 
Sitepark Gesellschaft für Informationsmanagement mbH
Rothenburg 14-16, 48143 Münster

Telefon: +49 251 482655-0, Telefax: +49 251 482655-55
http://www.sitepark.com
http://www.facebook.com/sitepark

Geschäftsführer: Thorsten Liebold
Amtsgericht Münster, HRB 5017

Authentication Module

[Suneet Shah]

Hello,

I am trying to build an Authentication/SSO module and part of it leverages
the work in Mod-Proxy (all my requests need to flow through the proxy)
After I authenticate, I generate a security token that I need to tack on to
each request and not have it get lost through the proxy.
Is there a way to configure mod-proxy so that it does or a way to enhance
it?

For example - I may start with url:
http://myhost/myapp?userid=abctoken=12334343
the proxy would then return a page, but that page should also have the query
string tacked on to it: ie.
http://myhost/myapp/page1.jsp?userid=abctoken=12334343

Thanks for your help
suneet

Re: Developing an Authentication Module

[Mark Montague]

On September 15, 2011 11:41 , Suneet Shah suneetshah2...@gmail.com wrote:

In our architecture, authentication and authorization is handled by a set of
web services.  I would need to have the apache module make calls to the
service. I was planning on using Axis 2 for this. Are there any issues with
thiat?


I have no experience with Axis 2, but an Apache module can certainly 
utilize external services.  For example, mod_auth_kerb makes RPC calls 
to Kerberos KDCs, and mod_auth_dbd makes queries against SQL databases.




I need to be able to look at request and see if it has a security token. If
it does, then I need to validate it through the service.

If it does not, then I need to redirect them to an authentication page.

I thought it would be easier to handle the authentication through our java
application (as we have the rest of the application) or should this part of
the module as well?

If a person successful authenticates, then the authentication app would
redirect the user to the originally requested url.



This sounds very much like the way cosign works.  cosign is a web 
single-sign-on solution that includes an Apache HTTP Server module, 
mod_cosign.  A diagram showing how cosign works is available at 
http://cosign.sourceforge.net/overview.shtml   The actual authentication 
(prompting for and verifying the user's username and password) is 
handled by an application written in C which runs as a CGI and is not a 
part of the mod_cosign module itself.


You may also want to study the implementation of other web 
single-sign-on solutions, including Pubcookie ( http://pubcookie.org/ ) 
and CAS ( http://www.jasig.org/cas ).  CAS may be of particular interest 
to you because it is written in Java.




This would flow through
the apache web service and mod-proxy to end up at the target location.


You may not need mod_proxy unless it is key to your requirements in some 
way.  cosign, for example, simply redirects the user to the target 
location after verifying the security token (cookie) or authenticating 
the user and issuing a new security token.


--
  Mark Montague
  m...@catseye.org

Re: Developing an Authentication Module

[Suneet Shah]

Hi Mark,

Thanks a lot for your help with this. I will take a look at the modules that
you have referenced below.

In our case, Mod-proxy and complementary modules seem to make sense. We need
to hide the location of the real application and the proxy would help with
that.  Also the firewall rules in place only allow us to talk to the apache
web server. There is no access directly to the other apps.. Finally, we also
need to be able to inject headers into some applications to enable a form of
SSO.

We need the speed and security offered by running native in Apache, which is
the reason why we opted for an apache module based approach. It would have
been easier to go with a java based approach since we have a lot more
experience in that environment

Thanks again for your guidance
Suneet


On Thu, Sep 15, 2011 at 12:02 PM, Mark Montague m...@catseye.org wrote:

 On September 15, 2011 11:41 , Suneet Shah suneetshah2...@gmail.com
 wrote:

 In our architecture, authentication and authorization is handled by a set
 of
 web services.  I would need to have the apache module make calls to the
 service. I was planning on using Axis 2 for this. Are there any issues
 with
 thiat?


 I have no experience with Axis 2, but an Apache module can certainly
 utilize external services.  For example, mod_auth_kerb makes RPC calls to
 Kerberos KDCs, and mod_auth_dbd makes queries against SQL databases.



  I need to be able to look at request and see if it has a security token.
 If
 it does, then I need to validate it through the service.

 If it does not, then I need to redirect them to an authentication page.

 I thought it would be easier to handle the authentication through our java
 application (as we have the rest of the application) or should this part
 of
 the module as well?

 If a person successful authenticates, then the authentication app would
 redirect the user to the originally requested url.



 This sounds very much like the way cosign works.  cosign is a web
 single-sign-on solution that includes an Apache HTTP Server module,
 mod_cosign.  A diagram showing how cosign works is available at
 http://cosign.sourceforge.net/**overview.shtmlhttp://cosign.sourceforge.net/overview.shtml
   The actual authentication (prompting for and verifying the user's username
 and password) is handled by an application written in C which runs as a CGI
 and is not a part of the mod_cosign module itself.

 You may also want to study the implementation of other web single-sign-on
 solutions, including Pubcookie ( http://pubcookie.org/ ) and CAS (
 http://www.jasig.org/cas ).  CAS may be of particular interest to you
 because it is written in Java.



  This would flow through
 the apache web service and mod-proxy to end up at the target location.


 You may not need mod_proxy unless it is key to your requirements in some
 way.  cosign, for example, simply redirects the user to the target location
 after verifying the security token (cookie) or authenticating the user and
 issuing a new security token.

 --
  Mark Montague
  m...@catseye.org

Developing an Authentication Module

[Suneet Shah]

Hello,



I need to build modules that will handle authentication and authorization.  Our
requirements seem to be a little different then what is provided with the
apache web server. However, before I started down this path, I was hoping to
get some feedback on the approach, as I am new module development.



In our architecture, authentication and authorization is handled by a set of
web services.  I would need to have the apache module make calls to the
service. I was planning on using Axis 2 for this. Are there any issues with
thiat?



For Authentication:

I need to be able to look at request and see if it has a security token. If
it does, then I need to validate it through the service.

If it does not, then I need to redirect them to an authentication page.

I thought it would be easier to handle the authentication through our java
application (as we have the rest of the application) or should this part of
the module as well?

If a person successful authenticates, then the authentication app would
redirect the user to the originally requested url. This would flow through
the apache web service and mod-proxy to end up at the target location.



Does this approach seem reasonable ?



Thanks for your feedback.

Suneet

Authentication and ReverseProxy to more servers

[Petr Hracek]

Dear developers,

sorry for bother you with that question but I could not imagine where
I have made a problem?

Situation have to be following:
I have MAIN server connected to the intranet. To that MAIN server are
connected some other servers.
In the MAIN server is buildup proprietary authentication module which
is used for authorization and authentication.

When the user write down in URL somethink like:
https://MAIN_server_IP/application1 then this should be reversed
proxied to the http://192.168.0.20:8080/appl1
https://MAIN_server_IP/application2 then this should be reversed
proxied to the http://192.168.0.30:8080/appl2
Both applications like application1 and application2 have to be
authorized first in the MAIN server and than proxied to
the relevant servers.

Authentication works fine but it is not proxied.
In the /var/log/apache2/error_log file is not mentioned and log from
mod_proxy.c module
and ReverseProxy is not working at all.
In the log is mentioned only:
File does not exists: /srv/www/htdocs/ssldocs/application1
But this is true because of it has to be proxied.
Handlers in my modules are:
static void register_hooks(apr_pool_t * p)
{
 static const char * const
aszPre[]={mod_proxy.c,mod_proxy_http.c,mod_proxy_ajp.c,NULL};
 ap_hook_auth_checker(access_handler,NULL,NULL,APR_HOOK_FIRST);
 ap_hook_check_user_id(auth_handler,NULL,NULL,APR_HOOK_FIRST);
}
Should be there add ap_hook_map_to_storage?

Could you please let me know how to do it?

Configuration file in MAIN server looks like:
VirtualHost _default_: 443
DocumentRoot /srv/www/htdocs/ssldocs
SSLEngine on
SSLProxyEngine on
ProxyRequests Off

Directory proxy:*
   AuthType OwnSec
   require valid-user
   Order Allow,deny
   Allow from all
/Directory

ProxyPass /application1 http://192.168.0.20:8080/appl1
ProxyPassReverse /application1 http://192.168.0.20:8080/appl1
ProxyPass /application2 http://192.168.0.30:8080/appl1
ProxyPassReverse /application2 http://192.168.0.30:8080/appl2
/VirtualHost

-- 
Best Regards / S pozdravem
Petr Hracek

Proxy authentication

[Petr Hracek]

Dear users,

I have problems with proxy authorization and I could not image where
is a problem.

Configuration in my VirtualHost section is:

VirtualHost _default_:443
SSLEngine on
SSLProxyEngine on
ProxyRequests off

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteMap pages txt:/opt/httpd2/conf/pages.txt
RewriteRule ^/([^/]+)${pages:$1|/$1} $
RewriteRule ^/([^/]+)/(.*)${pages:$1|/opt/httpd2/htdocs/ssldocs/$1}/$2 [L]

Directory /
   Options Includes Multiviews FollowSymLinks
   AllowOverride None
   Order deny,allow
   Deny from all
/Directory
Directory /opt/httpd2/htdocs/ssldocs/
AuthType SECURE_USER
require valid-user
Satisfy Any
/Directory

IfModule mod_authz_host.c
  Directory /
  Options + Indexes +Multiviews
  AuthType SECURE_USER
  require valid-user
  satisfy Any
  /Directory
Location /ATS/
   AuthType SECURE_USER
   require valid-user
   ProxyPass http://192.2.0.25:8080/ATSAdmin
   ProxyPassReverse http://192.2.0.25:8080/ATSAdmin
   satisfy Any
/Location

/IfModule

/VirtualHost

In the module is mentioned:
r-ap_auth_type = SECURE_USER;
Format of the file pages.txt is:

App1   /opt/App1/htdocs App1
App2   /opt/App2/htdocs App2
App3   /opt/App3/htdocs App3

https://IP_Address/App1 showing my own authorization.

When I will enter https://ip_address/ATS/ I want to authorized over
my module and when the authorization is done the it is proxied to the
http://192.2.0.25:8080/ATSAdmin.

Could you please let me know where I have made a mistake?

My module have following hooks:
static void register_hooks(apr_pool_t *p)
{
ap_hook_post_config(init_Module,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_auth_checker(auth_handler,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_check_user_id(access_handler,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_handler(notification_handler,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_fixups(fixups,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_child_init(init_Child,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_handler(secure_handler,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_handler(login_handler,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_handler(single_login_handler,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_handler(logout_handler,NULL,NULL,APR_HOOK_MIDDLE);
}

When the access_checker return value is OK than it shown me page 404.
When the access_checker return value is DECLINED that it shown me page
unauthorized access.
Shal I use some http redirection to the proxy pages?

When I will do that so that configuration is:
Location /wbm1
ProxyPass http://192.2.0.25/
Order deny,allow
Allow from all
AuthType Basic
AuthName Password Required
AuthUserFile password.file
AuthGroupFile group.file
Require group usergroup
/Location

Than all works fine.
-- 
Best Regards / S pozdravem
Petr Hracek

Authentication module sanity check

[Anders Melchiorsen]

Hi developers.

I have hacked up a new authentication module[1] that will use libcurl to
forward all cookies to a specified URL. The URL will validate my normal
session cookie and print the matching username.

This way, I can reuse my internal session manager to password protect
folders (webalizer, munin, etc.) with a simple .htaccess like this:

 AuthType Cookiecheck
 AuthCookiecheckUrl http://example.com/cgi/cookiecheck.cgi
 Require user mya...@example.com

and not bother users with the annoying basic auth and an extra password.


As I am not used to working with the Apache source code, I would
appreciate comments on this approach. I am wary of the implementation
details as well as the general idea.

[1]
http://www.kalibalik.dk/anders/software/mod_auth_cookiecheck/mod_auth_cookiecheck.c


Thanks,
Anders.

Re: Proposed: PKI Authentication for secure web access

[Rob Lemaster]

This is good info. Thanks for your responses. So I guess the problem
isn't that the functionality isn't available, but that it's hard to
get end users to adopt it. This makes me sad. When I become Emperor, I
will require all secure web sites to implement this functionality and
the world will be a better place.

-rob


On Sat, Nov 20, 2010 at 8:59 PM, Sander Temme scte...@apache.org wrote:

 On Nov 20, 2010, at 12:39 PM, Rob Lemaster wrote:

 Thanks for the link Issac. If this is already in Apache, why isn't
 everyone using it?

 Because key management is just too freaking hard, and too much of a 
 management and support burden.

 For God's sake, if we can't even get the Apache developer community to use 
 PGP without handholding, how would you expect the general public to handle 
 this tech?

 S.

Re: Proposed: PKI Authentication for secure web access

[Issac Goldstand]

lol.  In the meantime, it's still useful for implementation in closed
organizations where it's easy to enforce client cert policies (and easy
to use a CA model)

On 21/11/2010 10:11, Rob Lemaster wrote:
 This is good info. Thanks for your responses. So I guess the problem
 isn't that the functionality isn't available, but that it's hard to
 get end users to adopt it. This makes me sad. When I become Emperor, I
 will require all secure web sites to implement this functionality and
 the world will be a better place.

 -rob


 On Sat, Nov 20, 2010 at 8:59 PM, Sander Temme scte...@apache.org wrote:
 On Nov 20, 2010, at 12:39 PM, Rob Lemaster wrote:

 Thanks for the link Issac. If this is already in Apache, why isn't
 everyone using it?
 Because key management is just too freaking hard, and too much of a 
 management and support burden.

 For God's sake, if we can't even get the Apache developer community to use 
 PGP without handholding, how would you expect the general public to handle 
 this tech?

 S.

Re: Proposed: PKI Authentication for secure web access

[Issac Goldstand]

You can use self-signed client certs too.  You just have to explicitly
tell Apache what to trust and what not to trust.  You can also use your
own in-house CA, if applicable.

  Issac

On 20/11/2010 22:55, Rob Lemaster wrote:
 Thanks for that explanation Graham!

 I wasn't thinking in terms of CA-signed certificates like you and
 Issac pointed out, but more of a PGP-type model, where I could use my
 own self-signed public/private key pair created in Firefox  to
 authenticate to many web sites. I realize that self-signed certs
 aren't as secure (from the server's point of view), but I could
 authenticate and answer pre-assigned secret questions before uploading
 my public key to confirm my identity before the server accepts it. I'd
 still be grateful for the additional security of CA-signed certs if my
 bank and Paypal would use them..

 -rob

 On Sat, Nov 20, 2010 at 12:42 PM, Graham Leggett minf...@sharp.fm wrote:

 mod_ssl is used solely for https, yes, but the feature you're looking for is
 built into https by default already.

 Certificates work symmetrically, both sides have the power to require the
 other side to present a valid certificate.

 In the case you might be most familiar with, only one side has a certificate
 (the server). The other side (the browser) has no certificate. In this
 scenario, the browser can be sure it is speaking to the right server,
 because the server presented a signed certificate, but the server has no
 idea about the browser. Usually, some other authentication mechanism is used
 to identify the browser, of varying strengths (passwords, etc).

 In the case you want however, both sides of the connection are configured to
 require a certificate from the other side. The certificates do the same job
 as the keys that are exchanged in your SSH configuration, they allow the
 other side to say yup, I trust you, and that trust works both ways.

 Unlike an SSH key however, a certificate contains embedded within it details
 of the person (or thing) that owns the certificate, but these are details as
 far as the protocol is concerned.

 Regards,
 Graham
 --

Re: Proposed: PKI Authentication for secure web access

[Graham Leggett]

On 21 Nov 2010, at 6:59 AM, Sander Temme wrote:


Thanks for the link Issac. If this is already in Apache, why isn't
everyone using it?


Because key management is just too freaking hard, and too much of a  
management and support burden.


For God's sake, if we can't even get the Apache developer community  
to use PGP without handholding, how would you expect the general  
public to handle this tech?


In our experience, the hardest part about using certificates is  
overcoming the perception held by technical people that it's hard to  
use certificates.


Over the last three years, we have rolled out a certificate based  
infrastructure across a large organisation, with certs for all  
employees and external suppliers. The basic premise is that usernames  
and passwords are banned (unless completely unavoidable), and that  
your certificate gives you whatever access you need. Everything that  
requires registration of some kind has been configured to auto- 
register people from details in the certificates, so we have no  
centralised directory of any kind for people with certificates. Lots  
of problems evaporated as a result. When the certificate expires, or  
is revoked, the portcullis comes crashing down and you're locked out  
everywhere. There are no residual does person X still have access  
problems.


For end users, life is simple. If you need to access something, you  
simply go there, job done. No login forms, no registration, no asking  
somebody for access, no forgot your password forms, no obscure  
username that is annoyingly different to all your other usernames.


In our experience, unlike technical people, end users don't know that  
certificates are supposed to be hard, and so have never known they  
were supposed to consider certificates a problem. As a result, it's  
been very successful.


Regards,
Graham
--

Re: Proposed: PKI Authentication for secure web access

[Stefan Fritsch]

On Sunday 21 November 2010, Graham Leggett wrote:
 In our experience, unlike technical people, end users don't know
 that   certificates are supposed to be hard, and so have never
 known they were supposed to consider certificates a problem. As a
 result, it's been very successful.

If everything works, ok. But in my experience, a big problem is that 
browsers' error messages related to client certificates are mostly of 
the quality Something related to SSL does not work. And this is not 
limited to MSIE.

Re: Proposed: PKI Authentication for secure web access

[Rob Lemaster]

Now that's what I'm talking about. Are you guys hiring?


On Sun, Nov 21, 2010 at 12:06 PM, Graham Leggett minf...@sharp.fm wrote:

 In our experience, the hardest part about using certificates is overcoming
 the perception held by technical people that it's hard to use certificates.

 Over the last three years, we have rolled out a certificate based
 infrastructure across a large organisation, with certs for all employees and
 external suppliers. The basic premise is that usernames and passwords are
 banned (unless completely unavoidable), and that your certificate gives you
 whatever access you need. Everything that requires registration of some
 kind has been configured to auto-register people from details in the
 certificates, so we have no centralised directory of any kind for people
 with certificates. Lots of problems evaporated as a result. When the
 certificate expires, or is revoked, the portcullis comes crashing down and
 you're locked out everywhere. There are no residual does person X still
 have access problems.

 For end users, life is simple. If you need to access something, you simply
 go there, job done. No login forms, no registration, no asking somebody for
 access, no forgot your password forms, no obscure username that is
 annoyingly different to all your other usernames.

 In our experience, unlike technical people, end users don't know that
 certificates are supposed to be hard, and so have never known they were
 supposed to consider certificates a problem. As a result, it's been very
 successful.

 Regards,
 Graham
 --

Re: Proposed: PKI Authentication for secure web access

[Edward Z. Yang]

Hello Rob,

We use SSL Client Certificates extensively here at MIT.  They are quite
convenient for developers: if you want to plug into the existing campus
wide authentication system, just ask for a client cert and you don't need
to reimplement any authentication system.

Cheers,
Edward

Proposed: PKI Authentication for secure web access

[Rob Lemaster]

I would like to propose an enhancement to the Apache web server for
secure authentication.

If this is the wrong list, pls. reply with the correct list and I will
post it there.

SSH allows a user to create a public/private key pair and use that for
authentication. This is much more secure than simply using passwords
and adds the ability to add 'something you have' for multi-factor
authentication. I propose that the same functionality would be enabled
for web authentication.

This functionality would require support on the server and in the
client browser. The server would need to have the ability to store and
recognize a public keys for authentication. The client browser would
need to have the ability to create public/private keys and store them
securely. It would also need to have the ability to copy the keys to
other computers (home/work) or store them on a USB thumb drive for
remote access.

This functionality would be used primarily for web sites that require
secure authentication, such as banks, Ebay, and Paypal.

Do you think this is a good idea?

Re: Proposed: PKI Authentication for secure web access

[Arturo 'Buanzo' Busleiman]

Been there, done that:

http://wiki.buanzo.org (enigform and mod_openpgp)

Not x509, though.



On 11/20/10, Rob Lemaster rklemas...@gmail.com wrote:
 I would like to propose an enhancement to the Apache web server for
 secure authentication.

 If this is the wrong list, pls. reply with the correct list and I will
 post it there.

 SSH allows a user to create a public/private key pair and use that for
 authentication. This is much more secure than simply using passwords
 and adds the ability to add 'something you have' for multi-factor
 authentication. I propose that the same functionality would be enabled
 for web authentication.

 This functionality would require support on the server and in the
 client browser. The server would need to have the ability to store and
 recognize a public keys for authentication. The client browser would
 need to have the ability to create public/private keys and store them
 securely. It would also need to have the ability to copy the keys to
 other computers (home/work) or store them on a USB thumb drive for
 remote access.

 This functionality would be used primarily for web sites that require
 secure authentication, such as banks, Ebay, and Paypal.

 Do you think this is a good idea?

Re: Proposed: PKI Authentication for secure web access

[Graham Leggett]

On 20 Nov 2010, at 10:27 AM, Rob Lemaster wrote:


SSH allows a user to create a public/private key pair and use that for
authentication. This is much more secure than simply using passwords
and adds the ability to add 'something you have' for multi-factor
authentication. I propose that the same functionality would be enabled
for web authentication.

This functionality would require support on the server and in the
client browser. The server would need to have the ability to store and
recognize a public keys for authentication. The client browser would
need to have the ability to create public/private keys and store them
securely. It would also need to have the ability to copy the keys to
other computers (home/work) or store them on a USB thumb drive for
remote access.

This functionality would be used primarily for web sites that require
secure authentication, such as banks, Ebay, and Paypal.

Do you think this is a good idea?


Is there anything here that isn't already done by X509 client  
certificates, as offered by mod_ssl?


Regards,
Graham
--

Re: Proposed: PKI Authentication for secure web access

[Rob Lemaster]

Isn't mod_ssl used solely for HTTPS (browser-server encryption)? I
would like to use PKI for user authentication like you can in SSH on
top of the encryption provided by HTTPS. The most secure option I see
available for web authentication currently is OTP tokens (RSA,etc)
that only work on one web site.

thanks,
-rob

On Sat, Nov 20, 2010 at 5:37 AM, Graham Leggett minf...@sharp.fm wrote:

 Is there anything here that isn't already done by X509 client certificates,
 as offered by mod_ssl?

 Regards,
 Graham

Re: Proposed: PKI Authentication for secure web access

[Issac Goldstand]

On 20/11/2010 22:19, Rob Lemaster wrote:
 Isn't mod_ssl used solely for HTTPS (browser-server encryption)? I
 would like to use PKI for user authentication like you can in SSH on
 top of the encryption provided by HTTPS. The most secure option I see
 available for web authentication currently is OTP tokens (RSA,etc)
 that only work on one web site.

 thanks,
 -rob

Nope, you have full x509 based authentication out-of-the-box.  See
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#allclients

  Issac

Re: Proposed: PKI Authentication for secure web access

[Rob Lemaster]

Thanks for the link Issac. If this is already in Apache, why isn't
everyone using it?


On Sat, Nov 20, 2010 at 12:32 PM, Issac Goldstand mar...@beamartyr.net wrote:

 Nope, you have full x509 based authentication out-of-the-box.  See
 http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#allclients

  Issac

Re: Proposed: PKI Authentication for secure web access

[Graham Leggett]

On 20 Nov 2010, at 10:19 PM, Rob Lemaster wrote:


Isn't mod_ssl used solely for HTTPS (browser-server encryption)? I
would like to use PKI for user authentication like you can in SSH on
top of the encryption provided by HTTPS. The most secure option I see
available for web authentication currently is OTP tokens (RSA,etc)
that only work on one web site.


mod_ssl is used solely for https, yes, but the feature you're looking  
for is built into https by default already.


Certificates work symmetrically, both sides have the power to require  
the other side to present a valid certificate.


In the case you might be most familiar with, only one side has a  
certificate (the server). The other side (the browser) has no  
certificate. In this scenario, the browser can be sure it is speaking  
to the right server, because the server presented a signed  
certificate, but the server has no idea about the browser. Usually,  
some other authentication mechanism is used to identify the browser,  
of varying strengths (passwords, etc).


In the case you want however, both sides of the connection are  
configured to require a certificate from the other side. The  
certificates do the same job as the keys that are exchanged in your  
SSH configuration, they allow the other side to say yup, I trust  
you, and that trust works both ways.


Unlike an SSH key however, a certificate contains embedded within it  
details of the person (or thing) that owns the certificate, but these  
are details as far as the protocol is concerned.


Regards,
Graham
--

Re: Proposed: PKI Authentication for secure web access

[Rob Lemaster]

Thanks for that explanation Graham!

I wasn't thinking in terms of CA-signed certificates like you and
Issac pointed out, but more of a PGP-type model, where I could use my
own self-signed public/private key pair created in Firefox  to
authenticate to many web sites. I realize that self-signed certs
aren't as secure (from the server's point of view), but I could
authenticate and answer pre-assigned secret questions before uploading
my public key to confirm my identity before the server accepts it. I'd
still be grateful for the additional security of CA-signed certs if my
bank and Paypal would use them..

-rob

On Sat, Nov 20, 2010 at 12:42 PM, Graham Leggett minf...@sharp.fm wrote:

 mod_ssl is used solely for https, yes, but the feature you're looking for is
 built into https by default already.

 Certificates work symmetrically, both sides have the power to require the
 other side to present a valid certificate.

 In the case you might be most familiar with, only one side has a certificate
 (the server). The other side (the browser) has no certificate. In this
 scenario, the browser can be sure it is speaking to the right server,
 because the server presented a signed certificate, but the server has no
 idea about the browser. Usually, some other authentication mechanism is used
 to identify the browser, of varying strengths (passwords, etc).

 In the case you want however, both sides of the connection are configured to
 require a certificate from the other side. The certificates do the same job
 as the keys that are exchanged in your SSH configuration, they allow the
 other side to say yup, I trust you, and that trust works both ways.

 Unlike an SSH key however, a certificate contains embedded within it details
 of the person (or thing) that owns the certificate, but these are details as
 far as the protocol is concerned.

 Regards,
 Graham
 --

Re: Proposed: PKI Authentication for secure web access

[Daniel Ruggeri]

On 11/20/2010 2:39 PM, Rob Lemaster wrote:

Thanks for the link Issac. If this is already in Apache, why isn't
everyone using it?


On Sat, Nov 20, 2010 at 12:32 PM, Issac Goldstandmar...@beamartyr.net  wrote:


Nope, you have full x509 based authentication out-of-the-box.  See
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#allclients

  Issac



For those who have a real security need to authenticate their clients in 
this way, and are willing to accept the hassles of this method, it is 
definitely used. However, the idea that a bank or paypal would issue 
certificates for each of its end users can get cumbersome very fast. 
See, the private key would be managed by the user. Users (and even some 
server administrators) are terribly poor at managing their private keys 
in a safe and secure fashion. Some potential complications are a user 
switching browsers, a user switching computers, a user's key becoming 
compromised, loss of the key, etc... On top of that, the signing 
institution would need to be able to keep track of certificates it 
should no longer accept via CRL's and have infrastructure ready to 
verify the cert is still valid.


Essentially, the logistics of getting END USERS to generate a key of 
appropriate size (and getting them to keep it safe), send a CSR, sign 
and return a certificate to them as well as the unavoidable technical 
support involved makes this an unattractive option to large institutions 
because the average Internet denizen isn't expected to know how to do 
this stuff The Right Way.


P.S.
IMHO, this conversation applies to PKI, X509 client authentication and 
even password authentication... all of these mechanisms boil down to the 
fact that there is some entity that knows who the user is and that your 
server will have to take a leap of faith at some point to trust that the 
user sitting at the keyboard is who they say they are.


--
Daniel Ruggeri

Re: Proposed: PKI Authentication for secure web access

[Rob Lemaster]

I understand your skepticism, but I am not advocating a complex CA
infrastructure and I have more faith in end users (possibly
misplaced). IMHO, it is reasonable for users to take that extra step
for their banking site or SSL-VPN. It's really not that big a deal to
generate a key pair in PuTTY, I can't imagine it would be that hard in
Firefox. The question about whether it will be immediately and
enthusiastically adopted by end users on their Facebook site is not
the point.

A bank or Paypal does not need to issue certificates. In fact, I
believe that self-signed keys like in the PGP model would be more
appropriate, because that key pair could be used for multiple sites. A
single key pair could be used in different browsers and computers, and
if they are lost, a new key pair could be generated and the old pair
revoked by the user just like in PGP. With self-signed keys, you don't
need to deal with CAs, CRLs, etc., which I agree would be too
burdensome.

Generating a key pair for SSH is pretty trivial, and using a wizard in
Firefox would simplify it enough to be accessible to just about
anyone.

Yes, authentication boils down to trust. This is the advantage of
using multi-factor authentication. You would then have something you
know (username and password) and something you have (private key).
This is required in the newer PCI  HIPAA requirements as well.


On Sat, Nov 20, 2010 at 1:57 PM, Daniel Ruggeri drugg...@primary.net wrote:

 For those who have a real security need to authenticate their clients in
 this way, and are willing to accept the hassles of this method, it is
 definitely used. However, the idea that a bank or paypal would issue
 certificates for each of its end users can get cumbersome very fast. See,
 the private key would be managed by the user. Users (and even some server
 administrators) are terribly poor at managing their private keys in a safe
 and secure fashion. Some potential complications are a user switching
 browsers, a user switching computers, a user's key becoming compromised,
 loss of the key, etc... On top of that, the signing institution would need
 to be able to keep track of certificates it should no longer accept via
 CRL's and have infrastructure ready to verify the cert is still valid.

 Essentially, the logistics of getting END USERS to generate a key of
 appropriate size (and getting them to keep it safe), send a CSR, sign and
 return a certificate to them as well as the unavoidable technical support
 involved makes this an unattractive option to large institutions because the
 average Internet denizen isn't expected to know how to do this stuff The
 Right Way.

 P.S.
 IMHO, this conversation applies to PKI, X509 client authentication and even
 password authentication... all of these mechanisms boil down to the fact
 that there is some entity that knows who the user is and that your server
 will have to take a leap of faith at some point to trust that the user
 sitting at the keyboard is who they say they are.

 --
 Daniel Ruggeri

Re: Proposed: PKI Authentication for secure web access

[Sander Temme]

On Nov 20, 2010, at 12:39 PM, Rob Lemaster wrote:

 Thanks for the link Issac. If this is already in Apache, why isn't
 everyone using it?

Because key management is just too freaking hard, and too much of a management 
and support burden.  

For God's sake, if we can't even get the Apache developer community to use PGP 
without handholding, how would you expect the general public to handle this 
tech? 

S.

 On Sat, Nov 20, 2010 at 12:32 PM, Issac Goldstand mar...@beamartyr.net 
 wrote:
 
 Nope, you have full x509 based authentication out-of-the-box.  See
 http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#allclients
 
  Issac
 
 
 



-- 
Sander Temme
scte...@apache.org
PGP FP: FC5A 6FC6 2E25 2DFD 8007  EE23 9BB8 63B0 F51B B88A

View my availability: http://tungle.me/sctemme

RE: Fake Basic Authentication

[Plüm, Rüdiger, VF-Group]

 

 -Original Message-
 From: Nick Kew 
 Sent: Donnerstag, 9. September 2010 01:01
 To: dev@httpd.apache.org
 Subject: Fake Basic Authentication
 
 Someone asked on IRC today about seemlessly mixing SSL Client
 authentication (FakeBasicAuth) with normal basic authn.
 As I understood it, users without a client cert should authenticate, 
 but those with one would be spared the authn dialogue.

You confuse me. Doesn't this already work with Basic Auth if the user
that presents the certificate is registered in the Authn provider
with the password 'password'?
Of course this also means that if someone knows the username in the
certificate of one of the users he can log in WITHOUT certificate
using the username and 'password' (provided that client certs are not
mandatory of course).
Maybe it would be helpful to post an example configuration snippet
to be sure that we are really talking about the same thing.


 
 A quick look at mod_ssl reveals that FakeBasicAuth sets r-user
 in an Access hook, so it's set before authn.  So what the user

In the case that FakeBasicAuth is turned on r-user is not set
by mod_ssl. In this case it only adds a fake Basic auth header
to r-headers_in in ssl_hook_UserCheck (which is the same hook that
mod_auth_basic runs in but earlier) and leaves the job of setting
r-user to mod_auth_basic.

Regards

Rüdiger

Re: Fake Basic Authentication

[Guenter Knauf]

Am 09.09.2010 01:00, schrieb Nick Kew:

Someone asked on IRC today about seemlessly mixing SSL Client
authentication (FakeBasicAuth) with normal basic authn.
As I understood it, users without a client cert should authenticate,
but those with one would be spared the authn dialogue.

A quick look at mod_ssl reveals that FakeBasicAuth sets r-user
in an Access hook, so it's set before authn.  So what the user
asks is trivial: all it needs is an authn provider that accepts
any request in which r-user is set.  I've just hacked up the
smallest-ever(?) module (attached) to do that.

This could also give users flexibility to mix-and-match basic
auth with other schemes in mod_rewrite style.  Or no doubt
shoot themselves in the foot.

Thoughts?

isnt this already something similar?
http://sourceforge.net/projects/modauthcertific/

Gün.

Re: Fake Basic Authentication

[Nick Kew]

On Thu, 09 Sep 2010 16:51:00 +0200
Guenter Knauf fua...@apache.org wrote:

 Am 09.09.2010 01:00, schrieb Nick Kew:
  Someone asked on IRC today about seemlessly mixing SSL Client
  authentication (FakeBasicAuth) with normal basic authn.
  As I understood it, users without a client cert should authenticate,
  but those with one would be spared the authn dialogue.
 
  A quick look at mod_ssl reveals that FakeBasicAuth sets r-user
  in an Access hook, so it's set before authn.  So what the user
  asks is trivial: all it needs is an authn provider that accepts
  any request in which r-user is set.  I've just hacked up the
  smallest-ever(?) module (attached) to do that.
 
  This could also give users flexibility to mix-and-match basic
  auth with other schemes in mod_rewrite style.  Or no doubt
  shoot themselves in the foot.
 
  Thoughts?
 isnt this already something similar?
 http://sourceforge.net/projects/modauthcertific/

Looking at that, I see it implements its own protocol and hooks,
including changing r-ap_auth_type on-the-fly.  I could be wrong,
but it doesn't look like something that'll integrate well with
mod_auth_basic and authn providers.

-- 
Nick Kew

Fake Basic Authentication

[Nick Kew]

Someone asked on IRC today about seemlessly mixing SSL Client
authentication (FakeBasicAuth) with normal basic authn.
As I understood it, users without a client cert should authenticate, 
but those with one would be spared the authn dialogue.

A quick look at mod_ssl reveals that FakeBasicAuth sets r-user
in an Access hook, so it's set before authn.  So what the user
asks is trivial: all it needs is an authn provider that accepts
any request in which r-user is set.  I've just hacked up the
smallest-ever(?) module (attached) to do that.

This could also give users flexibility to mix-and-match basic
auth with other schemes in mod_rewrite style.  Or no doubt
shoot themselves in the foot.

Thoughts?

-- 
Nick Kew/* Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the License); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an AS IS BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

#include httpd.h
#include http_request.h
#include http_config.h
#include ap_provider.h
#include mod_auth.h

module AP_MODULE_DECLARE_DATA authn_fake_module;

static authn_status check_fake(request_rec *r, const char *u, const char *p)
{
return (r-user == NULL) ? AUTH_USER_NOT_FOUND : AUTH_GRANTED;
}

static void register_hooks(apr_pool_t *p)
{
static const authn_provider authn_fake_provider = {
check_fake,
NULL,
};
#if AP_MODULE_MAGIC_AT_LEAST(2010,0)
ap_register_auth_provider(p, AUTHN_PROVIDER_GROUP, fake,
  AUTHN_PROVIDER_VERSION,
  authn_fake_provider, AP_AUTH_INTERNAL_PER_CONF);
#else
ap_register_provider(p, AUTHN_PROVIDER_GROUP, fake, 0,
 authn_fake_provider);
#endif
}

#if AP_MODULE_MAGIC_AT_LEAST(2010,0)
AP_DECLARE_MODULE(authn_fake) =
#else
module AP_MODULE_DECLARE_DATA authn_fake_module =
#endif
{
STANDARD20_MODULE_STUFF,
NULL,
NULL,
NULL,
NULL,
NULL,
register_hooks
};

Re: Fake Basic Authentication

[Eric Covener]

 This could also give users flexibility to mix-and-match basic
 auth with other schemes in mod_rewrite style.  Or no doubt
 shoot themselves in the foot.

Seems to me like it does wonders for FakeBasicAuth usability.

Does it make sense to move the mockup of the Authorization header into
mod_authn_fake, or give it a better way to signal to the auth modules
not to challenge?

-- 
Eric Covener
cove...@gmail.com

Authentication of proxy over own module

[Petr Hracek]

Hello apache users,

I would like to explain my problem.
I have developed the module which is used for authorization to web pages.
It works fine without problem but I would like to use that module for
authorization
of proxy requests as well.
Proxy requests are not defined in settings of browser (in Firefox
Tools-Options-LAN settings - Manual configuration of proxy).

In apache conf. file I have following:

VirtualHost _default_:443

SSLEngine on
SSLProxyEngine on

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
RewriteMap foo txt:/opt/apache/conf/foo.map
RewriteRule ^/PAC$ http://192.168.0.23:8080/PACAdmin [P]
RewriteRule ^/PAC/(.*) http://192.168.0.23:8080/PACAdmin/$1 [P]
RewriteRule ^/([^/]+)$ ${foo:$1|/$1} [L]
RewriteRule ^/([^/]+)/(.*) ${foo:$1|/opt/apache/htdocs/ssldocs/$1}/$2
[L]

IfModule mod_authz_host.c
   Directory /
  Options +Indexes +Multiviews
  AuthType FOOM
  require   valid-user
  satisfy Any
   /Directory
/IfModule

Location /PAC/
   ProxyPass http://192.168.0.23:8080/PACAdmin
   ProxyPassReverse http://192.168.0.23:8080/PACAdmin
   ProxyPassReverseCookie   /PACAdmin   /PAC
   Order Allow,deny
   Allow from all
/Location

How I can used own module for authorization location /PAC/?
When user will enter URL http://192.168.0.23:8080/PAC
then firstly my own module will authorized that page and afterwards location
/PAC will be shown.
Is it possible to do it somehow?

Thanks for your help.
-- 
Best Regards / S pozdravem
Petr Hracek

Re: Client authentication and authorization using client certificates

[lambam80]

Johannes great news,  mod_auth_certificate works !

I reckon you need = httpd-2.2.14 in order to use the UID. 

See BUG https://issues.apache.org/bugzilla/show_bug.cgi?id=45107 

Initially I decided to wait for Fedora 13 with httpd-2.2.14 
where they say the above BUG is fixed in HTTPD.

In the end I tested with an unofficial version of httpd-2.2.14 on Fedora 12.

Good work, Dave
---

Johannes Müller wrote:
 
 Eric Covener wrote:
 On Tue, Jun 16, 2009 at 5:40 PM, Johannes Müllerjo...@gmx.de wrote:
   
 Yes should be no problem. Relicensing means I'll also have to remove
 current
 the current
 version and SVN revisions so there is no problem if someone already
 downloaded the
 GPLed release?
 

 IANAL: I don't see why, they're free to use it under those terms, and
 you're free to change the terms of any subsequent release (or prior
 release to other parties!)

   
 
 
 Released version 0.2 of mod_auth_certificate under Apache License 2.0
 Download at https://sourceforge.net/projects/modauthcertific/
 
 Any comments?
 
 Greetings,
 Johannes
 
 

-- 
View this message in context: 
http://old.nabble.com/Client-authentication-and-authorization-using-client-certificates-tp24058416p27919447.html
Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.

X.509 certificate against LDAP authentication

[Thomas, Peter]

Looking at some of the prior work in this area. It appears that one of
the big challenges in cert-based authentication is in the mapping
between the certificate subject and the directory entry.

If I'm creating something for general consumption, I want to make it
generalizable to multiple environments.  In looking at the other people
that have implemented this with hooks and shim modules, I've seen
several different techniques for certificate mapping  authentication.
I'd like my proposed enhancement to be as widely usable as possible.
Looking at the code, I think the greatest opportunity for reuse of
existing code and consistency with the architecture lies in creating
support for the certificate authentication type within the current
modules, starting with mod_authnz_ldap.

With respect to mapping  authentication, the approaches I'm considering
are to allow one or more of the following:

  1) Authenticate a user by the full binary certificate, assuming that
each user will have one or more valid certificates stored in the
directory in an attribute such as usercertificate;binary
  2) Authenticate a user by mapping the certificate subject to a DN
[How?]
  3) Authenticate a user by some combination of elements such as subject
CN and issuer CN against a directory of certificates?

I saw one case in my research where only groups existed in LDAP--no
users entries.To address that, it occurs to me that there might also be
an option 0:

  0) Authenticate a user by the presence of an accepted certificate,
without reference to a specific entry in the directory--i.e. any valid
certificate that comes out of mod_ssl is treated as an authenticated
user.]  This would let one authorize a user based on membership in a
group when only groups are populated.

Looking at mod_auth_basic and mod_auth_digest, it looks like I need to
come up with a user name fairly early on.  I intend to hook the handler
with mod_ssl.c as a predecessor.  Any thoughts on the most appropriate
way to pull the peer certificate out of the connection and then map it
to a user name?  I'm trying to avoid using SSLUserName from mod_ssl,
because we might need the certificate--but I don't want to set the
username to be the client certificate.  That makes for unfriendly
reading in logs.  Rather, I want to have some mapping [such as in
option 2 above] from the certificate to the user name.

In my ideal world, I would meet this goal with an absolute minimal
change to the code-base:

  1) add a new file modules/aaa/mod_auth_cert.c to support AuthType
certificate 
  2) add a check_certificate method to mod_authnz_ldap.c that maps
from a certificate to a user search and succeeds if the criteria for
existence of a user is met
  3) Reconcile any explicit or implicit assumptions that we are using
AuthType basic.

I appreciate any thoughts and pointers.

--Pete

---
Peter L. Thomas, ptho...@hpti.com
(w) 703-682-5308 (c) 703-615-7806 (pgr) 877-383-8910
 Thomas, Peter L. (ptho...@hpti.com).vcf 

RE: X.509 certificate against LDAP authentication

[Thomas, Peter]

I found ssl_list_ext(...) -- used, for example, in mod_setenvif.c --
which looked really promising for generalized access to the client
certificate elements without depending on whether mod_ssl.c
configuration options as +StdEnvVars or SSLUserName had been set.  I'm
still wrangling with how to handle the mapping of the certificate
subject into an LDAP query in a generalizable way.  RFC-2252 and
RFC-2253 offer some tantalizing hints...as well as the caveat that there
is not a deterministic reversal from an X.500 subject to an LDAP DN.  We
knew that already, right?

--Pete

 _ 
 From: Thomas, Peter  
 Sent: Wednesday, March 03, 2010 4:20 PM
 To:   'modules-...@httpd.apache.org'
 Subject:  X.509 certificate against LDAP authentication
 
 Looking at some of the prior work in this area. It appears that one of
 the big challenges in cert-based authentication is in the mapping
 between the certificate subject and the directory entry.
 
 If I'm creating something for general consumption, I want to make it
 generalizable to multiple environments.  In looking at the other
 people that have implemented this with hooks and shim modules, I've
 seen several different techniques for certificate mapping 
 authentication.  I'd like my proposed enhancement to be as widely
 usable as possible.  Looking at the code, I think the greatest
 opportunity for reuse of existing code and consistency with the
 architecture lies in creating support for the certificate
 authentication type within the current modules, starting with
 mod_authnz_ldap.
 
 With respect to mapping  authentication, the approaches I'm
 considering are to allow one or more of the following:
 
   1) Authenticate a user by the full binary certificate, assuming that
 each user will have one or more valid certificates stored in the
 directory in an attribute such as usercertificate;binary
   2) Authenticate a user by mapping the certificate subject to a DN
 [How?]
   3) Authenticate a user by some combination of elements such as
 subject CN and issuer CN against a directory of certificates?
 
 I saw one case in my research where only groups existed in LDAP--no
 users entries.To address that, it occurs to me that there might also
 be an option 0:
 
   0) Authenticate a user by the presence of an accepted certificate,
 without reference to a specific entry in the directory--i.e. any valid
 certificate that comes out of mod_ssl is treated as an authenticated
 user.]  This would let one authorize a user based on membership in a
 group when only groups are populated.
 
 Looking at mod_auth_basic and mod_auth_digest, it looks like I need to
 come up with a user name fairly early on.  I intend to hook the
 handler with mod_ssl.c as a predecessor.  Any thoughts on the most
 appropriate way to pull the peer certificate out of the connection and
 then map it to a user name?  I'm trying to avoid using SSLUserName
 from mod_ssl, because we might need the certificate--but I don't want
 to set the username to be the client certificate.  That makes for
 unfriendly reading in logs.  Rather, I want to have some mapping [such
 as in option 2 above] from the certificate to the user name.
 
 In my ideal world, I would meet this goal with an absolute minimal
 change to the code-base:
 
   1) add a new file modules/aaa/mod_auth_cert.c to support AuthType
 certificate 
   2) add a check_certificate method to mod_authnz_ldap.c that maps
 from a certificate to a user search and succeeds if the criteria for
 existence of a user is met
   3) Reconcile any explicit or implicit assumptions that we are using
 AuthType basic.
 
 I appreciate any thoughts and pointers.
 
 --Pete
 
 ---
 Peter L. Thomas, ptho...@hpti.com
 (w) 703-682-5308 (c) 703-615-7806 (pgr) 877-383-8910
   File: Thomas, Peter L. (ptho...@hpti.com).vcf  

Re: LDAP authentication: non-anonymous bind

[Vadim Chekan]

Lars Kruse wrote:

Hi,

the attached patch adds a second option for non-anonymous binds to the
authnz_ldap module. Please consider it for adoption.


I've applied it to 2.2.14 today and tested on windows (AD).
It can't bind if the exact ldap folder is unknown.

Let's say we have users not in OU=Users, but in OU=Developers and OU=QA.
In order for developer to authenticate http would have to bind to AD 
with search base OU=Developers,dc=company,dc=com. But in order for QA 
person, searach base should be different: QA=Developers,dc=company,dc=com.


Let's say we do search by sAMAccountName. Then with current approach the 
search base generate: sAMAccountName=user name,dc=company,dc=com.

Such search base does not exist.

In order to search in subfolders, search base should be static, meaning 
set in config file. And user name (variable part) should go into filter. 
Then it will be possible to search in dc=company,dc=com including 
subfolders by filter ((objectClass=user)(sAMAccountName=user name)


I managed to make it working (dirty hack):
I bind with username as is (must be user name@organization.com), and 
attribute in AuthLdapUrl should be set to userPrincipalName.

So I changed the code:
- sec-binddn = apr_psprintf(r-pool, %s=%s,%s, sec-attribute, user, 
sec-basedn);

+ sec-binddn = apr_psprintf(r-pool, %s, user);


The current situation:
The authnz_ldap module supports only one kind of non-anonymous bind to the ldap
server: by specifying the username (binddn) and password (bindpw) in an
apache config file. This is obviously not a very pretty thing, since you need
to take good care for file permissions (as an admin) and also users may feel a
little bit uncomfortable to put their plaintext login data into an htaccess
file.


Now, if we are at it, can we discuss encryption? Authnz_ldap will 
request AD in plain text. Not good. Without AuthLDAPAuthOnBind only 
single pseudo-user account was compromised with in ON, everybody's 
account will travel across the network in plain text, even if you 
connect to https via ssl!


I played a little bit with Apache Directory Studio, and I could connect 
to AD only in 2 cases.

No encryption; Simple Authentication (plain text)
No encryption; Digest-md5 (SASL)

Any chance we can leverage digest-md5 authentication method?
Othervise I would allow only ssl-emabled connection to AD. May be with 
some option enable plain text if you know what you are doing.


Vadim.

Re: LDAP authentication: non-anonymous bind

[Graham Leggett]

On 26 Jan 2010, at 4:44 AM, Eric Covener wrote:

This new behaviour covers the two use cases described above (even  
though I did

not check it in an Active Directory setup).


Patch is nice and simple, but it would be great if someone with AD
leanings could confirm that this combination of HTTP username,
attribute, and basedn is likely to result in something that can bind
in a typical AD install.


There are three possible scenarios for login:

- User provides username, auth_ldap server does a search within the  
directory to find the DN corresponding to the username, and then  
attempts to bind as that DN. If it succeeds, you're in. This usually  
requires a DN of some kind to use to do the initial login to do the  
original search. (AD works fine in this scenario, on condition you  
have an account to bind and do the initial search with).


- User provides username, auth_ldap applies the username to an admin- 
provided recipe of some kind to create the DN. This recipe needs to be  
flexible enough to support various scenarios, such as the base URL for  
the recipe being something other than the base URL for searches (think  
group searches, a group might not have the same base DN as the person).


- User provides username, auth_ldap tries to bind directly with that  
username without first converting it to a DN. This is how AD would work.


Ideally auth_ldap should support the above three methods, am I correct  
in understanding that the patch implements the second option above? (I  
don't have time to review it fully at the moment).


Regards,
Graham
--

Re: LDAP authentication: non-anonymous bind

[Eric Covener]

 In addition,
 the modifications to the binddn are in the 'sec' variable which is an
 authn_ldap_config_t structure created for the module and not for the
 _request_.

good catch, this is also a defect on one of the handful of patches in bugzilla!


-- 
Eric Covener
cove...@gmail.com

LDAP authentication: non-anonymous bind

[Lars Kruse]

Hi,

the attached patch adds a second option for non-anonymous binds to the
authnz_ldap module. Please consider it for adoption.

The current situation:
The authnz_ldap module supports only one kind of non-anonymous bind to the ldap
server: by specifying the username (binddn) and password (bindpw) in an
apache config file. This is obviously not a very pretty thing, since you need
to take good care for file permissions (as an admin) and also users may feel a
little bit uncomfortable to put their plaintext login data into an htaccess
file.


Use cases where anonymous binds don't work:

1) The most common use case for non-anonymous binds is an Active Directory
server, that (by default) does not accept anonymous binds. Usually this is
solved by creating a specific ldap user with limited read access and putting
its credentials into the apache config file. See examples:
http://www.held-im-ruhestand.de/software/apache-ldap-active-directory-authentication
http://www.jejik.com/articles/2007/06/apache_and_subversion_authentication_with_microsoft_active_directory/

2) My specific use case are some servers, that provide various services (mail,
webspace, wikis, svn, ...) to different people. All accounts are managed in a
single LDAP database. Since privacy is important for our users, it is not
acceptable, that they can get a complete user list from the ldap server. Thus
the servers, that offer shell access or webspace to users may not bind to the
LDAP server anonymously and even authenticated users may only access their own
accounts within the ldap database.
In this setup we can't use the authnz_ldap module, since we need
authenticated binds, but we don't want our users to store their precious
credentials in a plain text file.

One way of solving this issue is already implemented in Muquit's mod_auth_ldap
(http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap_apache2.html).
There the respective option is called AuthOnBind.

The patch, that I attached (not based on Muquit's code), allows the following:
 - a user tries to log into an apache-served location, that requires
   authentication
 - the given credentials (username and password) are combined with the basedn
   and attrib value (defined in AuthLDAPUrl)
 - the authnz_ldap module uses these credentials to bind to the server
   (for authentication and authorization)

The above behaviour is triggered by a new configuration directive, that I named
AuthLDAPAuthOnBind. It defaults to off, thus nothing changes for current
configurations.
This new behaviour covers the two use cases described above (even though I did
not check it in an Active Directory setup).

The patch is currently in use in our setup (see use case (2) above) and it runs
without problems.

Regarding the code quality:
I am not used to the apache codebase, thus I am not sure, if I used the string
functions in the proper way (around line 387). Please comment, if I overlooked
something!

cheers,
Lars

PS: I just e-mailed a signed Individual Contributor License Agreement to
secret...@apache.org - I am not sure, if this is necessary - just to let you
know ...
Index: mod_authnz_ldap.c
===
--- mod_authnz_ldap.c	(Revision 902678)
+++ mod_authnz_ldap.c	(Arbeitskopie)
@@ -65,6 +65,7 @@
 char *bindpw;   /* Password to bind to server (can be NULL) */
 int bind_authoritative; /* If true, will return errors when bind fails */
 
+int auth_on_bind;   /* If true, connection-user + basedn for initial bind  */
 int user_is_dn; /* If true, connection-user is DN instead of userid */
 char *remote_user_attribute;/* If set, connection-user is this attribute instead of userid */
 int compare_dn_on_server;   /* If true, will use server to do DN compare */
@@ -327,6 +328,7 @@
 sec-maxNestingDepth = 10;
 sec-sgAttributes = apr_pcalloc(p, sizeof (char *) * GROUPATTR_MAX_ELTS + 1);
 
+sec-auth_on_bind = 0;
 sec-user_is_dn = 0;
 sec-remote_user_attribute = NULL;
 sec-compare_dn_on_server = 0;
@@ -384,6 +386,11 @@
 return AUTH_GENERAL_ERROR;
 }
 
+if (sec-auth_on_bind) {
+sec-binddn = apr_psprintf(r-pool, %s=%s,%s, sec-attribute, user, sec-basedn);
+sec-bindpw = apr_pstrdup(r-pool, password);
+}
+
 start_over:
 
 /* There is a good AuthLDAPURL, right? */
@@ -1501,6 +1508,13 @@
 A list of attribute labels used to identify the user members of groups - defaults to 
 member and uniquemember),
 
+AP_INIT_FLAG(AuthLDAPAuthOnBind, ap_set_flag_slot,
+ (void *)APR_OFFSETOF(authn_ldap_config_t, auth_on_bind), OR_AUTHCFG,
+ If set to 'on', auth_ldap uses the entered username (combined with the \basedn\ and 
+ \Attrib\ from AuthLDAPURL) and password to perform an authenticated bind to the ldap 
+ server (during the search

Re: LDAP authentication: non-anonymous bind

[Ryan Phillips]

On Mon, Jan 25, 2010 at 8:44 PM, Eric Covener cove...@gmail.com wrote:
 On Mon, Jan 25, 2010 at 7:00 AM, Lars Kruse de...@sumpfralle.de wrote:

 This new behaviour covers the two use cases described above (even though I 
 did
 not check it in an Active Directory setup).

 Patch is nice and simple, but it would be great if someone with AD
 leanings could confirm that this combination of HTTP username,
 attribute, and basedn is likely to result in something that can bind
 in a typical AD install.


I've been working with LDAP and AD for a while now, and, AFAIK, there
are only two ways to bind to a Directory Server:

 1. User's BindDN, and
 2. User Principle Name

I don't believe the proposed method is portable to AD. In addition,
the modifications to the binddn are in the 'sec' variable which is an
authn_ldap_config_t structure created for the module and not for the
_request_.

Regards,
Ryan

hints for creating a DCE authentication and credential caching module

[Yannick Bergeron]

Hello

IBM DCE (Distributed Computing Environment) is an authentication and 
authorization system using kerberos v5-like credential to access a DFS 
(Distributed File System) filespace

I'm looking to write my own apache 2.2 module that would allow me to:
force authentication on a specific URL/CGIprompt authentication on an URL if 
the anonymous access is denieduse the authenticated user credential for the 
requestreuse the same credential unless it's expired (user/credential caching)
can this be done with the auth/authz/authn structure or I need to build 
something totally independant of this?

which documentation would help me to write a basic module that could evolve in 
what I'm looking at?


Regards,


Yannick Bergeron
  
_
Reinvent how you stay in touch with the new Windows Live Messenger.
http://go.microsoft.com/?linkid=9706116

RE: Using Authentication with flood

[eric.berg]

Anybody know anything about this?  It's using libapr under the hood, but
I couldn't find anything that indicates how that might translate into
authentication for Flood.

Eric 

 -Original Message-
 From: Berg, Eric: IT (NYK) 
 Sent: Friday, October 23, 2009 12:01 PM
 To: dev@httpd.apache.org
 Subject: Using Authentication with flood
 
 I'm trying to set up a regression test of sorts for my apache 
 servers to
 verify new configs.  I've been looking at Apache Flood, but I need to
 authenticate to my web servers and putting the username and 
 password in
 to the URL doesn't seem to be working.
 
 How can I authenticate using flood?
 
 Thanks.
 
 Eric
 
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Joe Orton]

On Wed, Sep 16, 2009 at 01:45:30PM +0100, Joe Orton wrote:
 On Wed, Sep 16, 2009 at 01:38:50PM +0100, Dr Stephen Henson wrote:
  I may have missed something here but the OCSP stapling code doesn't appear 
  to be
  in trunk. The patch in:
  
  https://issues.apache.org/bugzilla/show_bug.cgi?id=43822
  
  doesn't apply cleanly any more, though the changes needed to get it working 
  are
  fairly trivial. I'm in the process of including an updated patch.
 
 I'm working on merging this right now, your patch did apply fine, I've 
 committed the one part separately which you alude to below.

I finally got round to finishing this off, holidays and similar excuses 
now out of the way.  First of all: thanks a lot for the patch, and sorry 
it took so long to merge!

I made a few changes relative to your latest patch:

- minor syntax/style cleanups
- renamed the new C file to ssl_util_stapling.c
- updated the handling of SSLStaplingCache as per changes to 
  SSLSessionCache, to allow SSLStaplingCache default to DTRT
- moved up the call to ssl_stapling_ex_init() so it took effect before 
  the ex_data index was used

and have two questions:

1) the use of an ex_data structure attached to the X509 * to store the 
stapling-specific state seems unnecessary.  Was there a reason why you 
did this rather than simply extending the modssl_pk_server_t structure? 
(The ex_data indices have historically been a nightmare with mod_ssl due 
to the fact that OpenSSL might get unloaded from memory during startup, 
and any cached copies of the index values outside of OpenSSL may or may 
not be reliable.  Global state == bad!)

2) the error case where there's no SSLStaplingForceURL configured and no 
responder specified in the cert - this is currently logged but no more.  
I'm wondering whether this should be an ssl_abort(); if someone enables 
stapling for a vhost but there is no responder known, it seems like that 
should be a config error?

I've done basic testing using openssl s_client/ocsp as client/responder 
such that I can see an OCSP response being passed through, but it didn't 
seem to get cached correctly which I haven't looked into further (maybe 
I broke that with my changes).

Regards, Joe

Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Dr Stephen Henson]

Joe Orton wrote:
 
 I finally got round to finishing this off, holidays and similar excuses 
 now out of the way.  First of all: thanks a lot for the patch, and sorry 
 it took so long to merge!
 

Many thanks. I'm away from my test setup for a couple of days so can't test it
at present.

 I made a few changes relative to your latest patch:
 
 - minor syntax/style cleanups
 - renamed the new C file to ssl_util_stapling.c
 - updated the handling of SSLStaplingCache as per changes to 
   SSLSessionCache, to allow SSLStaplingCache default to DTRT
 - moved up the call to ssl_stapling_ex_init() so it took effect before 
   the ex_data index was used
 
 and have two questions:
 
 1) the use of an ex_data structure attached to the X509 * to store the 
 stapling-specific state seems unnecessary.  Was there a reason why you 
 did this rather than simply extending the modssl_pk_server_t structure? 
 (The ex_data indices have historically been a nightmare with mod_ssl due 
 to the fact that OpenSSL might get unloaded from memory during startup, 
 and any cached copies of the index values outside of OpenSSL may or may 
 not be reliable.  Global state == bad!)
 

Main reason is that I'm more used to how ex_data works ;-)

As long as the cached structure is associated with each server certificate in
some way that's fine.

 
 I've done basic testing using openssl s_client/ocsp as client/responder 
 such that I can see an OCSP response being passed through, but it didn't 
 seem to get cached correctly which I haven't looked into further (maybe 
 I broke that with my changes).
 

Will test it when I get back.

Steve.
-- 
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org

Using Authentication with flood

[eric.berg]

I'm trying to set up a regression test of sorts for my apache servers to
verify new configs.  I've been looking at Apache Flood, but I need to
authenticate to my web servers and putting the username and password in
to the URL doesn't seem to be working.

How can I authenticate using flood?

Thanks.

Eric
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___

Re: Authentication Basic default format

[Stefan Fritsch]

On Wednesday 21 October 2009, José Miguel Holguín Aparicio wrote:
 I have a question about htpasswd when creating password hashes for
 Basic Authentication. Why there isn't any warning message
  regarding password truncate to 8 characters?
 
 As you can see at your own documentation
 (http://httpd.apache.org/docs/2.2/misc/password_encryptions.html),
 OpenSSL is already warning us about this issue.
 
 
 In my opinion htpasswd command must show a warning message like
 OpenSSL does. Do you agree?

Yes. Commited to trunk as r829162.

Cheers,
Stefan

Authentication Basic default format

[José Miguel Holguín Aparicio]

Hi,

I have a question about htpasswd when creating password hashes for
Basic Authentication. Why there isn't any warning message regarding
password truncate to 8 characters?

As you can see at your own documentation
(http://httpd.apache.org/docs/2.2/misc/password_encryptions.html),
OpenSSL is already warning us about this issue.


In my opinion htpasswd command must show a warning message like
OpenSSL does. Do you agree?

Thanks in advance.
Regards

-- 
José Miguel Holguín
Security Technical Consultant
Carnegie Mellon Certified (FIH)

http://www.pentester.es

AW: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Natanael Mignon - michael-wessel . de]

After some time off (off this topic, at least), I am now trying to work my way 
through the stapling code and the mechanisms of caching in mod_ssl. Phew... I 
had expected this to be a little more straight forward even for a non-C-guru 
like me. *sigh* ;)

My favourite place to have the OCSP caching done is in ssl_engine_ocsp.c - 
verify_ocsp_status(), right where an OCSP request would be created:

static int verify_ocsp_status(...)
{
[...]
 /* Query response cache HERE */
 ruri = determine_responder_uri(sc, cert, c, pool);
 if (!ruri) {
return V_OCSP_CERTSTATUS_UNKNOWN;
 }
 request = create_request(ctx, cert, certID, s, pool);
[...]

The idea, inspired by your stapling code, Steve, is:

- Use SHA1 hash of cert (X509_digest(cert, EVP_sha1(), idx, NULL)) as key for 
the cache.
- Query cache for entry of idx above
-_ only create and dispatch new request, if no or invalid entry
- store/update response after (new) request has been dispatched and response 
has been received
- validate response (either received from cache or from connection to 
responder) -- this code is present, of course, and has been further customized 
already.

Is there a possibility to *not* customize a bunch of files like ssl_private.h, 
ssl_scache.c, ssl_engine_init.c and so on, but have all necessary handling 
placed here in ssl_engine_ocsp.c (and maybe ssl_util_ocsp.c), without messing 
up?

Of course, I see the pros of a generic approach, but this is definitely only 
for internal OCSP caching nothing to be communicated outside of this place.

On a more detailed level, it is the caching mechanisms that trouble me. What 
needs to be done to execute caching operations?

- Define and initialize a cache - similar to SSL session cache. The actual SSL 
session cache functions and structures cannot be used for this, just with a 
different storage (file)?
- Define and initialize a mutex for access to this additional cache...

So, I am lacking the right way to start this up, aims being at first a quick 
implementation and continued refactoring to a really well done solution 
afterwards. :-/

Mit freundlichen Grüßen / Kind regards
 Natanael Mignon

Von: Dr Stephen Henson [shen...@oss-institute.org]
Gesendet: Freitag, 11. September 2009 11:45
An: dev@httpd.apache.org
Betreff: Re: OCSP stapling in mod_ssl - use as OCSP cache for client 
authentication

What I think you are trying to do is to include a cache for OCSP queries the
proxy itself makes which is IMHO the best solution. So instead of always
consulting the OCSP responder it instead checks the cache to see if there is a
valid OCSP response in there, if it is expired or invalid then and only then
would it renew the response by making an actual query. Doing things that way
doesn't need OCSP stapling support in the server(s).

If that's correct then you could reuse some of the OCSP response query and
caching code in the stapling patch. It implements similar functionality.

Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[William A. Rowe, Jr.]

Dr Stephen Henson wrote:
 
 First comment to list in general: any comments on what needs to be done to get
 the OCSP stapling patch accepted?

I had been under the impression, from reading the bug commentary too many
times, that it was not vetting the CA chain from root to cert.

It seems I misunderstood and this patch is ready for backport.  Please
correct us if there are any other changes required to bless this code as
'production ready'/General Availability.

Bill

Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Dr Stephen Henson]

William A. Rowe, Jr. wrote:
 Dr Stephen Henson wrote:
 First comment to list in general: any comments on what needs to be done to 
 get
 the OCSP stapling patch accepted?
 
 I had been under the impression, from reading the bug commentary too many
 times, that it was not vetting the CA chain from root to cert.
 
 It seems I misunderstood and this patch is ready for backport.  Please
 correct us if there are any other changes required to bless this code as
 'production ready'/General Availability.
 

I may have missed something here but the OCSP stapling code doesn't appear to be
in trunk. The patch in:

https://issues.apache.org/bugzilla/show_bug.cgi?id=43822

doesn't apply cleanly any more, though the changes needed to get it working are
fairly trivial. I'm in the process of including an updated patch.

Nitpick: along the way I noticed the ocsp code in ssl_util_ocsp.c was updated to
support a configurable timeout (which was in the original stapling patch) but
the comment:

/* Inherit the default I/O timeout. */

has been retained which isn't true any more.

Steve.
-- 
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org

Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Joe Orton]

On Wed, Sep 16, 2009 at 01:38:50PM +0100, Dr Stephen Henson wrote:
 I may have missed something here but the OCSP stapling code doesn't appear to 
 be
 in trunk. The patch in:
 
 https://issues.apache.org/bugzilla/show_bug.cgi?id=43822
 
 doesn't apply cleanly any more, though the changes needed to get it working 
 are
 fairly trivial. I'm in the process of including an updated patch.

I'm working on merging this right now, your patch did apply fine, I've 
committed the one part separately which you alude to below.

 Nitpick: along the way I noticed the ocsp code in ssl_util_ocsp.c was updated 
 to
 support a configurable timeout (which was in the original stapling patch) but
 the comment:
 
   /* Inherit the default I/O timeout. */

Thanks for that, will fix.  Joe

OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Natanael Mignon - michael-wessel . de]

Hello Steve,
dear list,

inspired by https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 (OCSP 
stapling support for mod_ssl) I dare asking, if this patch might solve a 
requirement we face at the moment:

We do client authentication with certificates in Apache/mod_ssl (working as 
SSL-reverse-proxy) and we do require validation via OCSP. In order to avoid 
thousands of OCSP requests within short time, the system must provide an OCSP 
request cache, i.e. the situation is a little different from what the stapling 
patch is intended to do - but if we see Apache itself as a client, it would 
be fitting.

On basis of Apache 2.3 (for all the OCSP handling...) we have done some 
customizations already (thanks for your help on openssl-users!), so including 
the stapling patch would be welcome. I was wondering, if you had any ideas 
regarding this question that could help us? I'll look at the code now and try 
to apply the patch.

Any thoughts and help welcome. Thanks in advance!

Mit freundlichen Grüßen / Kind regards
 Natanael Mignon

IT - beraten | planen | umsetzen | betreiben
__
michael-wessel.de Informationstechnologie GmbH
Krausenstraße 50
30171 Hannover
Germany

fon  (+49) 511 260 911-0 (DW -13)
fax   (+49) 511 318 039-9
eMailn...@michael-wessel.de
web  www.michael-wessel.de

Geschäftsführer: Michael Wessel Dipl. Phys.
Amtsgericht Hannover
HR B 59031

Alle Produktnamen und Firmennamen sind ggfs. eingetragene Warenzeichen und/oder 
Markennamen der jeweiligen Hersteller.
Angebote freibleibend, Irrtümer und Druckfehler vorbehalten.
Lieferung vorbehaltlich ausreichender Selbstbelieferung.
© 2009 michael-wessel.de

Re: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Dr Stephen Henson]

Natanael Mignon - michael-wessel.de wrote:
 Hello Steve, dear list,
 
 inspired by https://issues.apache.org/bugzilla/show_bug.cgi?id=43822 (OCSP
 stapling support for mod_ssl) I dare asking, if this patch might solve a
 requirement we face at the moment:
 
 We do client authentication with certificates in Apache/mod_ssl (working as
 SSL-reverse-proxy) and we do require validation via OCSP. In order to avoid
 thousands of OCSP requests within short time, the system must provide an OCSP
 request cache, i.e. the situation is a little different from what the
 stapling patch is intended to do - but if we see Apache itself as a client,
 it would be fitting.
 
 On basis of Apache 2.3 (for all the OCSP handling...) we have done some
 customizations already (thanks for your help on openssl-users!), so including
 the stapling patch would be welcome. I was wondering, if you had any ideas
 regarding this question that could help us? I'll look at the code now and try
 to apply the patch.
 
 Any thoughts and help welcome. Thanks in advance!
 

First comment to list in general: any comments on what needs to be done to get
the OCSP stapling patch accepted? I've rewritten the original version to
incorporate all suggestions and answered all the queries in the report. It
probably needs updating, any other issues?

Now to the actual query, if I understand it correctly. That patch works in
reverse to your problem. It is designed to stop thousands of OCSP requests from
SSL clients connecting to an Apache server and all simultaneously slamming an
OCSP responder attempting to check the status of that server certificate.

One option would be to add stapling client support if you wanted to use OCSP
stapling. That would however only work if the servers the proxy connected to
also supported OCSP stapling.

Another option would be to use a local caching OCSP responder which queries the
remote responder to get an initial response and just serves that up until it
needs to be renewed.

What I think you are trying to do is to include a cache for OCSP queries the
proxy itself makes which is IMHO the best solution. So instead of always
consulting the OCSP responder it instead checks the cache to see if there is a
valid OCSP response in there, if it is expired or invalid then and only then
would it renew the response by making an actual query. Doing things that way
doesn't need OCSP stapling support in the server(s).

If that's correct then you could reuse some of the OCSP response query and
caching code in the stapling patch. It implements similar functionality.

Steve.
-- 
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org

AW: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[Natanael Mignon - michael-wessel . de]

 -Ursprüngliche Nachricht-
 Von: Dr Stephen Henson [mailto:shen...@oss-institute.org]
 Gesendet: Freitag, 11. September 2009 11:46
 An: dev@httpd.apache.org
 Betreff: Re: OCSP stapling in mod_ssl - use as OCSP cache for client
 authentication
 
 
 Now to the actual query, if I understand it correctly. That patch works
 in
 reverse to your problem. It is designed to stop thousands of OCSP
 requests from
 SSL clients connecting to an Apache server and all simultaneously
 slamming an
 OCSP responder attempting to check the status of that server
 certificate.

[NM] Right, the patch basically works reverse to our way.

 What I think you are trying to do is to include a cache for OCSP
 queries the
 proxy itself makes which is IMHO the best solution. So instead of
 always
 consulting the OCSP responder it instead checks the cache to see if
 there is a
 valid OCSP response in there, if it is expired or invalid then and only
 then
 would it renew the response by making an actual query. Doing things
 that way
 doesn't need OCSP stapling support in the server(s).
 
 If that's correct then you could reuse some of the OCSP response query
 and
 caching code in the stapling patch. It implements similar
 functionality.

[NM] That's it, exactly. And I've come to the conclusion, too, that reusing 
some of your code for our purpose would be the best solution. Hopefully, we get 
it right. ;)

Mit freundlichen Grüßen / Kind regards
 Natanael Mignon

IT-Dienstleistungen: beraten | planen | umsetzen | betreiben
__ 

fon  (+49) 511 260 911-0 (DW: - 13)
fax  (+49) 511 318 039-9
eMail  n...@michael-wessel.de
webwww.michael-wessel.de

Bitte senden Sie wichtige E-Mails stets auch an serv...@michael-wessel.de, um 
sicherzustellen, dass diese zeitnah bearbeitet werden.

Re: AW: OCSP stapling in mod_ssl - use as OCSP cache for client authentication

[William A. Rowe, Jr.]

Natanael Mignon - michael-wessel.de wrote:
 -Ursprüngliche Nachricht-
 Von: Dr Stephen Henson [mailto:shen...@oss-institute.org]

 If that's correct then you could reuse some of the OCSP response query
 and
 caching code in the stapling patch. It implements similar
 functionality.
 
 [NM] That's it, exactly. And I've come to the conclusion, too, that reusing 
 some of your code for our purpose would be the best solution. Hopefully, we 
 get it right. ;)

It sounds worthwhile to split the code into util_ocsp.c which can be shared
by the client and the server stapling, and cache modules, eh?

Re: Client authentication and authorization using client certificates

[Johannes Müller]

Eric Covener wrote:

On Tue, Jun 16, 2009 at 5:40 PM, Johannes Müllerjo...@gmx.de wrote:
  

Yes should be no problem. Relicensing means I'll also have to remove current
the current
version and SVN revisions so there is no problem if someone already
downloaded the
GPLed release?



IANAL: I don't see why, they're free to use it under those terms, and
you're free to change the terms of any subsequent release (or prior
release to other parties!)

  



Released version 0.2 of mod_auth_certificate under Apache License 2.0
Download at https://sourceforge.net/projects/modauthcertific/

Any comments?

Greetings,
Johannes

Client authentication and authorization using client certificates

[Johannes Müller]

Hello,

there has been an increasing number of requests concerning a certificate
based authentication / authorization for the Apache httpd in the past few
weeks.
As you might remember, I started a discussion around that topic in July 
2008.

Because of the somewhat missing interest on the mailing list at that time I
haven't persued this issue any longer.
This has changed lately. Therefore I decided to spend some hours on 
finishing a

new authentication module called mod_auth_certificate

Please feel free to download it at*

   https://sourceforge.net/projects/modauthcertific/

*You will also find some kind of short documentation in the archive.

*Features:*
- Works with Apache 2.0 / 2.2 / 2.3-trunk
- Apache sources won't have to be patched
- Supports fallback to basic authentication in case of cert auth failure
- Should work with all authorization modules coming with Apache (though I
 wasn't able to check all of them).
- Easy to install without recompiling Apache
- Extremely easy to configure

My intention in this announcement is to arouse increased interest in 
that topic by
providing something usable to the list. I still believe that better 
native support for
client certificate based authentication and authorization will in future 
offer
improved chances to the Apache webserver. I can think of smartcards 
being an

increasingly used SSO alternative to NTLM especially in heterogeneous
environments.

I would appreciate it if you could take a look at the module and leave your
comments here.

Please note that this program is open source software and was released 
under the

GPL.
Also my employer has nothing to do with the release of this work. It has 
become

my private pleasure now :-)

Thanks and Greetings,
Johannes Müller

Re: Client authentication and authorization using client certificates

[Eric Covener]

On Tue, Jun 16, 2009 at 12:36 PM, Johannes Müllerjo...@gmx.de wrote:
 Hello,
 Please note that this program is open source software and was released under
 the GPL.

Regarding  the license: That's going to prevent some interested
parties from clicking through, much less contributing to it.

-- 
Eric Covener
cove...@gmail.com

Re: Client authentication and authorization using client certificates

[Johannes Müller]

Eric Covener wrote:

On Tue, Jun 16, 2009 at 12:36 PM, Johannes Müllerjo...@gmx.de wrote:
  

Hello,
Please note that this program is open source software and was released under
the GPL.



Regarding  the license: That's going to prevent some interested
parties from clicking through, much less contributing to it.

  

Better one would be Apache License 2.0 right?
I'm not too deep into license issues...

Re: Client authentication and authorization using client certificates

[Eric Covener]

On Tue, Jun 16, 2009 at 5:24 PM, Johannes Müllerjo...@gmx.de wrote:
 Eric Covener wrote:

 On Tue, Jun 16, 2009 at 12:36 PM, Johannes Müllerjo...@gmx.de wrote:


 Hello,
 Please note that this program is open source software and was released
 under
 the GPL.


 Regarding  the license: That's going to prevent some interested
 parties from clicking through, much less contributing to it.



 Better one would be Apache License 2.0 right?
 I'm not too deep into license issues...

That would remove the barrier and match the in-tree modules (if
there's no strong preference for another license, and the code is
yours to relicense)

-- 
Eric Covener
cove...@gmail.com

Re: Client authentication and authorization using client certificates

[Ruediger Pluem]

On 06/16/2009 11:24 PM, Johannes Müller wrote:
 Eric Covener wrote:
 On Tue, Jun 16, 2009 at 12:36 PM, Johannes Müllerjo...@gmx.de wrote:
  
 Hello,
 Please note that this program is open source software and was
 released under
 the GPL.
 

 Regarding  the license: That's going to prevent some interested
 parties from clicking through, much less contributing to it.

   
 Better one would be Apache License 2.0 right?

Correct. So relicensing it to Apache License 2.0 brings you in a better
position here. AFAIU you are the only author and contributor to this
module so far. So this should be easy.

Regards

Rüdiger

Re: Client authentication and authorization using client certificates

[Johannes Müller]

Ruediger Pluem wrote:

On 06/16/2009 11:24 PM, Johannes Müller wrote:
  

Eric Covener wrote:


On Tue, Jun 16, 2009 at 12:36 PM, Johannes Müllerjo...@gmx.de wrote:
 
  

Hello,
Please note that this program is open source software and was
released under
the GPL.



Regarding  the license: That's going to prevent some interested
parties from clicking through, much less contributing to it.

  
  

Better one would be Apache License 2.0 right?



Correct. So relicensing it to Apache License 2.0 brings you in a better
position here. AFAIU you are the only author and contributor to this
module so far. So this should be easy.

Regards

Rüdiger
  
Yes should be no problem. Relicensing means I'll also have to remove 
current the current
version and SVN revisions so there is no problem if someone already 
downloaded the

GPLed release?

Greetings
Johannes

Re: Client authentication and authorization using client certificates

[Eric Covener]

On Tue, Jun 16, 2009 at 5:40 PM, Johannes Müllerjo...@gmx.de wrote:
 Yes should be no problem. Relicensing means I'll also have to remove current
 the current
 version and SVN revisions so there is no problem if someone already
 downloaded the
 GPLed release?

IANAL: I don't see why, they're free to use it under those terms, and
you're free to change the terms of any subsequent release (or prior
release to other parties!)

-- 
Eric Covener
cove...@gmail.com

Module order for authentication/authorization

[Markus Moeller]

How can I make sure that an authentication/authorisation module is always the 
the last ?  I was thinking of the following case order (e.g. mapping is always 
after authentication, but before authorisation):

Kerberos authentication - gives u...@realm
ldap authentication   -  gives user
basic authentication -  gives user
mapping authenticated users (e.g. u...@realm to user)   

authorisation based on user or group.


Thank you
Markus

mod_cache and module-based authentication

[Jon Grov]

Sorry to bother you all, and first: thanks for building such a great product!

My question is related to the patch suggested by Paul Quenna (in
2005) where mod_cache is allowed to be configured to run as a normal
handler instead of always as a quick handler.

The initial patch and related discussion is here:
http://thread.gmane.org/gmane.comp.apache.devel/20314
with a follow-up related to bug 36937 here:
http://thread.gmane.org/gmane.comp.apache.devel/22676/focus=22679

Originally, the patch was voted down, and I see the rationale for not
including it without a clear use case. But in our setting, it would be
of high value to get it into the official release. I have outlined our syste 
below, in
the hope that someone can decide whether we are within the planned scope of
mod_cache or not.

** Motivation

Our server setup is as follows:

* PROXY: Apache 2.2.11 with mod_cache and mod_proxy.
* APPSERVER: A JavaEE application server running a Java-based CMS.

The main part of the motivation for PROXY is to reduce the need to
regenerate content by the heavyweight CMS-processes. Security is also handled
by PROXY, where we use Sun Access Manager to enforce policy-based
authentication. This is provided by running a policy agent which is loaded
as an Apache-module. Policies are specified on quite broad level, e.g. all 
users
that are marked 'internal' in our LDAP can see everything, others can see 
nothing.

When PROXY receives a request for a non-cached URL, the agent first
authenticates the user (either by using buil-in SSO modules or through
password authentication), and then decides whether the user is allowed
to access this URL. If so, the request is forwarded from PROXY to
APPSERVER and can be served without further validation.

The challenge is that since we use mod_cache on PROXY, requests that
can be served from cache are returned directly to the user - without
ever being seen by the policy agent.

This is of course as expected, since mod_cache uses a special quick
handler in Apache's request chain, allowing requests for cached
objects to be served with minimal processing overhead. But as noted
above, it is necessary for us to protect the cache against
unauthorized users.

Our current workaround is to run two reverse proxy-instances, one which
provides authentication (on port 80) and another providing cache (on port
7920, which is only accessible from within PROXY). A request then
first hits the authentication proxy on port 80, and if valid, is
forwarded to the caching proxy on local port 7920.

This works, but it feels somewhat suboptimal, and we would much prefer to be
able to use one instance to serve both purposes.

Thank you in advance for any assistance!



-- 
Kind regards,
Jon Grov

Re: mod_cache and module-based authentication

[Graham Leggett]

Jon Grov wrote:


Our current workaround is to run two reverse proxy-instances, one which
provides authentication (on port 80) and another providing cache (on port
7920, which is only accessible from within PROXY). A request then
first hits the authentication proxy on port 80, and if valid, is
forwarded to the caching proxy on local port 7920.

This works, but it feels somewhat suboptimal, and we would much prefer to be
able to use one instance to serve both purposes.


I have been tasked with solving a very similar problem: the ability to 
optionally place the cache anywhere in the output filter chain (instead 
of replacing the whole filter chain, as now).


The rationale is that we need to cache content before the INCLUDES 
filter gets hold of the content, and that is currently not possible. 
Give me a day or two.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

developing custom authentication module

[Sam Carleton]

I am ISV developing a system that is using Apache. All the frontend's
for system I am developing are all custom desktop applications, or web
browsers controls wrapped in my own code. Thus users are not going to
be entering username and password, the username and password used will
be depended on which frontend being used.

It is time for me to implement authentication correctly. I have two
objectives with respect to authentication:

1: Protect my customers from unauthorized users.
2: Protect myself from customers hacking the authorization system to
get access to features in which they have not purchased.

#1 looks straight forward: If my impression is correct, I simply need
to implement my own custom provider to check the custom username and
password the frontends give it.

Q: Is there documentation out there somewhere on how to implementing a
new provider?

#2 looks a lot more tricky. It seems that I will need to deviate from
the normal way Apache's authentication works. For starters, NONE of
the configuration can be in the http.conf, not like it is now with
AuthType, AuthBasicProvider, etc. There is a Location directives in
the conf that will have a custom directive for my custom Apache
module. I would like to fully wire up this custom provider within this
directive. To add to the complexity, there are different levels of
authentication: None required, user, admin and there will be different
locations under the Location directive for each, again, this all
needs to be wired up in code when the custom directive for my custom
Apache module is called.

Q: Any suggestions on how I might achieve this?

Sam

P.S. I do NOT own the book on writing Apache Module in 2.0, just the
older 1.3 book. Would any of this be addressed in that book?

handling custom authentication

[Sam Carleton]

I am ISV developing a system that is using Apache.  All the frontend's
for system I am developing are all custom desktop applications, or web
browsers controls wrapped in my own code.  Thus users are not going to
be entering username and password, the username and password used will
be depended on which frontend being used.

It is time for me to implement authentication correctly.  I have two
objectives with respect to authentication:

1: Protect my customers from unauthorized users.
2: Protect myself from customers hacking the authorization system to
get access to features in which they have not purchased.

#1 looks straight forward:  If my impression is correct, I simply need
to implement my own custom provider to check the custom username and
password the frontends give it.

Q: Is there documentation out there somewhere on how to implementing a
new provider?

#2 looks a lot more tricky.  It seems that I will need to deviate from
the normal way Apache's authentication works.  For starters, NONE of
the configuration can be in the http.conf, not like it is now with
AuthType, AuthBasicProvider, etc.  There is a Location directives in
the conf that will have a custom directive for my custom Apache
module.  I would like to fully wire up this custom provider within
this directive.  To add to the complexity, there are different levels
of authentication:  None required, user, admin  and there will be
different locations under the Location directive for each, again,
this all needs to be wired up in code when the custom directive for my
custom Apache module is called.

Q: Any suggestions on how I might achieve this?

Sam

P.S.  I do NOT own the book on writing Apache Module in 2.0, just the
older 1.3 book.  Would any of this be addressed in that book?

Re: Logging authentication requests

[Dave Ingram]

To clarify:
 Is it currently possible to log authentication requests (ideally both
 success and failure, individually)? If not, is it possible?

Meant: is it currently possible to do this with Apache 2.2 (perhaps
using an existing module)? If not, is it even theoretically possible?


Dave

RE: Logging authentication requests

[Houser, Rick]

Given what I learned writing my module, that would certainly work.  I
think you'd be hooking check_user_id with the very first call that
happens in that phase.  That said, I don't know if there might be a
better way to handle this... 



Thanks,

Rick Houser
Auto-Owners Insurance
Systems Support
(517)703-2580

-Original Message-
From: Dave Ingram [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 09, 2008 10:11 AM
To: modules-dev@httpd.apache.org
Subject: Logging authentication requests

Hi all,

Just thinking about logging...

Is it currently possible to log authentication requests (ideally both
success and failure, individually)? If not, is it possible? And where
should the module fit into the authentication chain? Is this related to
Rick Houser's earlier posts about wrapping an existing hook?


Dave

Logging authentication requests

[Dave Ingram]

Hi all,

Just thinking about logging...

Is it currently possible to log authentication requests (ideally both
success and failure, individually)? If not, is it possible? And where
should the module fit into the authentication chain? Is this related to
Rick Houser's earlier posts about wrapping an existing hook?


Dave

[PATCH] Add directive to skip authentication when using client certificates

[Müller Johannes]

Hello,

The following patch against trunk adds a directive AuthBasicUserFromSSL 
(On/Off) to mod_auth_basic.
Setting this to On would skip authentication if r-user is set by mod_ssl.
This is needed when using client certificates for authentication, because in 
this case you don't get any password from the user, which you can use to 
authenticate.
Well, there is FakeBasicAuth, but setting the password to password for every 
user in a directory is definitely no solution.

Would be nice if we could include this in 2.2.x too. The affected code is 
basically similar.

See also discussion at 
http://mail-archives.apache.org/mod_mbox/httpd-dev/200807.mbox/[EMAIL PROTECTED]

Configuration may look like this:

Location /secret_area
SSLUserName SSL_CLIENT_S_DN_CN
SSLVerifyClient require
AuthTypeBasic
AuthNameTest
AuthBasicUserFromSSLOn

AuthBasicProvider   ldap
AuthLDAPUrl 
ldap://myldapserver.company.com:389/ou=Users,o=COMPANY,c=COM?uid?sub
AuthLDAPBindDN  cn=myUser,ou=users,o=COMPANY,c=COM
AuthLDAPBindPasswordmyPassword

require ldap-group  cn=mygroup,ou=Groups,o=COMPANY,c=COM
/Location


Greetings,
Johannes Müller



mod_auth_basic.patch
Description: mod_auth_basic.patch

handling authentication

[Sam Carleton]

I am working on a ISV that is developing kiosk system with Apache at
the core.  Considering my many years of software development is in
Windows Application development, not web development, I am running
into some issues with authentication.  I am hoping to gain some
insight from those of you that know that understand web development
far better then I do.

Initially I thought that since the whole system is a kiosk system,
each kiosk would have a different IP address, so I could simply
differentiate by IP.  Low and behold I have customers that is use
solutions like NComputing, which allow one physical machine to be
turned into 4~6 different kiosk's, all having the same IP address.  So
the obvious easy solution is to move to using Cookies.  The problem I
am having is figuring out how exactly to implement it.

There are three different issues need to be implemented:

1: Making sure the browser is one of my kiosk browsers application
(right now I am doing this by changing the user agent, but am open to
other approaches)
2: Making sure each browser is uniquely identified.
3: Making sure that the number of browsers connected does not exceed
the customers license.

Right now the kiosk browser simply connects to the root of the
application, index.php.  The Apache module hooks the access checker
(ap_hook_access_checker):

A: Checks to see if there is a valid license.
B: Checks to user agent string to see if it is a kiosk browser
C: Based on the type of license, check to see how many clients have
connected (based on the IP) in the last X seconds.

When using cookies, where should I put the timer?  Should I have the
Apache module track when the last time a said cookie connected to the
module or should I simply set the cookie to timeout in X seconds and
renew it on each request?  I am thinking it should work like this:

A: Checks to see if there is a valid license.
B: Check for the cookie
C: There is a cookie, check to see if the cookie has expired, if so
continue, otherwise update the system concerning the cookie and return
OK.
D: Checks to user agent string to see if it is a kiosk browser
E: Based on the type of license, check to see how many clients have
connected (based on the cookies) in the last X seconds.

Later in the PHP code, I can use the cookie as the unique identifier.

From a security standpoint, is there anything I am missing?

Sam

Re: Apache support for form authentication

[Guenter Knauf]

Hi Graham,
 The mod_session_dbd module is written but not yet completely tested, and
 the mod_auth_form module is written, tested, but not yet documented.
 This should be completed over the next few days.
maybe you can already commit mod_auth_form for the un-patient even though
docu might not be ready yet? I've just now a little bit time to look into
building the whole session stuff properly on NetWare...

thanks, Guenter.

Re: Apache support for form authentication

[Graham Leggett]

Guenter Knauf wrote:


maybe you can already commit mod_auth_form for the un-patient even though
docu might not be ready yet? I've just now a little bit time to look into
building the whole session stuff properly on NetWare...


I just did :)

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache support for form authentication

[Guenter Knauf]

Hi Graham,
 maybe you can already commit mod_auth_form for the un-patient even though
 docu might not be ready yet? I've just now a little bit time to look into
 building the whole session stuff properly on NetWare...

 I just did :)
and even with docu!! Thanks very much!

Guenter.

Re: Apache support for form authentication

[Chris Darroch]

Graham Leggett wrote:

The session modules are all designed to go exclusively inside Directory 
and Location sections, which allow you to precisely target which URL 
space your session is valid for, and this can be repeated as many times 
as you like creating as many individual sessions as you like.


William A. Rowe, Jr. wrote:


Hmmm... why can't I use a session across an entire vhost?


  That was my first thought as well: If you visit this host, we'll
try to give you a session cookie.  Of course it could go into a
Location / but it's a little cleaner and more obvious if I can just
use it directly in the RSRC_CONF context as well.


Identify areas of the server where functionality is being reinvented 
over and over, and then create key modules, like mod_shmap and 
mod_session to replace the reinvented functionality.


  Agreed, and I suspect most folks are likely to be on board with that
overall aim; of course, the question becomes one of getting agreement
on which areas are in fact examples of duplicated logic, and of those
which deserve to remain independent implementations for reasons of
performance/clarity/etc. and which should be refactored.

Chris.

--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

Re: Apache support for form authentication

[Graham Leggett]

William A. Rowe, Jr. wrote:


Hmmm... why can't I use a session across an entire vhost?


As in RSRC_CONF|ACCESS_CONF?

Regards,
Graham
--



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache support for form authentication

[Graham Leggett]

Chris Darroch wrote:


  Great idea.  What would you think about converting from
the session_save hook to a provider-based mechanism?  I can
imagine that administrators might want/need to use one kind of
storage provider (dbd, say) for sessions on high-priority virtual hosts,
while using another less reliable storage provider on others.

  Maybe this is possible with hooks if the storage modules return
DECLINED unless they're the one that's most closely configured
with a particular request.  Still, it might be a little cleaner
if the caller just looks up the appropriate provider and calls it
directly.



  Again, great idea, thanks!


The session modules are all designed to go exclusively inside Directory 
and Location sections, which allow you to precisely target which URL 
space your session is valid for, and this can be repeated as many times 
as you like creating as many individual sessions as you like.


So for an online store, you might have example.com/store covered by a 
low security session keeping track of basic user details and a shopping 
cart, while example.com/checkout is protected by a separate high 
security session based on dbd or crypto.


Eg:

Location /store
  Session On
  SessionCookieName shopping
  ...
/Location
Location /checkout
  Session On
  SessionDBDCookieName checkout
  SessionCryptoPassphrase secret
  ...
/Location

Is this what you had in mind?


  Once more, with feeling, I'll plug the notion of a generic mod_shmap
that implements shared map (key/value pair) storage, using any of
various providers for each map: dbd, dbm, shared memory (w/ cyclic buffer),
distcache, maybe memcached, etc.


Definitely.

Something I would like to see for a future 2.4 or 3.0 release is to 
achieve the goal of consolidation:


Identify areas of the server where functionality is being reinvented 
over and over, and then create key modules, like mod_shmap and 
mod_session to replace the reinvented functionality.


Then: collapse the repeated code.

The ultimate goal will be a smaller, tighter, but significantly more 
flexible server.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache support for form authentication

[William A. Rowe, Jr.]

Graham Leggett wrote:


The session modules are all designed to go exclusively inside Directory 
and Location sections, which allow you to precisely target which URL 
space your session is valid for, and this can be repeated as many times 
as you like creating as many individual sessions as you like.


Hmmm... why can't I use a session across an entire vhost?  Or strictly
for handling a single cgi Files  pattern?

I can certainly understand why not a Method  considering that will
flip between GET/POST etc... although it's probably not an issue.

Apache support for form authentication

[Graham Leggett]

Hi all,

Despite having a very capable pluggable aaa subsystem built into httpd, 
the two main mechanisms for access remain mod_auth_basic and 
mod_auth_digest.


Many web applications demand more flexible or user friendly ways to log 
into the server, and so every application server out there has developed 
its own custom login subsystem to make this happen.


Usually implementing some kind of single signon involves standardising 
on a particular brand of application server, with lots of unpleasant 
side effects caused by the lockin that results, or a ridiculously heavy 
server platform to do a simple login form.


It would be significantly simpler to teach Apache how to do form logins, 
and hide each vendor specific application server behind a reverse proxy 
that handles the login. The missing piece of course is the module 
mod_auth_form to make this happen.


Writing mod_auth_form uncovered an underlying issue - once the user 
credentials have been captured from the form, they need to be stored 
within a session somewhere that persists across browser requests.


Different application servers have different methods for handling 
sessions, each with its own strengths and weaknesses. Some sessions are 
stored as Java objects, and can only be shared with other Java based 
application servers. Some sessions might be stored in a database, which 
then presents a scaling problem.


It became clear that the session problem was an issue all on its own, 
and that one size definitely does not fit all.


The solution was an Apache module called mod_session, which provides a 
simple and generic session interface to httpd.


What is a session?

A session is a simple table of key value pairs. The significance of the 
key value pairs is up to the user of the session. In the case of 
mod_auth_form, it cares about two keys called user and pw.


Where do the sessions get stored?

That's up to further small submodules, which can be chosen by the 
administrator depending on their needs.


mod_session_dbd stores sessions within a SQL database. The session is 
tracked by a cookie, very similar to a typical Tomcat session. The catch 
is that you need a database beefy enough to handle the resulting load, 
which may or may not be a problem for the admin, they can decide.


Alternatively, mod_session_cookie stores sessions directly in a cookie 
on the browser. No server resources are taken up by sessions, which 
makes this very efficient. Obviously privacy is an issue, which is 
potentially solved by:


mod_session_crypto encrypts and decrypts the contents of a session 
before the session is either written to a SQL database, or sent to the 
user in a cookie. Being pluggable, mod_session_crypto can be excluded 
from the server where restrictions exist on the use of encryption.


Who can use the session?

Any other Apache or third party modules can use the session interface, 
and the hope is that having a standard session raises the chance that 
modules may be able to cooperate on how they share data.


mod_auth_form is the first obvious customer. Even CGI programs have a 
mechanism to access the session, if allowed by the admin.


So where are the modules?

The mod_session and mod_session_cookie modules are done and documented, 
and the plan is commit them shortly to give them a wider audience and 
get feedback on them.


The mod_session_crypto module is also done and documented, however I 
want to commit that separately so that issues with how the crypto is 
handled can be approached as a separate unit.


The mod_session_dbd module is written but not yet completely tested, and 
the mod_auth_form module is written, tested, but not yet documented. 
This should be completed over the next few days.


Why so many modules?

Breaking the problem down into individual components has made the 
session handling significantly simpler to work with and understand. In 
addition, the use of crypto has dictated that the crypto portion be 
pluggable for those regions where it is required to be excluded.


It is hoped that with a standard session interface, the number of ad-hoc 
solutions out there for solving the session problem can be reduced 
significantly.


I hope to have the bulk of this committed before Apachecon so that 
people can take a look. Will follow up shortly.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache support for form authentication

[Nick Kew]

On Fri, 04 Apr 2008 17:03:06 +0200
Graham Leggett [EMAIL PROTECTED] wrote:

 It would be significantly simpler to teach Apache how to do form
 logins,

+1.  It's something no doubt most of us have reinvented.
A standardised/bundled solution would be great!

 It is hoped that with a standard session interface, the number of
 ad-hoc solutions out there for solving the session problem can be
 reduced significantly.
 
 I hope to have the bulk of this committed before Apachecon so that 
 people can take a look. Will follow up shortly.

If it's there before I go, I'll take a look en route.
See you at the hackathon?

One more point.  Stepping up a level, the session management
wants to be unified with other logins, even those that don't need it.
Especially those popular amongst SSO folks, like LDAP.
Hopefully that'll come for free with your modules!

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: Apache support for form authentication

[Chris Darroch]

Graham Leggett wrote:


A session is a simple table of key value pairs.


mod_session_dbd stores sessions within a SQL database. The session is 
tracked by a cookie, very similar to a typical Tomcat session. The catch 
is that you need a database beefy enough to handle the resulting load, 
which may or may not be a problem for the admin, they can decide.


  Great idea.  What would you think about converting from
the session_save hook to a provider-based mechanism?  I can
imagine that administrators might want/need to use one kind of
storage provider (dbd, say) for sessions on high-priority virtual hosts,
while using another less reliable storage provider on others.

  Maybe this is possible with hooks if the storage modules return
DECLINED unless they're the one that's most closely configured
with a particular request.  Still, it might be a little cleaner
if the caller just looks up the appropriate provider and calls it
directly.

  Again, great idea, thanks!


  Once more, with feeling, I'll plug the notion of a generic mod_shmap
that implements shared map (key/value pair) storage, using any of
various providers for each map: dbd, dbm, shared memory (w/ cyclic buffer),
distcache, maybe memcached, etc.

  It would seem that mod_session would be an ideal potential customer
for such a storage provider system, along with mod_proxy (for the stuff it
shoehorns into the scoreboard now), mod_ssl, mod_auth_digest, and
perhaps even the scoreboard itself.

  Administrators could set the storage provider for each individually.
A default setup might use shmem for mod_proxy, distcache for mod_ssl and
mod_auth_digest caches (would be nice to finally enable mod_auth_digest's
shared cache code!), and dbd for user sessions.  The trade-offs are the
usual ones of performance vs. scalability/persistance/reliability.

  See http://marc.info/?l=apache-httpd-devm=120491055413781w=2
for a proposed ap_shmap.h based on Joe Orton's refactoring of
mod_ssl's session cache code.

  I can't be at the conference next week but I'd be willing to
hack on either trunk, or perhaps better, a branch, per Paul Querna's
suggestion.  A way to start might be to take Joe Orton's latest
dbm and shmem cyclic buffer providers and try to get mod_session +
mod_shmap + {mod_shmap_dbm, mod_shmap_shmem} working as a proof of
concept.  Thoughts?

Chris.

--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B