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 core or mod_auth respecting something like;
<Location /protected>
<AuthConfig> AuthFile users1 </AuthConfig>
<AuthConfig> AuthFile users2 </AuthConfig>
Simply use the existing scope, inheritance, and so on. Whenever multiple AuthConfigs apply to a given scope, iterate them until satisfied.
The issue here is that it doesn't indicate which auth mechanism to use (basic or digest). That's the critical part. And, is the order now implicit based on the ordering in the conf file? I think it should be explicit. So, there's lots of pragmatic issues with this approach.
I'm concerned that the more complex each auth provider needs to be, the more probability that there will be logic errors in the provider.
I really feel that most auth providers would become more complex if you take this approach. We'd also have to spend a lot of cycles verifying that the 'AuthConfig' block is valid at config-time - AuthFile and AuthDBFile and AuthLDAPURL couldn't be in the same block.
I'd prefer that we use provider-specific blocks instead. Furthermore, I would suggest that mod_authnz_ldap grows this grouping first and then we can make a judgment about how complex it is and how much reuse is realistic between modules. -- justin
