SEO

It appears that the JDBC client doesn't include the Kerberos support
that the C clients do.

So, two questions:

1) Is there an alternative JDBC client that's just a glue layer
instead of a complete re-implementation?

2) If I were willing to add a GSSAPI or SASL layer as an alternative
to the bare Krb 5 support would anyone be willing to help with the
supporting mods to the pg_hba.conf parsing, and configure?
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Thu, 28 Sep 2006, Henry B. Hotz wrote:

> It appears that the JDBC client doesn't include the Kerberos support
> that the C clients do.

Java doesn't have accessible Kerberos support. It wraps Kerberos in
GSSAPI which requires the server to support GSSAPI instead of plain
Kerberos.

> So, two questions:
>
> 1) Is there an alternative JDBC client that's just a glue layer instead of a
> complete re-implementation?

No, there aren't any Type 2 drivers around. Requiring native code is a
giant pain.

Kris Jurka



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Sep 28, 2006, at 10:52 AM, Kris Jurka wrote:

>
>
> On Thu, 28 Sep 2006, Henry B. Hotz wrote:
>
>> It appears that the JDBC client doesn't include the Kerberos
>> support that the C clients do.
>
> Java doesn't have accessible Kerberos support. It wraps Kerberos
> in GSSAPI which requires the server to support GSSAPI instead of
> plain Kerberos.

Looks like Kerberos is the only GSSAPI mechanism supported in Java.
OK by me, but that's not the point of the standard (or the SASL
standard).

>> So, two questions:
>>
>> 1) Is there an alternative JDBC client that's just a glue layer
>> instead of a complete re-implementation?
>
> No, there aren't any Type 2 drivers around. Requiring native code
> is a giant pain.
>
> Kris Jurka

Requiring JAVA support for everything you can do with C is also a
pain, isn't it? (This incompatibility being an example.)

I take it you're not volunteering to help with my second request. ;-)

------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Thu, 28 Sep 2006, Henry B. Hotz wrote:

> I take it you're not volunteering to help with my second request. ;-)
>

I would if we could get some -hackers buy in on the idea. Adding more and
more auth methods is something they're not excited about unless there's a
good reason (which I think this is).

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> 2) If I were willing to add a GSSAPI or SASL layer as an
> alternative to the bare Krb 5 support would anyone be willing
> to help with the supporting mods to the pg_hba.conf parsing,
> and configure?

Sure, I can help out with that. I've done a bunch of work on the current
kerberos stuff (tohugh I'm by no means the author) in order to make it
work on win32, so I have a little bit of a clue around that code ATM.

As for the other part - will core accept this - I can't answer that. I
do beleive that there is a point to it, given that Java will then
support it natively, but I'm not core. I'm unsure if there is a clear
view on the merits of adding more authentication options..


//Magnus

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Sep 28, 2006, at 12:42 PM, Magnus Hagander wrote:

>> 2) If I were willing to add a GSSAPI or SASL layer as an
>> alternative to the bare Krb 5 support would anyone be willing
>> to help with the supporting mods to the pg_hba.conf parsing,
>> and configure?
>
> Sure, I can help out with that. I've done a bunch of work on the
> current
> kerberos stuff (tohugh I'm by no means the author) in order to make it
> work on win32, so I have a little bit of a clue around that code ATM.
>
> As for the other part - will core accept this - I can't answer that. I
> do beleive that there is a point to it, given that Java will then
> support it natively, but I'm not core. I'm unsure if there is a clear
> view on the merits of adding more authentication options..

From the lack of traffic on this list I gather that the core
developers no longer hang out here. I've been gone for a few years.

For the record here's the arguments:

SASL is a "standards track RFC" (I saw those snide comments in the
record, Mr. Lane ;-) which allows you to plug in authentication
mechanisms, much like PAM allows you to plug in password checkers.
It is well adopted, since it forms the basis of most email protocols'
authentication, as well as LDAP and Jabber.

SASL provides a unified way for code to support all the
authentication options you're likely to want.

a) In the absence of OS-provided SASL libraries a simple password-
checking mechanism could be implemented as a wire-compatible fallback
with less code than the framework would take. (I won't write this,
but you could probably steal code from jabberd.)

b) SASL includes simple password checking mechanisms. In principle
we could use these to check the local postgres passwords. Not sure
how much customization that would require.

c) If you are using SSL/TLS for client/server connections (or it's a
local on-machine connection) you can use the SASL_EXTERNAL mechanism
to pick up the identity from the connection, without imposing extra
overhead.

d) SASL includes enterprise-class authentication support, such as
GSSAPI (and Kerberos via GSSAPI). If an enterprise has some unique
authentication infrastructure it can be implemented as a SASL (or
GSSAPI) plug-in without the need to customize PostgreSQL.

e) After the initial connection, SASL can be configured to run the
connection fully encrypted, integrity protected, or unprotected.

f) SASL support is available in current Java as well as C. SASL
libraries are included (or at least loadable) on MacOS, Solaris 10+,
and Linux. (I don't do windows, so I can't say there.) While it has
a reputation for complexity, that complexity is in building the
libraries, not in using them.

It can be used to provide most (all?) of the functionality now
provided by the assortment of existing mechanisms. If provided as an
alternative, it could eventually allow decommissioning of a lot of
the other mechanisms. If the number of existing mechanisms is an
issue, then this could be a big long-term win.

I'll assume the ball is in my court now, unless someone wants to
claim I should just do GSSAPI and not bother with the higher level.
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> > As for the other part - will core accept this - I can't
> answer that. I
> > do beleive that there is a point to it, given that Java will then
> > support it natively, but I'm not core. I'm unsure if there
> is a clear
> > view on the merits of adding more authentication options..
>
> From the lack of traffic on this list I gather that the core
> developers no longer hang out here. I've been gone for a few years.

Oh, they most definitly do. Every one of them. They just don't write in
every single thread (though sometimes I wonder about Tom..)

I noticed you copied Tom Lockhart - he isn't core anymore, so don't
expect a response there. Tom Lane is, though, and I'm sure he'll
respond.


> For the record here's the arguments:
<snip a bunch of SASL arguments that I'm sure are perfectly valid>


> f) SASL support is available in current Java as well as C.
> SASL libraries are included (or at least loadable) on MacOS,
> Solaris 10+, and Linux. (I don't do windows, so I can't say
> there.) While it has a reputation for complexity, that
> complexity is in building the libraries, not in using them.
>
> It can be used to provide most (all?) of the functionality
> now provided by the assortment of existing mechanisms.

Well, it's still a complexity you need to deal with. Plus, just Java and
C is far from enough, if you are intending to suggest we replace some of
what we have now with it (like passwords and other such things). For
example, you need things like perl, python, ruby, C#, etc etc. not sure
how many of those would be fine with a C wrapper, I know for a fact that
C# (or other .net languages) wouldn't, they need it natively.

There also used to be some bad portability issues wrt at least some of
the SASL libraries (if there is more than one). I know I tried to make
it work on win32 once and failed miserably. (Then again, I've failed on
Linux as well, but not quite as bad. And it's not included in all Linux
distributions, at least it wasn't when I checked a while back)

And finally, there's backwards compatibility. We're still going to have
to support all the existing ones for the forseeable future unless you
want to prevent all older clients from connecting (hint: you don't).


> If provided as an alternative, it could eventually allow
> decommissioning of a lot of the other mechanisms. If the
> number of existing mechanisms is an issue, then this could be
> a big long-term win.

Me, I think providing it as an alternative is the path to go. Which also
means that I think implementing GSSAPI for that (probably in long-term
to *replace* our current Kerberos authentication, in short-term to
complement it) rather than SASL, because it's significantly simpler.

> I'll assume the ball is in my court now, unless someone wants
> to claim I should just do GSSAPI and not bother with the higher level.

That would be my suggestion - do GSSAPI only and leave the current
methods the way they are. This should be doable without a huge amount of
code, and without affecting the other well-working mechanisms.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"Magnus Hagander" <mha@sollentuna.net> writes:
> As for the other part - will core accept this - I can't answer that.

It would depend in part on the size of the patch, and on whether there
are any arguments for supporting GSSAPI besides "Java can't do Kerberos".
What would it buy for a libpq user?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> > As for the other part - will core accept this - I can't answer that.
>
> It would depend in part on the size of the patch, and on
> whether there are any arguments for supporting GSSAPI besides
> "Java can't do Kerberos".
> What would it buy for a libpq user?

I don't know, really ;-) It seems we're fairly alone in *not* doing
GSSAPI (given for example the MIT Kerberos bug I uncovered when working
on it, that was at the very core of the codepath we're using, which
shows that others arne't using that). We'd be using a much better tested
code, I think.

It *may* be that life on win32 would be much easier, given that Windows
SSPI is supposed to be compatible with GSSAPI when used in the right
way. I don't know any details about this, though. If it does, it would
likely make life easier for .NET applications as well, not just Java.

I'll leave it to Henry to add some more arguments :-)

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Kris,

> I would if we could get some -hackers buy in on the idea. Adding
> more and more auth methods is something they're not excited about
> unless there's a good reason (which I think this is).

Actually, I've been trying to get some of the Sun engineers to
contribute patches for Solaris authentication methods, of which GSSAPI
is one. So in theory someone from Sun should be looking at coding
this.


Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org