You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2005/03/02 13:26:29 UTC
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, March 2, 2005 12:14 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> 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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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
Posted by Jess Holle <je...@ptc.com>.
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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
Posted by Jess Holle <je...@ptc.com>.
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
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Posted by Graham Leggett <mi...@sharp.fm>.
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
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Posted by Jess Holle <je...@ptc.com>.
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
Posted by Graham Leggett <mi...@sharp.fm>.
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
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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