Re: Multiple AAA providers
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 in in a narrow, special-cased, hackish way myself...] -- Jess Holle
Re: Multiple AAA providers
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 not have to hack this in in a narrow, special-cased, hackish way myself...] I have a JAAS LoginModule which I wrote for Jetty that does exactly this (if I understand what you mean, that is :). At work, I have our website authentication first checking OpenLDAP, then falling back to Win2k Active Directory. I want to be able to do the same from Apache, and am pretty tempted to start coding up a module to do it. -- Russell Howe [EMAIL PROTECTED] Today's Nemi: http://www.metro.co.uk/img/pix/nemi_may27.jpg smime.p7s Description: S/MIME Cryptographic Signature
Re: Multiple AAA providers
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 Apache 2.2 soon... [I'd rather not have to hack this in in a narrow, special-cased, hackish way myself...] I have a JAAS LoginModule which I wrote for Jetty that does exactly this (if I understand what you mean, that is :). At work, I have our website authentication first checking OpenLDAP, then falling back to Win2k Active Directory. 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 read-only corporate directory and another might be an application writable directory (for pseudo-users, guest accounts, etc). [By disparate/non-failover/non-redundant, I mean that each LDAP would be checked for a given user until that user entry was found (at which point no other LDAPs would be checked for the given user regardless of the success/failure of the bind). This differs from strictly failover LDAPs wherein Apache keeps trying to contact LDAP URLs until it finds one that responds (is up) and then just uses that one as "the" LDAP -- we have that now but it does not help in these use cases.] I want to be able to do the same from Apache, and am pretty tempted to start coding up a module to do it. There was discussion some time back (under the same title as this thread) about doing this in a somewhat general fashion so one could have multiple LDAP providers, multiple password file providers, etc... That would be a great grand unified theory (and I see it as useful) but what I care most about is multiple LDAPs. If we could just have the existing mod_auth_ldap handle multiple LDAPs (beyond in a strict failover capacity) that would be *huge*. If we can't get the grand unified approach, I'd at least like to see multiple LDAP handling. -- Jess Holle
Re: Multiple AAA providers
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 think that this would be part of Apache 2.2 soon... [I'd rather not have to hack this in in a narrow, special-cased, hackish way myself...] I have a JAAS LoginModule which I wrote for Jetty that does exactly this (if I understand what you mean, that is :). At work, I have our website authentication first checking OpenLDAP, then falling back to Win2k Active Directory. [By disparate/non-failover/non-redundant, I mean that each LDAP would be checked for a given user until that user entry was found (at which point no other LDAPs would be checked for the given user regardless of the success/failure of the bind). This differs from strictly failover LDAPs wherein Apache keeps trying to contact LDAP URLs until it finds one that responds (is up) and then just uses that one as the LDAP -- we have that now but it does not help in these use cases.] I want to be able to do the same from Apache, and am pretty tempted to start coding up a module to do it. That would be a great grand unified theory (and I see it as useful) but what I care most about is multiple LDAPs. If we could just have the existing mod_auth_ldap handle multiple LDAPs (beyond in a strict failover capacity) that would be *huge*. If we can't get the grand unified approach, I'd at least like to see multiple LDAP handling. I'm very interested in implementing this myself. To make what I'm doing more generally useful, I'd like to know what people expect from the implementation of Require after a multiple LDAP search. Should you be able to put the ldap server name in a Require? Or are you only concerned with require valid-user?
Re: Multiple AAA providers
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 read-only corporate directory and another might be an application writable directory (for pseudo-users, guest accounts, etc). Same for me here. We actually have a mixture - ldap search for collective accounts shared by groups of people (these will go, given time), LDAP search on an OpenLDAP server (hopefully a redundant pair) and an LDAP search on the Win2k domain controllers (two of them, if one's not available, fall back to the other). JAAS does all the hard work for me in Java though, as regards trying multiple authentication modules. Apparently they copied the configuration scheme from PAM, or at least tried to make it PAM-like. There was discussion some time back (under the same title as this thread) about doing this in a somewhat general fashion so one could have multiple LDAP providers, multiple password file providers, etc... That would be a great grand unified theory (and I see it as useful) but what I care most about is multiple LDAPs. If we could just have the existing mod_auth_ldap handle multiple LDAPs (beyond in a strict failover capacity) that would be *huge*. If we can't get the grand unified approach, I'd at least like to see multiple LDAP handling. Ah, I see what you mean - it would appear that while you can chain authentication methods, they have to be different methods, taking different options. Am I getting that right? If so, I can't readily port my Java authentication scheme to Apache :/ Here is my latest posting to jetty-discuss, talking about the LoginModule. Hopefully it is enough to give a rough idea of what it does. http://news.gmane.org/navbar.php?group=gmane.comp.java.jetty.generalarticle=5749next=5750prev=5756newsrc=,5749-5750,5763 -- Russell Howe [EMAIL PROTECTED] Today's Nemi: http://www.metro.co.uk/img/pix/nemi_may27.jpg smime.p7s Description: S/MIME Cryptographic Signature
Re: Multiple AAA providers
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 servers that will be called during a single authentication request. Check out http://httpd.apache.org/docs-2.1/mod/mod_authn_alias.html Cool. I'll have to check this out! [I don't know how I missed this!] -- Jess Holle [EMAIL PROTECTED] Friday, May 27, 2005 9:22:52 AM 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 in in a narrow, special-cased, hackish way myself...] -- Jess Holle
Re: Multiple AAA providers
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 during a single authentication request. Check out http://httpd.apache.org/docs-2.1/mod/mod_authn_alias.html Brad [EMAIL PROTECTED] Friday, May 27, 2005 9:22:52 AM 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 in in a narrow, special-cased, hackish way myself...] -- Jess Holle
mod_authn_alias attempt (was Re: Multiple AAA Providers)
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-devm=110995646219340w=2 . However, I have run into a road block. In order to make this work, mod_authn_alias needs to be able to retrieve the aliased per_dir configuration and merge it into the current per_dir configuration before calling the real check_password() provider function. I'm just not sure how to make this happen given the amount of information that mod_authn_alias has at the point when the merge_per_dir_config needs to happen. Any ideas? Brad [EMAIL PROTECTED] Friday, April 29, 2005 9:16:44 AM 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 ones who need multiple AAA data sources of a single type, especially LDAP. -- Jess Holle mod_authn_alias.c Description: Binary data
Re: Multiple AAA providers
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 'provider' (defined above). There are logically three places this can happen, so as a straw poll, would those interested in *coding* auth schemas please vote (end users, our choice will be transparent enough to you that we prefer the developers to indicate their preferences.) [ ] Implement in each provider (e.g. mod_authnz_ldap, mod_authn_file) Different AuthLdapConfig xxx AuthFileConfig zzz sections [ ] Implement in each scheme (e.g. basic, digest) Different AuthBasicConfig xxx AuthDigestConfig zzz sections [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. These choices overlook Brad's suggestion, which I still think is the best: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. I did not overlook it. What layer do you propose to code it at?
Re: Multiple AAA 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 AuthProviderAlias real-provider-name alias directive. I did not overlook it. What layer do you propose to code it at? Did you forget my reply to Brad? I said that it'd be a module that exposes 'fake' new providers that merges in the appropriate per_dir_config before calling the real auth providers. I have not yet heard a reason why this would be an unsatisfactory solution. -- justin
Re: Multiple AAA providers
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 AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. But I do know what this means: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. If they are saying the same thing then we might all be on the same page. Now would be a great time to have one of those white board discussions like we have at ApacheCon :). I would like to see us implement a syntax that can be reused as I suggested earlier. An AuthProviderAlias ... tag would allow for that. I am -1 to Bill's original proposal mainly because each use of an auth module requires that it be reconfigured within it's Location even if the configurations across Locations are identical. If Bill's original proposal was reworked to pull the AuthConfig out of the Location scope and allow it to be reused as an alias, then I am +1. Brad [EMAIL PROTECTED] Sunday, March 06, 2005 11:16 PM 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 'provider' (defined above). There are logically three places this can happen, so as a straw poll, would those interested in *coding* auth schemas please vote (end users, our choice will be transparent enough to you that we prefer the developers to indicate their preferences.) [ ] Implement in each provider (e.g. mod_authnz_ldap, mod_authn_file) Different AuthLdapConfig xxx AuthFileConfig zzz sections [ ] Implement in each scheme (e.g. basic, digest) Different AuthBasicConfig xxx AuthDigestConfig zzz sections [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. These choices overlook Brad's suggestion, which I still think is the best: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. I did not overlook it. What layer do you propose to code it at?
Re: Multiple AAA providers
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 providers to be oblivious (but still work.) [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. If they are saying the same thing then we might all be on the same page. Now would be a great time to have one of those white board discussions like we have at ApacheCon :). Agreed :) I would like to see us implement a syntax that can be reused as I suggested earlier. An AuthProviderAlias ... tag would allow for that. I am -1 to Bill's original proposal mainly because each use of an auth module requires that it be reconfigured within it's Location even if the configurations across Locations are identical. That's not accurate. It's allowed, but remember inheritance applies, In the module I already hacked, it's possible to VirtualHost xxx AuthConfig AuthDirectives /AuthConfig and that will also be inherited. But I didn't propose named aliases, which could be a very cool idea. If Bill's original proposal was reworked to pull the AuthConfig out of the Location scope and allow it to be reused as an alias, then I am +1. I'd be even more partial to allowing them in location scope, with alias names, and merging up the aliases. My concern is names clashing, on servers with massive VHOST lists. Allowing you to 'refine' a given alias... e.g. AuthConfig alt-ldap AuthLdapDirectives /AuthConfig VirtualHost xxx Location /private AuthConfig alt-ldap AuthLdap additional or overridden directives /AuthConfig ... then I think your preference for named sections, and my preference for scoped sections could both be satisfied. I'll give some thought to binding AuthConfig to a specific provider 'alias', v.s. allowing more complex control.
Re: Multiple AAA providers
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.) Let me clarify, we are talking about coding at the provider framework, not each provider itself. In other words, the authconfig module would do basically what you have proposed as far as merging config options outside of the actual provider module. The only difference would be allowing the authconfig configuration to be aliased so that it can be reused. I think we are close to the same page but I will wait to review the code that you come up with. Also the reason for the syntax authconfig ldap alt-ldap is so that the authconfig module knows what the base provider is. Otherwise how will it know which provider to call once the configuration merge is done? Then there would be no need for this syntax: VirtualHost xxx Location /private AuthConfig alt-ldap AuthLdap additional or overridden directives /AuthConfig It could be replaced with: VirtualHost xxx Location /private AuthProvider alt-ldap AuthLdap additional or overridden directives... Which more closely maps to the configuration syntax today. Brad William A. Rowe, Jr. [EMAIL PROTECTED] Monday, March 07, 2005 4:47:15 PM 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 providers to be oblivious (but still work.) [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. If they are saying the same thing then we might all be on the same page. Now would be a great time to have one of those white board discussions like we have at ApacheCon :). Agreed :) I would like to see us implement a syntax that can be reused as I suggested earlier. An AuthProviderAlias ... tag would allow for that. I am -1 to Bill's original proposal mainly because each use of an auth module requires that it be reconfigured within it's Location even if the configurations across Locations are identical. That's not accurate. It's allowed, but remember inheritance applies, In the module I already hacked, it's possible to VirtualHost xxx AuthConfig AuthDirectives /AuthConfig and that will also be inherited. But I didn't propose named aliases, which could be a very cool idea. If Bill's original proposal was reworked to pull the AuthConfig out of the Location scope and allow it to be reused as an alias, then I am +1. I'd be even more partial to allowing them in location scope, with alias names, and merging up the aliases. My concern is names clashing, on servers with massive VHOST lists. Allowing you to 'refine' a given alias... e.g. AuthConfig alt-ldap AuthLdapDirectives /AuthConfig VirtualHost xxx Location /private AuthConfig alt-ldap AuthLdap additional or overridden directives /AuthConfig ... then I think your preference for named sections, and my preference for scoped sections could both be satisfied. I'll give some thought to binding AuthConfig to a specific provider 'alias', v.s. allowing more complex control.
Re: Multiple AAA providers
--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.) Brad's suggestion satisfies those exact requirements while being at the provider layer - which is infinitely more efficient than the AuthConfig that has been proposed. Again, what is specifically unsatisfactory with the idea? -- justin
Re: Multiple AAA providers
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 places this can happen, so as a straw poll, would those interested in *coding* auth schemas please vote (end users, our choice will be transparent enough to you that we prefer the developers to indicate their preferences.) [ ] Implement in each provider (e.g. mod_authnz_ldap, mod_authn_file) Different AuthLdapConfig xxx AuthFileConfig zzz sections [ ] Implement in each scheme (e.g. basic, digest) Different AuthBasicConfig xxx AuthDigestConfig zzz sections [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. These choices overlook Brad's suggestion, which I still think is the best: [ ] Implement across providers Single AuthProviderAlias real-provider-name alias directive. This does not tie it into either the provider or the scheme and allows the config and overhead of the merging to be contained to the provider'd alias. We could probably find a better name than AuthProviderAlias though. My $.02. -- justin
Re: Multiple AAA providers
--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 *call* providers. Or is a provider File, DBM, LDAP? Yes. If you mean the former, I'm right there with you. However, that won't work on antique (2.0, even 1.3) auth modules, so my concept is still valid. It should simply be replaced for httpd-2.0 with something clearer :) Well, obviously, you're not with me here. =) -- justin
Re: Multiple AAA providers
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 ... to summarize; we (collectively) would like to see some mechanism for multiple configurations of the same 'provider' (defined above). There are logically three places this can happen, so as a straw poll, would those interested in *coding* auth schemas please vote (end users, our choice will be transparent enough to you that we prefer the developers to indicate their preferences.) [ ] Implement in each provider (e.g. mod_authnz_ldap, mod_authn_file) Different AuthLdapConfig xxx AuthFileConfig zzz sections [ ] Implement in each scheme (e.g. basic, digest) Different AuthBasicConfig xxx AuthDigestConfig zzz sections [ ] Implement globally across schemes and providers Single AuthConfig xxx directive, but as it's not in the scheme which iterates the providers, control isn't as fine-grained. Please comment. Bill
Re: Multiple AAA providers
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: Location /foo LDAPProvider ldap1 ...config options for mod_authnz_ldap... /LDAPProvider LDAPProvider ldap2 ...config options for mod_authnz_ldap... /LDAPProvider DBDProvider my_db ...config options for hypothetical mod_authn_dbd... /DBDProvider ...config options for mod_authnz_ldap... AuthUserFile conf/foo AuthBasicProvider ldap1 ldap2 ldap file my_db /Location This isolates the config directly to the module, and if we so desire, we could add helper functions which promote re-use of this strategy by other provider modules as needed. -- justin This means that: - Every auth module has to be independantly updated to use this method (which won't happen) - Every module will have it's own method of configuring multiple providers. Putting my end user hat on, doing it the way you suggest would irritate me no end, as it would make no logical sense to me why one auth provider allows multiple configurations and another doesn't, or why one auth provider uses one config mechanism and another auth provider uses a different one. I definitely think that getting the auth framework to understand this syntax is the right way to go, we just need to figure out that magic syntax that will work elegantly. Regards, Graham --
Re: Multiple AAA providers
Actually I think the better syntax would be: AuthProviderAlias ldap Myldap1 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias ldap Myldap2 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias file Myfile1 ...config options for mod_auth... /AuthProviderAlias Location /foo1 AuthProvider Myldap1 Myfile1 ...Other config options... /Location Location /foo2 AuthProvider Myldap2 Myfile1 ...Other config options... /Location Location /foo3 AuthProvider Myldap1 Myldap2 ...Other config options... /Location This would allow you to mix-match-reuse-redefine auth configurations anywhere you like. I haven't thought this through completely from an implementation standpoint, but by moving the provider definitions into mod_auth_basic and then extending the framework for handling multiple provider definitions into the providers themselves, I think we can come out with something very useful and reuseable. Brad [EMAIL PROTECTED] Friday, March 04, 2005 1:06:47 AM 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: Location /foo LDAPProvider ldap1 ...config options for mod_authnz_ldap... /LDAPProvider LDAPProvider ldap2 ...config options for mod_authnz_ldap... /LDAPProvider DBDProvider my_db ...config options for hypothetical mod_authn_dbd... /DBDProvider ...config options for mod_authnz_ldap... AuthUserFile conf/foo AuthBasicProvider ldap1 ldap2 ldap file my_db /Location This isolates the config directly to the module, and if we so desire, we could add helper functions which promote re-use of this strategy by other provider modules as needed. -- justin This means that: - Every auth module has to be independantly updated to use this method (which won't happen) - Every module will have it's own method of configuring multiple providers. Putting my end user hat on, doing it the way you suggest would irritate me no end, as it would make no logical sense to me why one auth provider allows multiple configurations and another doesn't, or why one auth provider uses one config mechanism and another auth provider uses a different one. I definitely think that getting the auth framework to understand this syntax is the right way to go, we just need to figure out that magic syntax that will work elegantly. Regards, Graham --
Re: Multiple AAA providers
--On Friday, March 4, 2005 8:56 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Actually I think the better syntax would be: AuthProviderAlias ldap Myldap1 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias ldap Myldap2 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias file Myfile1 ...config options for mod_auth... /AuthProviderAlias Location /foo1 AuthProvider Myldap1 Myfile1 ...Other config options... /Location Location /foo2 AuthProvider Myldap2 Myfile1 ...Other config options... /Location Location /foo3 AuthProvider Myldap1 Myldap2 ...Other config options... /Location This would allow you to mix-match-reuse-redefine auth configurations anywhere you like. I haven't thought this through completely from an implementation standpoint, but by moving the provider definitions into mod_auth_basic and then extending the framework for handling multiple provider definitions into the providers themselves, I think we can come out with something very useful and reuseable. Actually, I think we could move this into a (new) mod_authn_alias/config or something and make it generic - tieing it into mod_auth_basic would mean it couldn't be used by mod_auth_digest. The key here from the implementation perspective is that we would know what the 'real' provider name is as well - so we wouldn't have to tie it to the module. mod_authn_alias would register a 'fake' provider that merges the auth's per_dir_config before executing the 'real' provider. So, yah, I like this. -- justin
Re: Multiple AAA providers
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 this would interact with the auth providers is still unanswered. Correct. Needs Study. Remember that the auth providers don't implement the check_user_id hook - only the auth mechanisms (basic/digest) implement those hooks. So, this module acts counter to the entire notion of providers by just blindly re-running the entire hook process instead. (check_user_id now becomes recursive - yikes!) Actually, to depth == 1. We have a recursion block to prevent further recursion. One interesting side effect on this patch. If we don't find the auth we required in the specific per-dir config, we unset it before we return declined from the module. If a provider accepts, we leave that per-dir config set (that -is- where we were authorized!) The side effect is this, on the subsequent hooks, per-dir still points at this second provider, so now we leverage the identical config for gaining groups, fixups and other such tweakage. Remember, we -only- recursed IIF everyone on pass one declined. Our hook isn't invoked at all because it's RUN_FIRST, and if someone is willing to authenticate the user, we succeed. We'd now incur the overhead of the auth mechanism hooks when there is little need to do so. No overhead, anything but DECLINED drops us out of the hook. Plus, we lose the ability to sanely chain providers as was the original intent. Agreed - this - is what needs study. I still maintain the better way to do this is to handle it in the provider modules themselves by leveraging the provider API instead. NO and I will veto. IF you introduce code complexity into seven provider modules which could be made more complex in the core, in a single add-in module, or extending only the basic/digest provider, then you are rolling dice in one area I don't like to play poker. To reiterate, in my mind, the ideal syntax is: Location /foo LDAPProvider ldap1 ...config options for mod_authnz_ldap... /LDAPProvider LDAPProvider ldap2 ...config options for mod_authnz_ldap... /LDAPProvider DBDProvider my_db ...config options for hypothetical mod_authn_dbd... /DBDProvider ...config options for mod_authnz_ldap... AuthUserFile conf/foo AuthBasicProvider ldap1 ldap2 ldap file my_db /Location This isolates the config directly to the module, and if we so desire, we could add helper functions which promote re-use of this strategy by other provider modules as needed. -- justin Unnecessarily complicates all the providers. What about AuthConfig LDAP ldap1 ... AuthConfig LDAP ldap2 ... AuthBasicProvider ldap1 ldap2 file my_db where we teach auth_basic and only auth_basic about AuthConfig sections, and keep the cruft out of each and every provider instance? Bill
Re: Multiple AAA providers
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: AuthProviderAlias ldap Myldap1 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias ldap Myldap2 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias file Myfile1 ...config options for mod_auth... /AuthProviderAlias Seems AuthAlias file Foo would be simpler to grok and less simple to mistype. This would allow you to mix-match-reuse-redefine auth configurations anywhere you like. I agree provided Location /foo AuthAlias ldap ldap1 Location /foo/secure AuthAlias ldap ldap1 does the right thing for /foo/secure/... and it's trivial enough to make sure that happens. Actually, I think we could move this into a (new) mod_authn_alias/config or something and make it generic Hmmm Hmmm... yup, that's what I did... - tieing it into mod_auth_basic would mean it couldn't be used by mod_auth_digest. but you lose the control offered by AuthBasicProvider ... that was a good suggestion. mod_authn_alias would register a 'fake' provider that merges the auth's per_dir_config before executing the 'real' provider. yup, that's what mod_auth_config did. However, mod_auth_config; 1. invokes auth for the local directives (not Auth sectioned) 2. invokes auth for all Auth sections. providing the explicit list in AuthBasicProvider would ensure we walk the provider configs correctly.
Re: Multiple AAA providers
--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 Auth sectioned) 2. invokes auth for all Auth sections. providing the explicit list in AuthBasicProvider would ensure we walk the provider configs correctly. No, the module that was posted had no concept of providers. The right place to do this is at the provider level not the hook level. -- justin
Re: Multiple AAA providers
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 Auth sectioned) 2. invokes auth for all Auth sections. providing the explicit list in AuthBasicProvider would ensure we walk the provider configs correctly. No, the module that was posted had no concept of providers. The right place to do this is at the provider level not the hook level. -- justin We have a naming problem. Provider is meaningless. Is a provider Basic, Digest? Or is a provider File, DBM, LDAP? If you mean the former, I'm right there with you. However, that won't work on antique (2.0, even 1.3) auth modules, so my concept is still valid. It should simply be replaced for httpd-2.0 with something clearer :) Bill
Re: Multiple AAA providers
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; AuthConfig AuthFile users1 /AuthConfig This would give us the best of both worlds. It's no different from the use of Location, Directory, and File per-dir blocks. How does that work? The issue here is that we want to use the same module multiple times in the same location/directory/file. So, there'd only be one per-dir-config instance. -- justin I found an hour to hack it, but it will take two more to wrap it. Proof of concept tomorrow. Actually, not proof, the solution ;-) Bill Just for 2.2, I presume? [I ask as we have a good number of customers who want this *now*.] -- Jess Holle
Re: Multiple AAA providers
At 11:13 PM 3/2/2005, William A. Rowe, Jr. wrote:
xNo - simply create a per-dir config, and use dirconfig to represent;
AuthConfig
AuthFile users1
/AuthConfig
How does that work? The issue here is that we want to use the same module
multiple times in the same location/directory/file. So, there'd only be one
per-dir-config instance. -- justin
I found an hour to hack it, but it will take two more to wrap it.
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.
Bill /* Copyright 2002-2005 The Apache Software Foundation or its licensors, as
* applicable.
*
* Licensed 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 apr_strings.h
#define CORE_PRIVATE
#include http_config.h
module AP_MODULE_DECLARE_DATA auth_config_module;
typedef struct auth_dir_conf {
apr_array_header_t *sec_auth;
} auth_dir_conf;
static void *create_auth_dir_config(apr_pool_t *p, char *dummy)
{
auth_dir_conf *conf =
(auth_dir_conf *) apr_palloc(p, sizeof(auth_dir_conf));
/* Created in authsection, when invoked */
conf-sec_auth = NULL;
return (void *) conf;
}
static void *merge_auth_dir_config(apr_pool_t *p, void *basev, void *addv)
{
auth_dir_conf *conf = (auth_dir_conf *) apr_palloc(p,
sizeof(auth_dir_conf));
auth_dir_conf *base = (auth_dir_conf *) basev;
auth_dir_conf *add = (auth_dir_conf *) addv;
if (add-sec_auth) {
conf-sec_auth = add-sec_auth;
}
else {
conf-sec_auth = base-sec_auth;
}
/* The logic;
* conf-auth_dir_conf = apr_array_append(p, base-sec_auth, add-sec_auth);
* would be useful, if we had a way to distinguish when AuthConfig should
* override AuthConfig from a lower scope.
*/
return conf;
}
static const char *authsection(cmd_parms *cmd, void *confv, const char *arg)
{
int old_overrides = cmd-override;
auth_dir_conf *conf = (auth_dir_conf *)confv;
ap_conf_vector_t *new_auth_config = ap_create_per_dir_config(cmd-pool);
const char *endp = ap_strrchr_c(arg, '');
const char *errmsg = ap_check_cmd_context(cmd, NOT_IN_LIMIT);
if (errmsg != NULL)
return errmsg;
if (endp == NULL)
return apr_pstrcat(cmd-pool, cmd-cmd-name,
directive missing closing '', NULL);
if (arg)
return apr_pstrcat(cmd-pool, AuthConfig takes no options, , arg,
is invalid, NULL);
/* Create the sec_auth array on demand */
if (!conf-sec_auth)
conf-sec_auth = apr_array_make(cmd-pool, 2, sizeof(ap_conf_vector_t
*));
cmd-override = ACCESS_CONF;
errmsg = ap_walk_config(cmd-directive-first_child, cmd, new_auth_config);
*((void **)apr_array_push(conf-sec_auth)) = new_auth_config;
cmd-override = old_overrides;
/* Hopefully NULL */
return errmsg;
}
static int auth_check_user_id(request_rec *r)
{
int access_status;
void *recurse;
auth_dir_conf *conf = ap_get_module_config(r-per_dir_config,
auth_config_module);
ap_conf_vector_t *orig_dir_config = r-per_dir_config;
ap_conf_vector_t **auth_elt;
int auth_nelt;
if (!conf-sec_auth)
return DECLINED;
if ((apr_pool_userdata_get((void**)recurse, mod_auth_config::recurse,
r-pool) != APR_SUCCESS) recurse)
return DONE;
auth_elt = (ap_conf_vector_t **)conf-sec_auth-elts;
auth_nelt = conf-sec_auth-nelts;
apr_pool_userdata_setn((void*) -1, mod_auth_config::recurse,
apr_pool_cleanup_null, r-pool);
while (auth_nelt *auth_elt) {
r-per_dir_config = ap_merge_per_dir_configs(r-pool, orig_dir_config,
*auth_elt);
access_status = ap_run_check_user_id(r);
/* We contine on DONE, only auth_config returns it */
if ((access_status != DONE) (access_status != DECLINED)) {
apr_pool_userdata_setn(NULL, mod_auth_config::recurse,
apr_pool_cleanup_null, r-pool);
return access_status;
}
--auth_nelt;
++auth_elt;
}
apr_pool_userdata_setn(NULL, mod_auth_config::recurse,
apr_pool_cleanup_null, r-pool);
r-per_dir_config = orig_dir_config;
return
Re: Multiple AAA providers
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 unanswered. Remember that the auth providers don't implement the check_user_id hook - only the auth mechanisms (basic/digest) implement those hooks. So, this module acts counter to the entire notion of providers by just blindly re-running the entire hook process instead. (check_user_id now becomes recursive - yikes!) We'd now incur the overhead of the auth mechanism hooks when there is little need to do so. Plus, we lose the ability to sanely chain providers as was the original intent. 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: Location /foo LDAPProvider ldap1 ...config options for mod_authnz_ldap... /LDAPProvider LDAPProvider ldap2 ...config options for mod_authnz_ldap... /LDAPProvider DBDProvider my_db ...config options for hypothetical mod_authn_dbd... /DBDProvider ...config options for mod_authnz_ldap... AuthUserFile conf/foo AuthBasicProvider ldap1 ldap2 ldap file my_db /Location This isolates the config directly to the module, and if we so desire, we could add helper functions which promote re-use of this strategy by other provider modules as needed. -- justin
Re: Multiple AAA providers
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 difficult this would be to do in the current AAA structure?
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
passing on doing the checking. code that into the provider loop and you're
done.
I can find the time to do this probably this week if justin or the other
provider authors think it's a good idea.
--Geoff
Re: Multiple AAA providers
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
passing on doing the checking. code that into the provider loop and
you're
done.
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
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
Auth ldap-provider-B
# LDAP stuff for LDAP server B
/Auth
AuthBasicProvider ldap-provider-A ldap-provider-B
Regards,
Graham
--
Re: Multiple AAA providers
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 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 Auth ldap-provider-B # LDAP stuff for LDAP server B /Auth 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 themselves. --Geoff
Re: Multiple AAA providers
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
passing on doing the checking. code that into the provider loop and
you're
done.
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
There are two options to this:
- Teach each provider how to handle multiple instances of itself (sounds
like too much duplication)
I looked at this *briefly* with mod_auth_ldap -- and decided I had other
ways to frustrate myself in the short term.
- Introduce a concept like this:
Auth ldap-provider-A
# LDAP stuff for LDAP server A
/Auth
Auth ldap-provider-B
# LDAP stuff for LDAP server B
/Auth
AuthBasicProvider ldap-provider-A ldap-provider-B
*That* would be great!
--
Jess Holle
Re: Multiple AAA providers
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 hmm... 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 Auth ldap-provider-B # LDAP stuff for LDAP server B /Auth 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 themselves. --Geoff
Re: Multiple AAA providers
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 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. 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 themselves. The problem is that LDAP auth is set up using many directives (system user to bind to the directory as, password, the search details to find the user record, possible SSL directives per LDAP server). While the file case fits neatly into the AuthFileName directive, this doesn't fit into any other auth provider where there are multiple arguments. To fill out the example of the Auth container to better illustrate what I mean, you might have this: Auth ldap-acc-activedirectory 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,dc=co,dc=za?uid?sub AuthLDAPRemoteUserIsDN on /Auth Auth ldap-eng-activedirectory require ldap-group cn=Engineering,ou=Groups,ou=YYY AuthLDAPBindDN cn=Mail,dc=YYY AuthLDAPBindPassword blah2 LDAPTrustedMode SSL AuthLDAPURL ldaps://yyy.co.za/dc=yyy,dc=co,dc=za?uid?sub AuthLDAPRemoteUserIsDN on /Auth AuthBasicProvider ldap-acc-activedirectory ldap-eng-activedirectory Regards, Graham --
Re: Multiple AAA providers
To fill out the example of the Auth container to better illustrate what I mean, you might have this: Auth ldap-acc-activedirectory 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,dc=co,dc=za?uid?sub AuthLDAPRemoteUserIsDN on /Auth Auth ldap-eng-activedirectory require ldap-group cn=Engineering,ou=Groups,ou=YYY AuthLDAPBindDN cn=Mail,dc=YYY AuthLDAPBindPassword blah2 LDAPTrustedMode SSL AuthLDAPURL ldaps://yyy.co.za/dc=yyy,dc=co,dc=za?uid?sub AuthLDAPRemoteUserIsDN on /Auth AuthBasicProvider ldap-acc-activedirectory ldap-eng-activedirectory yeah, ok, I can see what you mean :) but a configuration like that doesn't strike me as something easily done with the current set of tools. but I'm sure that someone more familiar has a different opinion. alright, so we have two issues then - see if we can't provide some kind of configuration grouping like this - allow providers to fall through to eachother via a declined mechanism am I capturing it? --Geoff
Re: Multiple AAA providers
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, which would mean that the current provider is
passing on doing the checking. code that into the provider loop and you're
done.
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
Re: Multiple AAA providers
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
Re: Multiple AAA providers
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 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. I believe adding a 'generic' auth containter would introduce far more complexity in the core for a benefit that only mod_authnz_ldap would actually use. -- justin
Re: Multiple AAA providers
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 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. Correct. That is the approach that makes the most sense to me. The provider itself can loop as long as it wants to using its own config syntax. However, there is nothing that prohibits one authn module from registering multiple providers dynamically. Remember that the providers are only looked up at request-time. So, if mod_auth_ldap were to have a syntax like: AuthLDAPProvider foo-1 ldap://ldap.example.com/cn=? AuthLDAPProvider foo-2 ldap://ldap2.example.com/cn=? AuthBasicProvider foo-1 foo-2 That would work, as long as mod_auth_ldap calls ap_register_provider x number of times. -- justin
Re: Multiple AAA providers
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. To fill out the example of the Auth container to better illustrate what I mean, you might have this: You could do this today with a RAW_ARGS for LDAPAuth. For each LDAPAuth block, mod_authnz_ldap can register a new authn provider. Once mod_authnz_ldap could do this for itself, we could review the implementation to see if it would make sense generically. Right now, I'm very skeptical that it makes sense in a larger scale. Additionally, I'm not willing to see us lose backwards compatibility either in our auth config syntax. So, the current non-container approach would have to stay regardless. -- justin
Re: Multiple AAA providers
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
Re: Multiple AAA providers
Bleh. Wouldn't it be easier not to rearchitect the whole thing? 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. I think we can accomplish this with minimal or no changes to any existing auth module. 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. Bill At 09:45 AM 3/2/2005, Justin Erenkrantz wrote: 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 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. Correct. That is the approach that makes the most sense to me. The provider itself can loop as long as it wants to using its own config syntax. However, there is nothing that prohibits one authn module from registering multiple providers dynamically. Remember that the providers are only looked up at request-time. So, if mod_auth_ldap were to have a syntax like: AuthLDAPProvider foo-1 ldap://ldap.example.com/cn=? AuthLDAPProvider foo-2 ldap://ldap2.example.com/cn=? AuthBasicProvider foo-1 foo-2 That would work, as long as mod_auth_ldap calls ap_register_provider x number of times. -- justin
Re: Multiple AAA providers
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 multiple configurations per-dir. Other auth modules may have the same structure. Brad [EMAIL PROTECTED] Wednesday, March 02, 2005 11:14:33 AM Bleh. Wouldn't it be easier not to rearchitect the whole thing? 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. I think we can accomplish this with minimal or no changes to any existing auth module. 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. Bill At 09:45 AM 3/2/2005, Justin Erenkrantz wrote: 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 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. Correct. That is the approach that makes the most sense to me. The provider itself can loop as long as it wants to using its own config syntax. However, there is nothing that prohibits one authn module from registering multiple providers dynamically. Remember that the providers are only looked up at request-time. So, if mod_auth_ldap were to have a syntax like: AuthLDAPProvider foo-1 ldap://ldap.example.com/cn=? AuthLDAPProvider foo-2 ldap://ldap2.example.com/cn=? AuthBasicProvider foo-1 foo-2 That would work, as long as mod_auth_ldap calls ap_register_provider x number of times. -- justin
Re: Multiple AAA providers
--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 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
Re: Multiple AAA providers
--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 structure. At the very least, authnz_ldap would have to be taught how to store multiple configurations per-dir. Other auth modules may have the same structure. It'd be trivial to store this as part of the authn_structure as a 'context' field. Each provider could then store its config info in that field instead. To reiterate, I think the ideal here is to come up with a config syntax that allows config-time registration of providers with associated configuration information. -- justin
Re: Multiple AAA providers
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_ldap would have to be taught how to store multiple configurations per-dir. Other auth modules may have the same structure. No - simply create a per-dir config, and use dirconfig to represent; AuthConfig AuthFile users1 /AuthConfig This would give us the best of both worlds. It's no different from the use of Location, Directory, and File per-dir blocks. Bill
Re: Multiple AAA providers
--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; AuthConfig AuthFile users1 /AuthConfig This would give us the best of both worlds. It's no different from the use of Location, Directory, and File per-dir blocks. How does that work? The issue here is that we want to use the same module multiple times in the same location/directory/file. So, there'd only be one per-dir-config instance. -- justin
Re: Multiple AAA providers
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; AuthConfig AuthFile users1 /AuthConfig This would give us the best of both worlds. It's no different from the use of Location, Directory, and File per-dir blocks. How does that work? The issue here is that we want to use the same module multiple times in the same location/directory/file. So, there'd only be one per-dir-config instance. -- justin I found an hour to hack it, but it will take two more to wrap it. Proof of concept tomorrow. Actually, not proof, the solution ;-) Bill
