Tom, Josh, etc.:
But if you're looking for a big application that uses Kerberos,
there's that pesky thing called Windows. Every single Windows machine in
an active directory domain environment is a Kerberos client, and uses
Kerberos for authentication to all network services.
Kerberos with
Josh Berkus josh@agliodbs.com writes:
Yes ... if we were looking to cut down on both code and dependency bugs, we
might consider desupporting raw Kerberos. At this point, I think that
everyone who supports Kerberos supports GSSAPI, unless we're still committed
to supporting users of Red
Tom,
I have no corporate commitment to make PG 8.3+ work on ancient Red Hat
versions, if that's what you mean.
Well, in that case my suggestion is that we plan to transition to GSSAPI and
drop support for raw Kerberos as soon as Henry is ready with a patch (plus
I'm going to try to get the
To be honest, I have often wondered *why* we support kerberos
outside of the uber l33t geek factor. I have not once in a
commercial deployment had a business requirement for the
beast. LDAP? Now that is a whole other issue :)
Single sign-on in a Windows/AD environment (I'm talking
To be honest, I have often wondered *why* we support
kerberos outside
of the uber l33t geek factor. I have not once in a commercial
deployment had a business requirement for the beast. LDAP?
Now that
is a whole other issue :)
Single sign-on in a Windows/AD environment (I'm
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth
method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.
On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth
method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if
Sorry about the premature send.
On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth
method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that
On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote:
Well, unless you have an unusually good PKI infrastructure, SSL
doesn't provide any cryptographic connection between the client
identity and the data received by the server. (At least that's true
for the way it's used by Web
On Nov 2, 2006, at 11:04 AM, Martijn van Oosterhout wrote:
On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote:
In my case I have good control over the Kerberos infrastructure, but
none over the Federal PKI infrastructure. I also want the data
channel encryption tied to the client
* Martijn van Oosterhout (kleptog@svana.org) wrote:
In postgresql the client and server can specify what certificates
thay'll accept, there are no default trusted CAs. You can require the
client to have a certain certificate, for example. The client can also
verify the server has the expected
In postgresql the client and server can specify what certificates
thay'll accept, there are no default trusted CAs. You can
require the
client to have a certain certificate, for example. The
client can also
verify the server has the expected certificate. How much
it's used I
On Thu, 2 Nov 2006, Magnus Hagander wrote:
I expect we'll need a mapping of some sort, or perhaps a
sasl_regexp or similar to what is done in OpenLDAP. I don't
recall PG supporting using the DN from a client cert in an
SSL connection as a PG username but perhaps I missed it somewhere...
* Richard Troy ([EMAIL PROTECTED]) wrote:
Would signed certificates be preferred? Well, sure, they're nice. I don't
object, and in fact welcome some improvements here. For example, I'd love
the choice of taking an individual user's certificate and authenticating
completely based upon that.
Username/password is not acceptable in a number of situations. This is
not intended to replace them. This would be in *addition* to supporting
the current auth methods. I don't understand at all how you feel it'd
be nice to have yet shouldn't be done.
Thanks,
* Richard Troy ([EMAIL PROTECTED]) wrote:
...I thought you said this _needs_ to be done - by using words like
unacceptible and required - and I disagree. There's a difference
between what needs to be done and what is desired to be done. Further, I
never said shouldn't.
For PG to be an option
On Nov 2, 2006, at 12:26 PM, Richard Troy wrote:
Well, there's simply no need. While I can agree that more could be
done,
I'm not convinced there's a need because what we have now works
fine. Let
me support my view by stating first that I perceive that combining the
conception of
Would signed certificates be preferred? Well, sure, they're
nice. I don't object, and in fact welcome some improvements
here. For example, I'd love the choice of taking an
individual user's certificate and authenticating completely
based upon that. However, while this _seems_ to simplify
On Thu, Nov 02, 2006 at 01:10:14PM -0800, Henry B. Hotz wrote:
standard protocols and libraries that support real security: SASL
and GSSAPI in particular. You may for various reasons decide that
[. . .]
Part of establishing a secure connection is establishing that the end
points are
On Thu, Nov 02, 2006 at 08:58:37PM +0100, Magnus Hagander wrote:
I don't think you can tie the SSL certificate to a specific
user though... I certainly can't recall any way to do that
today in PG.
You can't. It's been talked about, but never done.
Oops, sorry. You can verify the user
On Thu, Nov 02, 2006 at 10:48:29PM +0100, Magnus Hagander wrote:
The same could apply to SSL cert based authentication, for users
connecting from machines outside of my realm. Once you have unlocked
the certificate, you can authenticate any number of times to any number
of services that will
All,
For what it's worth, I heartily support this effort. For most cases,
it probably isn't necessary, but I can think of several applications
for SASL/GSSAPI where something weaker will simply not do; in the
absence of the proposed functionality, I simply wouldn't be able to
use Postgres
Josh Berkus josh@agliodbs.com writes:
... Why would we reject a piece of useful functionality based on a
published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have rejected the original
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
... Why would we reject a piece of useful functionality based on a
published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have
* Tom Lane ([EMAIL PROTECTED]) wrote:
Josh Berkus josh@agliodbs.com writes:
... Why would we reject a piece of useful functionality based on a
published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related
On Thu, Nov 02, 2006 at 07:49:01PM -0800, Joshua D. Drake wrote:
To be honest, I have often wondered *why* we support kerberos outside of
the uber l33t geek factor. I have not once in a commercial deployment
had a business requirement for the beast. LDAP? Now that is a whole
other issue :)
The same could apply to SSL cert based authentication, for users
connecting from machines outside of my realm. Once you have
unlocked
the certificate, you can authenticate any number of times to any
number of services that will accept this certificate
*without* having
to re-enter
... Why would we reject a piece of useful functionality based on a
published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have rejected the original Kerberos-support patch if
To be honest, I have often wondered *why* we support
kerberos outside
of the uber l33t geek factor. I have not once in a commercial
deployment had a business requirement for the beast. LDAP?
Now that is
a whole other issue :)
Isn't NFSv4 a big application that uses Kerberos? I
On Fri, Nov 03, 2006 at 08:05:05AM +0100, Magnus Hagander wrote:
The same could apply to SSL cert based authentication, for users
connecting from machines outside of my realm. Once you have
unlocked
the certificate, you can authenticate any number of times to any
number of
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.
round
On Oct 31, 2006, at 8:34 PM, Tom Lane wrote:
Henry B. Hotz [EMAIL PROTECTED] writes:
I notice that all the
authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
which sounds like something that isn't expected to block on network
access.
That's right.
Is this behavior important
On Nov 1, 2006, at 6:33 AM, Stephen Frost wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
I've been looking at adding SASL or GSSAPI as an auth method. I have
some questions about how to handle the flow of control changes.
Great! I'd love to see that implemented, personally, so if
I've been looking at adding SASL or GSSAPI as an auth method. I have
some questions about how to handle the flow of control changes.
When you do one of the above, an authentication is not (necessarily)
a simple one-packet exchange. In fact the exchange may involve
trying several
Henry B. Hotz [EMAIL PROTECTED] writes:
I notice that all the
authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
which sounds like something that isn't expected to block on network
access.
That's right.
Is this behavior important during startup?
You needn't bother to
35 matches
Mail list logo
