Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass
On Mon, Jun 19, 2017 at 5:49 PM, Jacob Championwrote: > 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
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
On Mon, Jun 19, 2017 at 5:41 PM, Jacob Championwrote: > 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
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
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
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
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
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
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
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 ?
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 ?
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
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
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
--- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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