It done and checked into 2.2. I posted several messages to this mailing list
last week and this week. There is a new module called mod_auth_alias that
allows you to create alias providers giving you the ability to to create
alternate providers to different ldap servers that will be called du
Brad Nicholes wrote:
It done and checked into 2.2. I posted several messages to this mailing list last week and this week. There is a new module called mod_auth_alias that allows you to create alias providers giving you the ability to to create alternate providers to different ldap serve
Jess Holle wrote:
> In our case it does not depend which is checked first (except perhaps
> for performance) as there will not be any overlap between the
> directories. For instance, one LDAP might be for corporation X and
> another for one of their partners. Another example: one might be a
> rea
On 27-May-05, at 10:53 AM, Jess Holle wrote:
Russell Howe wrote:Jess Holle wrote:
Is there any remaining/ongoing interest in this development area?
The need to authenticate a single resource against multiple disparate
(non-failover/non-redundant) LDAP servers looms large and I'd like to
th
Russell Howe wrote:
Jess Holle wrote:
Is there any remaining/ongoing interest in this development area?
The need to authenticate a single resource against multiple disparate
(non-failover/non-redundant) LDAP servers looms large and I'd like to
think that this would be part of Apac
Jess Holle wrote:
> Is there any remaining/ongoing interest in this development area?
>
> The need to authenticate a single resource against multiple disparate
> (non-failover/non-redundant) LDAP servers looms large and I'd like to
> think that this would be part of Apache 2.2 soon... [I'd rather
Is there any remaining/ongoing interest in this development area?
The need to authenticate a single resource against multiple disparate
(non-failover/non-redundant) LDAP servers looms large and I'd like to
think that this would be part of Apache 2.2 soon... [I'd rather not
have to hack this i
Here is the second attempt which actually works. It still needs some
cleanup and auth_digest has not been accounted for yet, but it does let you
define and call multiple alias providers that can be referenced from multiple
locations. I would like to add it to modules/aaa if there are no obj
Here is an attempt at providing this functionality through a separate module
called mod_authn_alias. It follows the syntax outlined in the previous message
thread http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=110995646219340&w=2
. However, I have run into a road block. In order to ma
Has there been any further motion on the multiple AAA provider issue in 2.1?
Our customers really need to be able to directly authenticate against
multiple LDAPs (again, this is not a failover case -- the contents of
each LDAP are distinct and non-overlapping).
I *suspect* we're not the only one
--On Monday, March 7, 2005 5:47 PM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
Absolutely not my intention. Again, I do not want to have each
provider have to reimplement the same code and parsing. I want
a single module to do so, and the providers to be oblivious
(but still work.)
>>I believe that we are talking about coding at the provider layer
(ldap,
>>file, etc.).
>
>Absolutely not my intention. Again, I do not want to have each
>provider have to reimplement the same code and parsing. I want
>a single module to do so, and the providers to be oblivious
>(but still work.
At 10:11 AM 3/7/2005, Brad Nicholes wrote:
>I believe that we are talking about coding at the provider layer (ldap,
>file, etc.).
Absolutely not my intention. Again, I do not want to have each
provider have to reimplement the same code and parsing. I want
a single module to do so, and the provid
I believe that we are talking about coding at the provider layer (ldap,
file, etc.). The problem here is that I am not sure what the following
means:
>> [ ] Implement globally across schemes and providers
>> Single directive, but as it's not in the
scheme
>> which iterates the providers,
On Mon, Mar 07, 2005 at 12:16:05AM -0600, William A. Rowe, Jr. wrote:
> >These choices overlook Brad's suggestion, which I still think is the best:
> >
> > [ ] Implement across providers
> > Single directive.
>
> I did not overlook it.
>
> What layer do you propose to code it at?
Did you
At 12:03 PM 3/6/2005, Justin Erenkrantz wrote:
>On Sat, Mar 05, 2005 at 10:59:30PM -0600, William A. Rowe, Jr. wrote:
>> Ok, as Justin and I are in significant disagreement ... to summarize;
>>
>> we (collectively) would like to see some mechanism for multiple
>> configurations of the same 'provid
On Sat, Mar 05, 2005 at 10:59:30PM -0600, William A. Rowe, Jr. wrote:
> Ok, as Justin and I are in significant disagreement ... to summarize;
>
> we (collectively) would like to see some mechanism for multiple
> configurations of the same 'provider' (defined above). There are
> logically three pl
At 11:54 AM 3/5/2005, Justin Erenkrantz wrote:
>--On Friday, March 4, 2005 12:42 PM -0600 "William A. Rowe, Jr." <[EMAIL
>PROTECTED]> wrote:
>
>>Or is a provider File, DBM, LDAP?
>
>Yes. [...] obviously, you're not with me here. =) -- justin
Ok, as Justin and I are in significant disagreement .
--On Friday, March 4, 2005 12:42 PM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
We have a naming problem. Provider is meaningless.
No, it's not. It's directly from the code and API itself. See
ap_provider.h.
Is a provider Basic, Digest?
No. These are the auth mechanisms which *ca
At 11:34 AM 3/4/2005, Justin Erenkrantz wrote:
>--On Friday, March 4, 2005 11:27 AM -0600 "William A. Rowe, Jr." <[EMAIL
>PROTECTED]> wrote:
>
>>yup, that's what mod_auth_config did. However, mod_auth_config;
>>
>> 1. invokes auth for the local directives (not sectioned)
>>
>> 2. invokes auth fo
--On Friday, March 4, 2005 11:27 AM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
yup, that's what mod_auth_config did. However, mod_auth_config;
1. invokes auth for the local directives (not sectioned)
2. invokes auth for all sections.
providing the explicit list in AuthBasicProvi
At 11:14 AM 3/4/2005, Justin Erenkrantz wrote:
>--On Friday, March 4, 2005 8:56 AM -0700 Brad Nicholes <[EMAIL PROTECTED]>
>wrote:
>
>>Actually I think the better syntax would be:
>>
>>
>> ...config options for mod_authnz_ldap...
>>
>>
>>
>> ...config options for mod_authnz_ldap...
>>
>>
>>
>>
At 01:30 AM 3/4/2005, Justin Erenkrantz wrote:
>On Thu, Mar 03, 2005 at 08:40:22PM -0600, William A. Rowe, Jr. wrote:
>> And attached is the module for comment. I have no time till this
>> weekend if then, so I've got the build system changes and will
>> commit if we like.
>
>My question as to how
--On Friday, March 4, 2005 8:56 AM -0700 Brad Nicholes
<[EMAIL PROTECTED]> wrote:
Actually I think the better syntax would be:
...config options for mod_authnz_ldap...
...config options for mod_authnz_ldap...
...config options for mod_auth...
AuthProvider Myldap1 Myfile1
...
Actually I think the better syntax would be:
...config options for mod_authnz_ldap...
...config options for mod_authnz_ldap...
...config options for mod_auth...
AuthProvider Myldap1 Myfile1
...Other config options...
AuthProvider Myldap2 Myfile1
...Other config opt
Justin Erenkrantz said:
> I still maintain the better way to do this is to handle it in the provider
> modules themselves by leveraging the provider API instead.
>
> To reiterate, in my mind, the ideal syntax is:
>
>
>
> ...config options for mod_authnz_ldap...
>
>
> ...confi
On Thu, Mar 03, 2005 at 08:40:22PM -0600, William A. Rowe, Jr. wrote:
> And attached is the module for comment. I have no time till this
> weekend if then, so I've got the build system changes and will
> commit if we like.
My question as to how this would interact with the auth providers is still
At 11:13 PM 3/2/2005, William A. Rowe, Jr. wrote:
>x>>No - simply create a per-dir config, and use dirconfig to represent;
>>>
AuthFile users1
>>
>>How does that work? The issue here is that we want to use the same module
>>multiple times in the same location/directory/file.
William A. Rowe, Jr. wrote:
At 04:06 PM 3/2/2005, Justin Erenkrantz wrote:
--On Wednesday, March 2, 2005 2:07 PM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
No - simply create a per-dir config, and use dirconfig to represent;
A
At 04:06 PM 3/2/2005, Justin Erenkrantz wrote:
>--On Wednesday, March 2, 2005 2:07 PM -0600 "William A. Rowe, Jr." <[EMAIL
>PROTECTED]> wrote:
>
>>No - simply create a per-dir config, and use dirconfig to represent;
>>
>>>
>>> AuthFile users1
>>>
>>
>>This would give us the best of both worl
--On Wednesday, March 2, 2005 2:07 PM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
No - simply create a per-dir config, and use dirconfig to represent;
AuthFile users1
This would give us the best of both worlds. It's no different from
the use of Location, Directory, and File
Actually I think I like Justin's idea best. That way you can actually
define one provider profile and then reuse it wherever needed just by
referencing the provider. This would avoid duplication of auth
directives if you have multiple secure locations or virtual hosts. If
this were implemented w
At 01:36 PM 3/2/2005, Brad Nicholes wrote:
>Although I agree that this would probably be the best way to go, I don't
>think it will be that simple. Authnz_ldap stores the LDAPurl and other
>information (bind user id, bind password, certs, etc) in a per-Dir
>structure. At the very least, authnz_ld
--On Wednesday, March 2, 2005 12:36 PM -0700 Brad Nicholes
<[EMAIL PROTECTED]> wrote:
Although I agree that this would probably be the best way to go, I don't
think it will be that simple. Authnz_ldap stores the LDAPurl and other
information (bind user id, bind password, certs, etc) in a per-Dir
--On Wednesday, March 2, 2005 12:14 PM -0600 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
Bleh. Wouldn't it be easier not to rearchitect the whole thing?
I believe this config syntax is orthogonal to the auth provider scheme.
There are completely independent of each other.
What about the
Although I agree that this would probably be the best way to go, I don't
think it will be that simple. Authnz_ldap stores the LDAPurl and other
information (bind user id, bind password, certs, etc) in a per-Dir
structure. At the very least, authnz_ldap would have to be taught how
to store multipl
Bleh. Wouldn't it be easier not to rearchitect the whole thing?
What about the core or mod_auth respecting something like;
AuthFile users1
AuthFile users2
Simply use the existing scope, inheritance, and so on. Whenever
multiple AuthConfigs apply to a given scope, ite
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 en
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 p
On Wed, Mar 02, 2005 at 08:24:25AM -0500, Geoffrey Young wrote:
> while I don't claim to have more than a cursory understanding of ldap, I
> would think these cases could be handled by extending the current situation
> a bit. for instance, for the file provider something like
>
> AuthBasicProvide
On Wed, Mar 02, 2005 at 07:52:30AM -0600, Jess Holle wrote:
> This is essentially describing Graham's first option -- which is
> workable. It just requires extra work from each and every auth module
> author -- thus leading to a likelihood of some providing this and others
> not doing so. It w
> AUTH_USER_NOT_FOUND acts as AUTH_DECLINED.
>
> The auth modules loop until it runs out of providers or it receives something
> other than AUTH_USER_NOT_FOUND. -- justin
duh. I saw that but was reading the logic wrong. thanks :)
--Geoff
On Wed, Mar 02, 2005 at 07:26:29AM -0500, Geoffrey Young wrote:
> I think we just need another status besides
>
> typedef enum {
> AUTH_DENIED,
> AUTH_GRANTED,
> AUTH_USER_FOUND,
> AUTH_USER_NOT_FOUND,
> AUTH_GENERAL_ERROR
> } authn_status
>
> something like AUTH_DECLINED, whi
> To fill out the example of the "Auth" container to better illustrate what
> I mean, you might have this:
>
>
> require ldap-group cn=Accounting,ou=Groups,ou=XXX
> AuthLDAPBindDN cn=Mail,dc=XXX
> AuthLDAPBindPassword blah1
> LDAPTrustedMode SSL
> AuthLDAPURL ldaps://xxx.co.za/dc=xxx,d
Geoffrey Young said:
> isn't this kind of thing really up to the provider itself? I would think
> that the provider would need to be intelligent enough to understand when
> to
> iterate over directories or files and when not to.
The end goal is to simplify the providers so that you do not have t
This is essentially describing Graham's first option -- which is
workable. It just requires extra work from each and every auth module
author -- thus leading to a likelihood of some providing this and
others not doing so. It would be good to have a level of consistency.
Though my primary con
Graham Leggett wrote:
Geoffrey Young said:
I think we just need another status besides
typedef enum {
AUTH_DENIED,
AUTH_GRANTED,
AUTH_USER_FOUND,
AUTH_USER_NOT_FOUND,
AUTH_GENERAL_ERROR
} authn_status
something like AUTH_DECLINED, which would mean that the current provider
is
pass
> This solves the problem for multiple providers, but the problem isn't
> solved for where the same provider is used twice, for example:
>
> - If user is present in file A or file B
> - If user is present in directory A or directory B
hmm...
isn't this kind of thing really up to the provider it
Geoffrey Young said:
> I think we just need another status besides
>
> typedef enum {
> AUTH_DENIED,
> AUTH_GRANTED,
> AUTH_USER_FOUND,
> AUTH_USER_NOT_FOUND,
> AUTH_GENERAL_ERROR
> } authn_status
>
> something like AUTH_DECLINED, which would mean that the current provider
> is
> This functionality would be useful for more than just LDAP: you might want
> to use two different flat file databases, or maybe you want to auth
> someone in LDAP and someone else in SQL.
>
> This is really an AAA-wide question rather than an LDAP specific question.
>
> Anyone know how difficu
Jess Holle said:
> The use cases are:
>
>1. multiple organizations, each with their own LDAP wish to allow
> their personnel into a common site -- each has its own, separately
> administered LDAP
>2. a single organization has a read-only internal LDAP and a writable
> LDA
51 matches
Mail list logo
