[19186] in Kerberos
Re: Apps aquiring tickets (was Re: gssapi/openssh)
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat May 3 16:54:44 2003
To: "James F.Hranicky" <jfh@cise.ufl.edu>
From: Sam Hartman <hartmans@MIT.EDU>
Date: Sat, 03 May 2003 16:51:30 -0400
In-Reply-To: <20030502102433.15a3d313.jfh@cise.ufl.edu> ("James
F.Hranicky"'s message of "Fri, 2 May 2003 10:24:33 -0400")
Message-ID: <87issrg3e5.fsf@luminous.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
cc: kerberos@mit.edu
cc: Simon Wilkinson <sxw@warspite.inf.ed.ac.uk>
Errors-To: kerberos-bounces@mit.edu
>>>>> "James" == James F Hranicky <jfh@cise.ufl.edu> writes:
James> On Wed, 30 Apr 2003 18:25:47 +0100
James> Simon Wilkinson <sxw@warspite.inf.ed.ac.uk> wrote:
>> No, it doesn't. Philosophically, I don't think that its the job
>> of the client to go out and get credentials, if none
>> exist. Practically, doing so would require the client to know
>> about the underlying GSSAPI mechanism, which at present it
>> doesn't need to.
James> I understand this sentiment (especially with GSSAPI given
James> its a layer that uses Kerberos, but isn't itself Kerberos),
James> but I think that if the following were true it would be a
James> boon for the user:
James> 1) applications could get a TGT for a given realm
James> stored in a single common place that other apps could use
They can.
James> 2) the ticket cache could contain TGTs for multiple
James> realms
I think if you want this you need to think through exactly what it
would mean and come up with a concrete proposal that looks at
implementation issues. If you can do that then please write up your
proposal and send to krbdev@mit.edu.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
