Re: LDAP auth

"Magnus Hagander" <mha@sollentuna.net> writes:

Was there ever a decision in "the libcurl thread"?

No, not yet.

Personally I'm unconvinced that we should depend on libcurl: if it's
going to use openldap to do LDAP work, then the only good reason to use
libcurl rather than openldap directly is if there's some clear use-case
for libcurl's other features. Which no one had presented AFAIR. I'm
still willing to be convinced though.

regards, tom lane

Magnus Hagander wrote:

Awhile back, "Magnus Hagander" <mha@sollentuna.net> wrote:

This patch adds native LDAP auth, for those platforms that

don't have

PAM (such as Win32, but also unixen without PAM). On Unix, uses
OpenLDAP. On win32, uses the builin WinLDAP library.

Is this patch still live, or do you want to withdraw it in
light of the recent discussions about using libcurl?

I'm unsure wether libcurl does what we'd need, but I haven't looked into
the details (I did a very quick check on the web, but was unable to
quickly find what I was looking for).

Specifically, we want to just do an LDAP bind and not actually fetch
anything. Though I guess we could fetch the base DN without taking a lot
of performance...

Also, I'm unsure if they'll run with winldap on windows or add an extra
library dependence on openldap (which will cause problems when using
ldaps in windows, since you need a completely separate set of
certificates and stuff imported into openldap instead of using what
Windows alreayd set up for you). Their FAQ says they require openldap,
but a quick google shows maybe they don't.

Was there ever a decision in "the libcurl thread"? If we're going to
pull in libcurl as a dependency anyway, it would deifnitly be worthwhile
checking if we can use it here as well, if nothing else then just to get
rid of the configure steps. But if we don't use it elsewhere, I don't
see any reason to add an extra dependency.

I suggested libcurl in another context, and not so much as a means of
getting at LDAP data as a means of getting config data from non-LDAP as
well as LDAP sources. If all we want is LDAP then using libcurl would
indeed be introducing an unnecessary dependency.

In this context, though, its use seems a bit odd.

cheers

andrew

Andrew Dunstan wrote:

I suggested libcurl in another context, and not so much as a means of
getting at LDAP data as a means of getting config data from non-LDAP as
well as LDAP sources. If all we want is LDAP then using libcurl would
indeed be introducing an unnecessary dependency.

In this context, though, its use seems a bit odd.

Right, that's what I remember, the curl can _also_ be used to distribute
authentication data, but of course LDAP is more standard.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

Was there ever a decision in "the libcurl thread"?

No, not yet.

Personally I'm unconvinced that we should depend on libcurl: if it's
going to use openldap to do LDAP work, then the only good
reason to use libcurl rather than openldap directly is if there's some

clear use-case for libcurl's other features. Which no one had

presented AFAIR. I'm

still willing to be convinced though.

I'm almost done with implementing a patch that recognizes LDAP URLs in
pg_services.conf and queries an LDAP server for a connection option
string.

Currently I'm coding against libldap, and I intend to submit the patch
that way. If there are loud calls for another library, I think I could
adapt the code without much hassle.

The only other protocol I can think of that might make sense is
HTTP, but I personally have never heard of a web server employed
that way.

Yours,
Laurenz Albe

Was there ever a decision in "the libcurl thread"?

No, not yet.

Personally I'm unconvinced that we should depend on

libcurl: if it's

going to use openldap to do LDAP work, then the only good reason to
use libcurl rather than openldap directly is if there's some

clear use-case for libcurl's other features. Which no one had

presented AFAIR. I'm

still willing to be convinced though.

I'm almost done with implementing a patch that recognizes
LDAP URLs in pg_services.conf and queries an LDAP server for
a connection option string.

Currently I'm coding against libldap, and I intend to submit
the patch that way. If there are loud calls for another
library, I think I could adapt the code without much hassle.

The only other protocol I can think of that might make sense
is HTTP, but I personally have never heard of a web server
employed that way.

If you haven't already, look at the ldap auth patch in the queue for
some win32 specific issues - we do not want to rely on OpenLDAP on
windows, since there is a builtin version that's almost the same (close
enough).

(BTW, web servers are employed for *anything* these days...)

//Magnus

Andrew Dunstan wrote:

I suggested libcurl in another context, and not so much as

a means of

getting at LDAP data as a means of getting config data from

non-LDAP

as well as LDAP sources. If all we want is LDAP then using libcurl
would indeed be introducing an unnecessary dependency.

In this context, though, its use seems a bit odd.

Right, that's what I remember, the curl can _also_ be used to
distribute authentication data, but of course LDAP is more standard.

Um. LDAP is a protocol, curl is a libary. I assume you mean OpenLDAP,
though. And yes, OpenLDAP is way more common than libcurl for getting
LDAP data. And since libcurl depends on openldap, there's really no
point in donig it unless you're going to use the *other* features of
libcurl as well.

//Magnus

I'm almost done with implementing a patch that recognizes
LDAP URLs in pg_services.conf and queries an LDAP server for
a connection option string.

Currently I'm coding against libldap [...]

If you haven't already, look at the ldap auth patch in the queue for
some win32 specific issues - we do not want to rely on OpenLDAP on
windows, since there is a builtin version that's almost the
same (close enough).

Thank you for drawing my attention to that, I wasn't aware of it.
I'll definitely try to use the native winldap interface and try to
make my patch as compatible to yours as possible (configure
--with-ldap).

If your patch is accepted and a dependency on OpenLDAP is introduced,
my patch will provide an additional gain with no additional cost.

Yours,
Laurenz Albe

"Albe Laurenz" <all@adv.magwien.gv.at> writes:

If your patch is accepted and a dependency on OpenLDAP is introduced,
my patch will provide an additional gain with no additional cost.

Out of curiosity what would an SQL database want with ldap anyways?
Is it just a set of bindings for ldap functions for applications?

--
greg

If your patch is accepted and a dependency on OpenLDAP is introduced,
my patch will provide an additional gain with no additional cost.

Out of curiosity what would an SQL database want with ldap anyways?
Is it just a set of bindings for ldap functions for applications?

No, what I have in mind is a way to lookup database connection options
(dbname, port, etc.) on an LDAP server, so that the connection
information
can be stored in one central place and does not have to be distributed
to the clients.

BTW, I checked the Windows API for LDAP, and it is quite different
from OpenLDAP. So I'm afraid that I'll have to use OpenLDAP on Windows
too :^(

Yours,
Laurenz Albe

If your patch is accepted and a dependency on OpenLDAP is

introduced,

my patch will provide an additional gain with no additional cost.

Out of curiosity what would an SQL database want with ldap anyways?
Is it just a set of bindings for ldap functions for applications?

No, what I have in mind is a way to lookup database
connection options (dbname, port, etc.) on an LDAP server, so
that the connection information can be stored in one central
place and does not have to be distributed to the clients.

BTW, I checked the Windows API for LDAP, and it is quite
different from OpenLDAP. So I'm afraid that I'll have to use
OpenLDAP on Windows too :^(

Please look at that once more. There are serious integration issues
using OpenLDAP on windows - at least if you want to put SSL into the
mix. And it's not really that different. You might also want to take a
look at the code from dblink-ldap, which runs fine on both Windows and
linux, without a huge amount of #ifdefs.
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/dblink-ldap/dblink-ldap/dbl
ink-ldap.c?rev=1.3&content-type=text/x-cvsweb-markup)

//Magnus

Greg Stark wrote:

"Albe Laurenz" <all@adv.magwien.gv.at> writes:

If your patch is accepted and a dependency on OpenLDAP is introduced,
my patch will provide an additional gain with no additional cost.

Out of curiosity what would an SQL database want with ldap anyways?

Single Sign On is the obvious answer.

I find it hard to imagine LDAP being sensibly use for any other postgres
purpose than authentication, despite recent flights of fancy on the list
about storing large slabs of config data there.

cheersw

andrew

If your patch is accepted and a dependency on OpenLDAP is

introduced,

my patch will provide an additional gain with no additional cost.

Out of curiosity what would an SQL database want with ldap anyways?

Single Sign On is the obvious answer.

LDAP doesn't actually provide Single Sign On. It does provide Single
Login with Single Password. But you still have to type in your password
again for each login.

Kerberos provides single sign-on, where you just log in once and you're
done - no more password entry.

I find it hard to imagine LDAP being sensibly use for any
other postgres purpose than authentication, despite recent
flights of fancy on the list about storing large slabs of
config data there.

Well, that does seem to be the flavour of the month though.. ;-)

//Magnus

On Mon, Mar 06, 2006 at 15:00:07 -0500,
Andrew Dunstan <andrew@dunslane.net> wrote:

I find it hard to imagine LDAP being sensibly use for any other postgres
purpose than authentication, despite recent flights of fancy on the list
about storing large slabs of config data there.

It can also make sense to get authorization information from LDAP.

Bruno Wolff III wrote:

On Mon, Mar 06, 2006 at 15:00:07 -0500,
Andrew Dunstan <andrew@dunslane.net> wrote:

I find it hard to imagine LDAP being sensibly use for any other postgres
purpose than authentication, despite recent flights of fancy on the list
about storing large slabs of config data there.

It can also make sense to get authorization information from LDAP.

Yes, that's true. But I can imagine putting a shared config setup on a
web server, or an ftp server, or a tftp server, a good deal more easily
than putting it in LDAP.

cheers

andrew

I find it hard to imagine LDAP being sensibly use for any other

postgres

purpose than authentication, despite recent flights of fancy on the

list

about storing large slabs of config data there.

It can also make sense to get authorization information from LDAP.

Yes, that's true. But I can imagine putting a shared config setup on a

web server, or an ftp server, or a tftp server, a good deal more

easily

than putting it in LDAP.

I don't want to discuss matters of taste, and this is clearly such a
matter.

I tend to agree that it is a little exaggerated to set up an LDAP server
just to store a few bits of connection information.

But nowadays LDAP servers are used for various things, like directories
of employees, and if you already have an LDAP server in the house, it is
the
perfect tool for the task.

Yours,
Laurenz Albe