From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Andrew Sullivan" <ajs(at)crankycanuck(dot)ca> |
Subject: | Re: Design Considerations for New Authentication Methods |
Date: | 2006-11-03 07:13:55 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA0FCEF@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-11-03 07:16:23 | Re: Design Considerations for New Authentication Methods |
Previous Message | Magnus Hagander | 2006-11-03 07:05:05 | Re: Design Considerations for New Authentication Methods |