Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 77065 invoked from network); 2 Mar 2005 16:39:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 2 Mar 2005 16:39:22 -0000 Received: (qmail 14756 invoked by uid 500); 2 Mar 2005 16:39:17 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 14703 invoked by uid 500); 2 Mar 2005 16:39:17 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 14686 invoked by uid 99); 2 Mar 2005 16:39:17 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from relay2.ptc.com (HELO relay2.ptc.com) (12.11.148.122) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 02 Mar 2005 08:39:15 -0800 Received: from hq-exfe1.ptcnet.ptc.com (132.253.201.60) by relay2.ptc.com with ESMTP; 02 Mar 2005 11:40:10 -0500 X-IronPort-AV: i="3.90,130,1107752400"; d="scan'208,217"; a="12070126:sNHT27334188" Received: from [132.253.40.151] ([132.253.40.151]) by HQ-EXFE1.ptcnet.ptc.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Mar 2005 11:39:21 -0500 Message-ID: <4225EC39.3040500@ptc.com> Date: Wed, 02 Mar 2005 10:39:21 -0600 From: Jess Holle User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: Multiple AAA providers References: <49679.67.138.149.162.1109684861.squirrel@67.138.149.162> <19396.196.8.104.37.1109686697.squirrel@www.sharp.fm> <42247D3D.2020909@ptc.com> <41839.196.8.104.37.1109688338.squirrel@www.sharp.fm> <42249D6C.2060103@ptc.com> <39952.196.8.104.37.1109755200.squirrel@www.sharp.fm> <4225B0F5.6010704@modperlcookbook.org> <37477.196.8.104.37.1109767704.squirrel@www.sharp.fm> <4225BE89.1090004@modperlcookbook.org> <52188.196.8.104.37.1109772635.squirrel@www.sharp.fm> <20050302155250.GS4351@scotch.ics.uci.edu> In-Reply-To: <20050302155250.GS4351@scotch.ics.uci.edu> Content-Type: multipart/alternative; boundary="------------060007090206090302050400" X-OriginalArrivalTime: 02 Mar 2005 16:39:21.0405 (UTC) FILETIME=[62B3CED0:01C51F46] X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --------------060007090206090302050400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Justin Erenkrantz wrote: >On Wed, Mar 02, 2005 at 04:10:35PM +0200, Graham Leggett wrote: > > >>The end goal is to simplify the providers so that you do not have to teach >>each one how to handle multiple sources. The problem with implementing >>multiple sources in one provider is that the end users assumes that the >>same is possible in other providers, and is surprised when they find out >>the hard way it's not. >> >> >I don't believe it would simplify anything other than mod_auth_ldap. > > As I really only care about mod_auth_ldap, that's fine by me. If I cared about any other authentication module, however, I'd want this done in a completely general way across all modules. Why? So I could rely on being able to do this with any/all authentication modules with a consistent configuration approach. Doing this in each module will result in only a handful doing it and each doing it differently. Again, I really only care about LDAP, though, so I'd be happy with inconsitency, etc -- as long as it solves the issue for LDAP authentication. -- Jess Holle --------------060007090206090302050400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Justin Erenkrantz wrote:

On Wed, Mar 02, 2005 at 04:10:35PM +0200, Graham Leggett wrote:

The end goal is to simplify the providers so that you do not have to teach
each one how to handle multiple sources. The problem with implementing
multiple sources in one provider is that the end users assumes that the
same is possible in other providers, and is surprised when they find out
the hard way it's not.

I don't believe it would simplify anything other than mod_auth_ldap.

As I really only care about mod_auth_ldap, that's fine by me.

If I cared about any other authentication module, however, I'd want this done in a completely general way across all modules. Why? So I could rely on being able to do this with any/all authentication modules with a consistent configuration approach. Doing this in each module will result in only a handful doing it and each doing it differently.

Again, I really only care about LDAP, though, so I'd be happy with inconsitency, etc -- as long as it solves the issue for LDAP authentication.

--
Jess Holle

--------------060007090206090302050400--