GSSAPI, SSPI - include_realm default

Greetings,
 The include_realm default for GSSAPI and SSPI is currently 'include_realm=0', meaning that the realm is stripped off
ofthe Kerberos principal (aka the 'system' username) prior to looking up the user in pg_authid.
 
 This is fine in a single-realm environment but extremely dangerous in a multi-realm environment, as user@REALMA is
rarelythe same as user@REALMB.  Worse, a given environment can go from single-realm to multi-realm with relative ease
andmost administrators aren't going to expect applications to have a problem with that change.  Every other
Kerberos-enabledapplication which I'm aware of requires either the full principal (including realm) be considered, or
thatthe realm of the principal matches the realm of the system (which is what OpenSSH requires, as an example).
 
 As such, I'd like to propose changing the default to be 'include_realm=1'.
 Back when Kerberos support was originally added, we didn't have the pg_ident regex-based mapping capability.  Today,
userswho wish to strip the realm off would be best served by configuring a mapping in pg_ident.conf which strips off
exactlythe realm name (or names, if they are multi-realm where the users actually are the same individuals in multiple
realms)instead of using 'include_realm=0'.
 
 Users who really wish to strip off the realm for their environment would still be able to add 'include_realm=0' to
theirpg_hba.conf. We would recommend against that in the documentation, however, and explain how it's unsafe.  I would
recommendthat this be coached as transistional support for users who wish to upgrade but don't want to (further) change
theirconfiguration immediately, with the implication that we might remove it some day.
 
 This would be done for 9.5 and we would need to note it in the release notes, of course.
 Shipping an insecure pg_hba.conf as the default (with 'trust') works because the distributions change it to a more
securesetting anyway. There's no similar option to change the default for include_realm short of hacking the source
codeand documentation, which would be much more invasive and likely invite complaints from users when their
configurationdoesn't work the way the postgresql.org docs claim it should.
 
 Thoughts?
     Thanks!
    Stephen