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
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
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
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
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
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
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
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
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'
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
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
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
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
--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.)
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
--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*
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
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...
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
--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...
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
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
--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
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
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;
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.
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
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
LDAP for
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
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
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
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
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
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
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
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
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: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
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
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
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
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
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
--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
--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
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
--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,
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
48 matches
Mail list logo
