Re: Design Considerations for New Authentication Methods

Magnus Hagander <mha@sollentuna.net>

From: "Magnus Hagander" <mha@sollentuna.net>
To: "Joshua D. Drake" <jd@commandprompt.com>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <josh@agliodbs.com>, <pgsql-hackers@postgresql.org>, "Andrew Sullivan" <ajs@crankycanuck.ca>
Date: 2006-11-03T07:13:55Z
Lists: pgsql-hackers
> >> ... 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 
> we'd known 
> > then what we know now.  It's been a constant source of bugs 
> ever since 
> > it went in, and with so few users of the feature, it takes 
> a long time 
> > to find the problems.
> 
> 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 clients on
windows, servers on linux here - at least in my case). I know several
people who use it, most just don't post here ;-)

Now, it would likely be a lot *easier* to do this with GSSAPI than the
pure kerberos stuff we have now, given that the Windows native APIs
support GSSAPI compatible stuff, but not the stuff we have now.

//Magnus