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 concern is with multiple LDAPs, the multiple password file case makes good sense, for instance.

Jess Holle

Geoffrey Young wrote:
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


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.
There are two options to this:

- Teach each provider how to handle multiple instances of itself (sounds
like too much duplication)
- Introduce a concept like this:

<Auth ldap-provider-A>
  # LDAP stuff for LDAP server A
<Auth ldap-provider-B>
  # LDAP stuff for LDAP server B

AuthBasicProvider ldap-provider-A ldap-provider-B
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

AuthBasicProvider file
AuthFileName file1 file2

if AuthFileName were ITERATE mod_authn_file would know that it should not
return AUTH_USER_NOT_FOUND until it has checked all the files present.  or
somesuch off the top of my head.

are there situations specific to ldap that would make some variant of this
difficult or unacceptable? I'm just trying to get a better feel for why the
exception you raise isn't an issue for providers to locally figure out