pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedMake SSPI documentation clearer
9+ messages / 4 participants
[nested] [flat]
* Make SSPI documentation clearer
@ 2023-03-10 15:30 PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
0 siblings, 1 reply; 9+ messages in thread
From: PG Doc comments form @ 2023-03-10 15:30 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: tpo_deb@sourcepole.ch
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/sspi-auth.html
Description:
The [current SSPI
documentation](https://www.postgresql.org/docs/current/sspi-auth.html)
reads:
"SSPI authentication only works when both server and client are running
Windows, or, on non-Windows platforms, when GSSAPI is available."
I interpret that phrase like this:
* there's a case where both server and client are running Windows
* there's a case where both are running non-Windows
What about mixed cases? When the client is non-Windows, then can it use
SSPI? No, AFAIK not. So I'd suggest to make that phrase above clearer and
completely explicit:
"SSPI authentication works when both server and client are running
Windows.
When the server is on a non-Windows platform then the server must use GSSAPI
if it wants to authenticate the client either via Kerberos or via Active
Directory. A client on a Windows platform that connects to a non-Windows
Postgresql server can either use SSPI (strongly encouraged) or GSS (much
more difficult to set up) if it wants to authenticate via Kerberos or Active
Directory. A client from a non-Windows platform must use GSS if it wants to
authenticate via Kerberos or Active Directory."
Thanks a lot for everything Postgres to you who is reading a considering
this change!
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Make SSPI documentation clearer
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
@ 2023-03-13 00:36 ` Stephen Frost <sfrost@snowman.net>
2023-03-13 09:00 ` Re: Make SSPI documentation clearer Tomas Pospisek <tpo2@sourcepole.ch>
2023-09-27 23:09 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 9+ messages in thread
From: Stephen Frost @ 2023-03-13 00:36 UTC (permalink / raw)
To: tpo_deb@sourcepole.ch; pgsql-docs@lists.postgresql.org
Greetings,
* PG Doc comments form (noreply@postgresql.org) wrote:
> Page: https://www.postgresql.org/docs/15/sspi-auth.html
> Description:
>
> The [current SSPI
> documentation](https://www.postgresql.org/docs/current/sspi-auth.html)
> reads:
>
> "SSPI authentication only works when both server and client are running
> Windows, or, on non-Windows platforms, when GSSAPI is available."
>
> I interpret that phrase like this:
>
> * there's a case where both server and client are running Windows
> * there's a case where both are running non-Windows
Yeah, that phrasing isn't great.
> What about mixed cases? When the client is non-Windows, then can it use
> SSPI? No, AFAIK not. So I'd suggest to make that phrase above clearer and
> completely explicit:
SSPI is Windows-specific, yeah.
> "SSPI authentication works when both server and client are running
> Windows.
>
> When the server is on a non-Windows platform then the server must use GSSAPI
> if it wants to authenticate the client either via Kerberos or via Active
> Directory. A client on a Windows platform that connects to a non-Windows
> Postgresql server can either use SSPI (strongly encouraged) or GSS (much
> more difficult to set up) if it wants to authenticate via Kerberos or Active
> Directory. A client from a non-Windows platform must use GSS if it wants to
> authenticate via Kerberos or Active Directory."
Rather than work in negative, I feel like it might make more sense to
work in positives? That is, perhaps this instead:
On Windows platforms, SSPI is the default and most commonly used
mechanism. Note that an SSPI client can authenticate to a server which
is using either SSPI or GSSAPI, and a GSSAPI client can authenticate to
a server which is using either SSPI or GSSAPI. Generally speaking,
clients and servers on Windows are recommended to use SSPI while clients
and servers on Unix (non-Windows) platforms use GSSAPI.
Stricltly speaking, this is all independent of if AD is being used as
the KDC or not.
Thanks,
Stephen
Attachments:
[application/pgp-signature] signature.asc (832B, ../../ZA5wJQFOcULuIwwn@tamriel.snowman.net/2-signature.asc)
download
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Make SSPI documentation clearer
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
@ 2023-03-13 09:00 ` Tomas Pospisek <tpo2@sourcepole.ch>
2023-03-20 12:08 ` Re: Make SSPI documentation clearer Tomas Pospisek <tpo2@sourcepole.ch>
1 sibling, 1 reply; 9+ messages in thread
From: Tomas Pospisek @ 2023-03-13 09:00 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; pgsql-docs@lists.postgresql.org
On 13.03.23 01:36, Stephen Frost wrote:
> * PG Doc comments form (noreply@postgresql.org) wrote:
> > Page: https://www.postgresql.org/docs/15/sspi-auth.html
> > Description:
> >
> > The [current SSPI
> > documentation](https://www.postgresql.org/docs/current/sspi-auth.html)
> > reads:
> >
> > "SSPI authentication only works when both server and client are
> > running Windows, or, on non-Windows platforms, when GSSAPI is
> > available."
> >
> > I interpret that phrase like this:
> >
> > * there's a case where both server and client are running Windows
> > * there's a case where both are running non-Windows
>
> Yeah, that phrasing isn't great.
>
> > What about mixed cases? When the client is non-Windows, then can it
> > use SSPI? No, AFAIK not. So I'd suggest to make that phrase above
> > clearer and completely explicit:
>
> SSPI is Windows-specific, yeah.
>
> > "SSPI authentication works when both server and client are running
> > Windows.
> >
> > When the server is on a non-Windows platform then the server must
> > use GSSAPI if it wants to authenticate the client either via
> > Kerberos or via Active Directory. A client on a Windows platform
> > that connects to a non-Windows Postgresql server can either use SSPI
> > (strongly encouraged) or GSS (much more difficult to set up) if it
> > wants to authenticate via Kerberos or Active Directory. A client
> > from a non-Windows platform must use GSS if it wants to authenticate
> > via Kerberos or Active Directory."
>
> Rather than work in negative, I feel like it might make more sense to
> work in positives? That is, perhaps this instead:
>
> On Windows platforms, SSPI is the default and most commonly used
> mechanism. Note that an SSPI client can authenticate to a server
> which is using either SSPI or GSSAPI, and a GSSAPI client can
> authenticate to a server which is using either SSPI or GSSAPI.
> Generally speaking, clients and servers on Windows are recommended to
> use SSPI while clients and servers on Unix (non-Windows) platforms use
> GSSAPI.
>
> Stricltly speaking, this is all independent of if AD is being used as
> the KDC or not.
I agree, that's a better formulation. I'd suggest to improve your
version in three ways:
1. replace "mechanism" with "authentication mechanism"
2. be explicit about Active Directory so there's no doubt wrt to setting
up authentication
3. be explicit that GSSAPI should be used on non-Windows platform
servers when one wants clients in an AD domain to seamlessly
authenticate with the non-Windows server. I'd mention that because if
the windows clients are *not* in an AD domain then they will *not* be
able to authenticate to the non-Windows server with GSSAPI.
So finally the whole start of the SSPI paragraph in the docu would look
like this:
----------------------
21.7. SSPI Authentication
On Windows platforms, SSPI is the default and most commonly used
authentication mechanism. Note that an SSPI client can authenticate to
a server which is using either SSPI or GSSAPI, and a GSSAPI client can
authenticate to a server which is using either SSPI or GSSAPI.
Generally speaking, clients and servers on Windows are recommended to
use SSPI while clients and servers on Unix (non-Windows) platforms are
recommended to use GSSAPI if they want to interoperate seamlessly with
Active Directory or Kerberos authentication.
When using Kerberos authentication, SSPI works the same way GSSAPI does;
see Section 21.6 for details.
----------------------
If the docu is changed in this way, then the phrase "PostgreSQL will use
SSPI in negotiate mode" is dropped wrt to the previous documentation. I
have not been able to find out what "SSPI in negotion mode" is and
therefore if it's in any way relevant to mention that in the docs.
Thanks,
*t
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Make SSPI documentation clearer
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
2023-03-13 09:00 ` Re: Make SSPI documentation clearer Tomas Pospisek <tpo2@sourcepole.ch>
@ 2023-03-20 12:08 ` Tomas Pospisek <tpo2@sourcepole.ch>
2023-03-20 12:44 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
0 siblings, 1 reply; 9+ messages in thread
From: Tomas Pospisek @ 2023-03-20 12:08 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; pgsql-docs@lists.postgresql.org
Hi pgsql documenters,
what is the status of bringing the proposed SSPI documentation chages
into the git repo?
- is there anything to be improved or missing with the proposed changes?
- does the improvement need a hat tip of someone?
- anybody here that has the guts, time and willingness to take the
supposed improvement and apply put it into the git repo?
Anything else needed here?
If the change is in principle OK, then I can prepare a patch or such (I
assume postgres doesn't take pull requests from
https://github.com/postgres ?)?
Greetings,
*t
On 13.03.23 10:00, Tomas Pospisek wrote:
> On 13.03.23 01:36, Stephen Frost wrote:
>
> > * PG Doc comments form (noreply@postgresql.org) wrote:
> > > Page: https://www.postgresql.org/docs/15/sspi-auth.html
> > > Description:
> > >
> > > The [current SSPI
> > > documentation](https://www.postgresql.org/docs/current/sspi-auth.html)
> > > reads:
> > >
> > > "SSPI authentication only works when both server and client are
> > > running Windows, or, on non-Windows platforms, when GSSAPI is
> > > available."
> > >
> > > I interpret that phrase like this:
> > >
> > > * there's a case where both server and client are running Windows
> > > * there's a case where both are running non-Windows
> >
> > Yeah, that phrasing isn't great.
> >
> > > What about mixed cases? When the client is non-Windows, then can it
> > > use SSPI? No, AFAIK not. So I'd suggest to make that phrase above
> > > clearer and completely explicit:
> >
> > SSPI is Windows-specific, yeah.
> >
> > > "SSPI authentication works when both server and client are running
> > > Windows.
> > >
> > > When the server is on a non-Windows platform then the server must
> > > use GSSAPI if it wants to authenticate the client either via
> > > Kerberos or via Active Directory. A client on a Windows platform
> > > that connects to a non-Windows Postgresql server can either use SSPI
> > > (strongly encouraged) or GSS (much more difficult to set up) if it
> > > wants to authenticate via Kerberos or Active Directory. A client
> > > from a non-Windows platform must use GSS if it wants to authenticate
> > > via Kerberos or Active Directory."
> >
> > Rather than work in negative, I feel like it might make more sense to
> > work in positives? That is, perhaps this instead:
> >
> > On Windows platforms, SSPI is the default and most commonly used
> > mechanism. Note that an SSPI client can authenticate to a server
> > which is using either SSPI or GSSAPI, and a GSSAPI client can
> > authenticate to a server which is using either SSPI or GSSAPI.
> > Generally speaking, clients and servers on Windows are recommended to
> > use SSPI while clients and servers on Unix (non-Windows) platforms use
> > GSSAPI.
> >
> > Stricltly speaking, this is all independent of if AD is being used as
> > the KDC or not.
>
> I agree, that's a better formulation. I'd suggest to improve your
> version in three ways:
>
> 1. replace "mechanism" with "authentication mechanism"
> 2. be explicit about Active Directory so there's no doubt wrt to setting
> up authentication
> 3. be explicit that GSSAPI should be used on non-Windows platform
> servers when one wants clients in an AD domain to seamlessly
> authenticate with the non-Windows server. I'd mention that because if
> the windows clients are *not* in an AD domain then they will *not* be
> able to authenticate to the non-Windows server with GSSAPI.
>
> So finally the whole start of the SSPI paragraph in the docu would look
> like this:
>
>
> ----------------------
>
> 21.7. SSPI Authentication
>
> On Windows platforms, SSPI is the default and most commonly used
> authentication mechanism. Note that an SSPI client can authenticate to
> a server which is using either SSPI or GSSAPI, and a GSSAPI client can
> authenticate to a server which is using either SSPI or GSSAPI.
> Generally speaking, clients and servers on Windows are recommended to
> use SSPI while clients and servers on Unix (non-Windows) platforms are
> recommended to use GSSAPI if they want to interoperate seamlessly with
> Active Directory or Kerberos authentication.
>
> When using Kerberos authentication, SSPI works the same way GSSAPI does;
> see Section 21.6 for details.
>
> ----------------------
>
> If the docu is changed in this way, then the phrase "PostgreSQL will use
> SSPI in negotiate mode" is dropped wrt to the previous documentation. I
> have not been able to find out what "SSPI in negotion mode" is and
> therefore if it's in any way relevant to mention that in the docs.
>
> Thanks,
> *t
>
>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Make SSPI documentation clearer
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
2023-03-13 09:00 ` Re: Make SSPI documentation clearer Tomas Pospisek <tpo2@sourcepole.ch>
2023-03-20 12:08 ` Re: Make SSPI documentation clearer Tomas Pospisek <tpo2@sourcepole.ch>
@ 2023-03-20 12:44 ` Stephen Frost <sfrost@snowman.net>
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Frost @ 2023-03-20 12:44 UTC (permalink / raw)
To: Tomas Pospisek <tpo2@sourcepole.ch>; +Cc: pgsql-docs@lists.postgresql.org
Greetings,
* Tomas Pospisek (tpo2@sourcepole.ch) wrote:
> what is the status of bringing the proposed SSPI documentation chages into
> the git repo?
> - is there anything to be improved or missing with the proposed changes?
... maybe, see below.
> - does the improvement need a hat tip of someone?
Needs a committer willing to include the change. I'm generally alright
with being that committer once we get to some finalized wording unless
there's comments from others.
> - anybody here that has the guts, time and willingness to take the
> supposed improvement and apply put it into the git repo?
This isn't helpful and frankly is detrimental to getting this change
included. We strive strongly to have a positive tone and focus on
technical excellence.
> Anything else needed here?
See below for comments on the change.
> If the change is in principle OK, then I can prepare a patch or such (I
> assume postgres doesn't take pull requests from https://github.com/postgres
> ?)?
If you'd like to work on a patch, that'd be great. The process would be
to make the change in your local git repo, create a patch with the change
(generally with git format-patch) and then post an email to the
pgsql-hackers mailing list with the proposed patch and finally register
it into the open commitfest (which is the app that we use for managing
the many, many requested changes to PG):
https://commitfest.postgresql.org
> On 13.03.23 10:00, Tomas Pospisek wrote:
> > On 13.03.23 01:36, Stephen Frost wrote:
> >
> > > * PG Doc comments form (noreply@postgresql.org) wrote:
> > > > Page: https://www.postgresql.org/docs/15/sspi-auth.html
> > > > Description:
> > > >
> > > > The [current SSPI
> > > > documentation](https://www.postgresql.org/docs/current/sspi-auth.html)
> > > > reads:
> > > >
> > > > "SSPI authentication only works when both server and client are
> > > > running Windows, or, on non-Windows platforms, when GSSAPI is
> > > > available."
> > > >
> > > > I interpret that phrase like this:
> > > >
> > > > * there's a case where both server and client are running Windows
> > > > * there's a case where both are running non-Windows
> > >
> > > Yeah, that phrasing isn't great.
> > >
> > > > What about mixed cases? When the client is non-Windows, then can it
> > > > use SSPI? No, AFAIK not. So I'd suggest to make that phrase above
> > > > clearer and completely explicit:
> > >
> > > SSPI is Windows-specific, yeah.
> > >
> > > > "SSPI authentication works when both server and client are running
> > > > Windows.
> > > >
> > > > When the server is on a non-Windows platform then the server must
> > > > use GSSAPI if it wants to authenticate the client either via
> > > > Kerberos or via Active Directory. A client on a Windows platform
> > > > that connects to a non-Windows Postgresql server can either use SSPI
> > > > (strongly encouraged) or GSS (much more difficult to set up) if it
> > > > wants to authenticate via Kerberos or Active Directory. A client
> > > > from a non-Windows platform must use GSS if it wants to authenticate
> > > > via Kerberos or Active Directory."
> > >
> > > Rather than work in negative, I feel like it might make more sense to
> > > work in positives? That is, perhaps this instead:
> > >
> > > On Windows platforms, SSPI is the default and most commonly used
> > > mechanism. Note that an SSPI client can authenticate to a server
> > > which is using either SSPI or GSSAPI, and a GSSAPI client can
> > > authenticate to a server which is using either SSPI or GSSAPI.
> > > Generally speaking, clients and servers on Windows are recommended to
> > > use SSPI while clients and servers on Unix (non-Windows) platforms use
> > > GSSAPI.
> > >
> > > Stricltly speaking, this is all independent of if AD is being used as
> > > the KDC or not.
> >
> > I agree, that's a better formulation. I'd suggest to improve your
> > version in three ways:
> >
> > 1. replace "mechanism" with "authentication mechanism"
Sure.
> > 2. be explicit about Active Directory so there's no doubt wrt to setting
> > up authentication
Not against the idea of mentioning AD...
> > 3. be explicit that GSSAPI should be used on non-Windows platform
> > servers when one wants clients in an AD domain to seamlessly
> > authenticate with the non-Windows server. I'd mention that because if
> > the windows clients are *not* in an AD domain then they will *not* be
> > able to authenticate to the non-Windows server with GSSAPI.
However, Windows systems not in an AD domain can certainly use GSSAPI to
authenticate with the appropriate libraries installed and Kerberos
configured on them.
> > So finally the whole start of the SSPI paragraph in the docu would look
> > like this:
> > ----------------------
> >
> > 21.7. SSPI Authentication
> >
> > On Windows platforms, SSPI is the default and most commonly used
> > authentication mechanism. Note that an SSPI client can authenticate to
> > a server which is using either SSPI or GSSAPI, and a GSSAPI client can
> > authenticate to a server which is using either SSPI or GSSAPI.
> > Generally speaking, clients and servers on Windows are recommended to
> > use SSPI while clients and servers on Unix (non-Windows) platforms are
> > recommended to use GSSAPI if they want to interoperate seamlessly with
> > Active Directory or Kerberos authentication.
> >
> > When using Kerberos authentication, SSPI works the same way GSSAPI does;
> > see Section 21.6 for details.
> >
> > ----------------------
These changes generally seem alright to me and they don't seem to
include an invalid statement such as what you were proposing with #3
above.
> > If the docu is changed in this way, then the phrase "PostgreSQL will use
> > SSPI in negotiate mode" is dropped wrt to the previous documentation. I
> > have not been able to find out what "SSPI in negotion mode" is and
> > therefore if it's in any way relevant to mention that in the docs.
I'm not sure that it's necessary to delve into Negotiate mode either in
this documentation. For those curious, it's essentially another
wrapping of Kerberos, akin to SASL, to allow for other authentication
methods to be used instead of Kerberos (think NTLM). It's been a while
since I delved into it, but my last recollection was that using
Negotiate for any of the other valid options (which was mainly just
NTLM, again, as I recall) other than for Kerberos is basically
deprecated and strongly discouraged.
Thanks,
Stephen
Attachments:
[application/pgp-signature] signature.asc (832B, ../../ZBhVQ9V3pswfCzOf@tamriel.snowman.net/2-signature.asc)
download
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Make SSPI documentation clearer
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
@ 2023-09-27 23:09 ` Bruce Momjian <bruce@momjian.us>
2023-09-28 13:55 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 9+ messages in thread
From: Bruce Momjian @ 2023-09-27 23:09 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; +Cc: tpo_deb@sourcepole.ch; pgsql-docs@lists.postgresql.org
On Sun, Mar 12, 2023 at 08:36:53PM -0400, Stephen Frost wrote:
> > When the server is on a non-Windows platform then the server must use GSSAPI
> > if it wants to authenticate the client either via Kerberos or via Active
> > Directory. A client on a Windows platform that connects to a non-Windows
> > Postgresql server can either use SSPI (strongly encouraged) or GSS (much
> > more difficult to set up) if it wants to authenticate via Kerberos or Active
> > Directory. A client from a non-Windows platform must use GSS if it wants to
> > authenticate via Kerberos or Active Directory."
>
> Rather than work in negative, I feel like it might make more sense to
> work in positives? That is, perhaps this instead:
>
> On Windows platforms, SSPI is the default and most commonly used
> mechanism. Note that an SSPI client can authenticate to a server which
> is using either SSPI or GSSAPI, and a GSSAPI client can authenticate to
> a server which is using either SSPI or GSSAPI. Generally speaking,
> clients and servers on Windows are recommended to use SSPI while clients
> and servers on Unix (non-Windows) platforms use GSSAPI.
I developed the attached patch.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Attachments:
[text/x-diff] sspi.diff (1.2K, ../../ZRS2Dpp4mX0plOaN@momjian.us/2-sspi.diff)
download | inline diff:
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
new file mode 100644
index a72f80f..fa53a0f
*** a/doc/src/sgml/client-auth.sgml
--- b/doc/src/sgml/client-auth.sgml
*************** omicron bryanh
*** 1505,1514 ****
<literal>negotiate</literal> mode, which will use
<productname>Kerberos</productname> when possible and automatically
fall back to <productname>NTLM</productname> in other cases.
! <productname>SSPI</productname> authentication only works when both
! server and client are running <productname>Windows</productname>,
! or, on non-Windows platforms, when <productname>GSSAPI</productname>
! is available.
</para>
<para>
--- 1505,1514 ----
<literal>negotiate</literal> mode, which will use
<productname>Kerberos</productname> when possible and automatically
fall back to <productname>NTLM</productname> in other cases.
! <productname>SSPI</productname> and <productname>GSSAPI</productname>
! interoperate as clients and servers. It is recommended to use
! <productname>SSPI</productname> on Windows clients and servers and
! <productname>GSSAPI</productname> on non-Windows platforms.
</para>
<para>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Make SSPI documentation clearer
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
2023-09-27 23:09 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
@ 2023-09-28 13:55 ` Bruce Momjian <bruce@momjian.us>
2023-10-10 20:51 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 9+ messages in thread
From: Bruce Momjian @ 2023-09-28 13:55 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; +Cc: tpo_deb@sourcepole.ch; pgsql-docs@lists.postgresql.org
On Wed, Sep 27, 2023 at 07:09:02PM -0400, Bruce Momjian wrote:
> On Sun, Mar 12, 2023 at 08:36:53PM -0400, Stephen Frost wrote:
> > > When the server is on a non-Windows platform then the server must use GSSAPI
> > > if it wants to authenticate the client either via Kerberos or via Active
> > > Directory. A client on a Windows platform that connects to a non-Windows
> > > Postgresql server can either use SSPI (strongly encouraged) or GSS (much
> > > more difficult to set up) if it wants to authenticate via Kerberos or Active
> > > Directory. A client from a non-Windows platform must use GSS if it wants to
> > > authenticate via Kerberos or Active Directory."
> >
> > Rather than work in negative, I feel like it might make more sense to
> > work in positives? That is, perhaps this instead:
> >
> > On Windows platforms, SSPI is the default and most commonly used
> > mechanism. Note that an SSPI client can authenticate to a server which
> > is using either SSPI or GSSAPI, and a GSSAPI client can authenticate to
> > a server which is using either SSPI or GSSAPI. Generally speaking,
> > clients and servers on Windows are recommended to use SSPI while clients
> > and servers on Unix (non-Windows) platforms use GSSAPI.
>
> I developed the attached patch.
My first attempt was too terse, so here is a more detailed version,
attached.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Attachments:
[text/x-diff] sspi.diff (1.1K, ../../ZRWF3%2FhQPyUZb8om@momjian.us/2-sspi.diff)
download | inline diff:
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index a72f80f033..9d1e7d63ef 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -1505,10 +1505,12 @@ omicron bryanh guest1
<literal>negotiate</literal> mode, which will use
<productname>Kerberos</productname> when possible and automatically
fall back to <productname>NTLM</productname> in other cases.
- <productname>SSPI</productname> authentication only works when both
- server and client are running <productname>Windows</productname>,
- or, on non-Windows platforms, when <productname>GSSAPI</productname>
- is available.
+ <productname>SSPI</productname> and <productname>GSSAPI</productname>
+ interoperate as clients and servers, e.g., an
+ <productname>SSPI</productname> client can authenticate to an
+ <productname>GSSAPI</productname> server. It is recommended to use
+ <productname>SSPI</productname> on Windows clients and servers and
+ <productname>GSSAPI</productname> on non-Windows platforms.
</para>
<para>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Make SSPI documentation clearer
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
2023-09-27 23:09 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
2023-09-28 13:55 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
@ 2023-10-10 20:51 ` Bruce Momjian <bruce@momjian.us>
2023-10-14 14:58 ` Re: Make SSPI documentation clearer Tomas Pospisek <tpo2@sourcepole.ch>
0 siblings, 1 reply; 9+ messages in thread
From: Bruce Momjian @ 2023-10-10 20:51 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; +Cc: tpo_deb@sourcepole.ch; pgsql-docs@lists.postgresql.org
On Thu, Sep 28, 2023 at 09:55:43AM -0400, Bruce Momjian wrote:
> On Wed, Sep 27, 2023 at 07:09:02PM -0400, Bruce Momjian wrote:
> > On Sun, Mar 12, 2023 at 08:36:53PM -0400, Stephen Frost wrote:
> > > > When the server is on a non-Windows platform then the server must use GSSAPI
> > > > if it wants to authenticate the client either via Kerberos or via Active
> > > > Directory. A client on a Windows platform that connects to a non-Windows
> > > > Postgresql server can either use SSPI (strongly encouraged) or GSS (much
> > > > more difficult to set up) if it wants to authenticate via Kerberos or Active
> > > > Directory. A client from a non-Windows platform must use GSS if it wants to
> > > > authenticate via Kerberos or Active Directory."
> > >
> > > Rather than work in negative, I feel like it might make more sense to
> > > work in positives? That is, perhaps this instead:
> > >
> > > On Windows platforms, SSPI is the default and most commonly used
> > > mechanism. Note that an SSPI client can authenticate to a server which
> > > is using either SSPI or GSSAPI, and a GSSAPI client can authenticate to
> > > a server which is using either SSPI or GSSAPI. Generally speaking,
> > > clients and servers on Windows are recommended to use SSPI while clients
> > > and servers on Unix (non-Windows) platforms use GSSAPI.
> >
> > I developed the attached patch.
>
> My first attempt was too terse, so here is a more detailed version,
> attached.
Patch applied back to PG 11.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Make SSPI documentation clearer
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Re: Make SSPI documentation clearer Stephen Frost <sfrost@snowman.net>
2023-09-27 23:09 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
2023-09-28 13:55 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
2023-10-10 20:51 ` Re: Make SSPI documentation clearer Bruce Momjian <bruce@momjian.us>
@ 2023-10-14 14:58 ` Tomas Pospisek <tpo2@sourcepole.ch>
0 siblings, 0 replies; 9+ messages in thread
From: Tomas Pospisek @ 2023-10-14 14:58 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; Stephen Frost <sfrost@snowman.net>; +Cc: pgsql-docs@lists.postgresql.org
On 10.10.23 22:51, Bruce Momjian wrote:
> On Thu, Sep 28, 2023 at 09:55:43AM -0400, Bruce Momjian wrote:
>> On Wed, Sep 27, 2023 at 07:09:02PM -0400, Bruce Momjian wrote:
>>> On Sun, Mar 12, 2023 at 08:36:53PM -0400, Stephen Frost wrote:
>>>>> When the server is on a non-Windows platform then the server must use GSSAPI
>>>>> if it wants to authenticate the client either via Kerberos or via Active
>>>>> Directory. A client on a Windows platform that connects to a non-Windows
>>>>> Postgresql server can either use SSPI (strongly encouraged) or GSS (much
>>>>> more difficult to set up) if it wants to authenticate via Kerberos or Active
>>>>> Directory. A client from a non-Windows platform must use GSS if it wants to
>>>>> authenticate via Kerberos or Active Directory."
>>>>
>>>> Rather than work in negative, I feel like it might make more sense to
>>>> work in positives? That is, perhaps this instead:
>>>>
>>>> On Windows platforms, SSPI is the default and most commonly used
>>>> mechanism. Note that an SSPI client can authenticate to a server which
>>>> is using either SSPI or GSSAPI, and a GSSAPI client can authenticate to
>>>> a server which is using either SSPI or GSSAPI. Generally speaking,
>>>> clients and servers on Windows are recommended to use SSPI while clients
>>>> and servers on Unix (non-Windows) platforms use GSSAPI.
>>>
>>> I developed the attached patch.
>>
>> My first attempt was too terse, so here is a more detailed version,
>> attached.
>
> Patch applied back to PG 11.
Nice! Thanks a lot Bruce! And:
Stephen wrote:
>
>> Tomas wrote:
>>
>> - anybody here that has the guts, time and willingness to take the
>> supposed improvement and apply put it into the git repo?
>
> This isn't helpful and frankly is detrimental to getting this change
> included. We strive strongly to have a positive tone and focus on
> technical excellence.
Thanks a lot Stephen for this comment! I hope it will cause a more
important change on my side than my minuscule effort to improve the
docu. And sorry I didn't follow up - life piled up and I never came back
to this.
Many thanks Stephen, really, very appreciated and thanks Bruce for
picking up the ball!!!
*t
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2023-10-14 14:58 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-03-10 15:30 Make SSPI documentation clearer PG Doc comments form <noreply@postgresql.org>
2023-03-13 00:36 ` Stephen Frost <sfrost@snowman.net>
2023-03-13 09:00 ` Tomas Pospisek <tpo2@sourcepole.ch>
2023-03-20 12:08 ` Tomas Pospisek <tpo2@sourcepole.ch>
2023-03-20 12:44 ` Stephen Frost <sfrost@snowman.net>
2023-09-27 23:09 ` Bruce Momjian <bruce@momjian.us>
2023-09-28 13:55 ` Bruce Momjian <bruce@momjian.us>
2023-10-10 20:51 ` Bruce Momjian <bruce@momjian.us>
2023-10-14 14:58 ` Tomas Pospisek <tpo2@sourcepole.ch>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox