Re: BUG #9337: SSPI/GSSAPI with mismatched user names

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #9337: SSPI/GSSAPI with mismatched user names
Дата
Msg-id 10402.1393278034@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #9337: SSPI/GSSAPI with mismatched user names  (Brian Crowell <brian@fluggo.com>)
Ответы Re: BUG #9337: SSPI/GSSAPI with mismatched user names  (Brian Crowell <brian@fluggo.com>)
Список pgsql-bugs
Brian Crowell <brian@fluggo.com> writes:
> On Mon, Feb 24, 2014 at 2:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If it's possible to extract a principal name from a ticket without
>> contacting the server, then that objection fails ... but if that were
>> the case then I suppose you'd not be here looking for a solution.

> You've got a point. I do believe the principal name is in the ticket
> in clear text. I could generate a ticket in anticipation of needing
> it, extract the name, and send that. I have no idea how to get it, but
> I'll look into it.

> I still think this would be useful in the server.

If it's possible to get a name out of a ticket without contacting a
realm server, I think what you're talking about would likely be all right.
IIUC this approach would also save one round trip to the client to get
the ticket once we've decided to use SSPI auth, so that seems like a
potential benefit independently of where the username is coming from.

I'm not really the house expert on Kerberos-style auth though, so I'd
defer to Stephen and some other people on whether there are hidden
gotchas.

One question worth asking is whether exposing the ticket in the startup
packet is problematic if the startup packet is unencrypted and can be
snooped by third parties.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Brian Crowell
Дата:
Сообщение: Re: BUG #9337: SSPI/GSSAPI with mismatched user names
Следующее
От: Brian Crowell
Дата:
Сообщение: Re: BUG #9337: SSPI/GSSAPI with mismatched user names