[3485] in java-interest
Re: How java apps get krb tickets?
daemon@ATHENA.MIT.EDU (Larry S. Bartz)
Tue Nov 14 15:09:26 1995
Date: Tue, 14 Nov 1995 11:27:42 -0500 (EST)
From: "Larry S. Bartz" <lsbart35@emmo.indy.cr.irs.gov>
To: Adam Cain <acain@snapple.ncsa.uiuc.edu>
Cc: java-kerberos@lists.Stanford.EDU, www-kerberos@lists.Stanford.EDU,
java-interest@java.sun.com
In-Reply-To: <9511111352.ZM13729@snapple.ncsa.uiuc.edu>
On Sat, 11 Nov 1995, Adam Cain wrote:
> Date: Sat, 11 Nov 1995 13:52:55 -0600
> From: Adam Cain <acain@snapple.ncsa.uiuc.edu>
> To: java-kerberos@lists.Stanford.EDU
> Subject: How java apps get krb tickets?
>
> First, to address a previous question/concern:
>
> The Kerberized Mosaic certainly does check the ticket cache before
> it asks for a kerberos password. Obviously, we put in the capability
> to klogin from within Mosaic so that things are easier to use, especially
> for the somewhat kerberos-naive user. We feared that simply displaying
> a message like "sorry, you must klogin to get a TGT" and then expecting
> the user to go off into some other shell to do "kinit" might be considered
> too laborious or cryptic by "normal" users. Yet, I can certainly appreciate
> the spirit of keeping the password/TGT functions only in kinit/klog. I'll
> discuss this also with people on the www-kerberos list and if enough people
> object to this feature (really, we worked hard on this particular "bug"),
> then we'll take it out.
Take it out?
Don't you dare! Your initial notions on this subject are the correct ones.
We'll never be able to implement the Kerberized Web if we make it too
clunky for Joe Average User. A large part of the beauty of putting our
applications up on the Web (and kerberizing the authentication and
authorization) is that we are providing the potential for unprecedented
levels of wide scale integration; making the matrix (uh, the Web) look
like it is "all one thing" to our customers.
There is tremendous value in this integration. Anything which detracts
from it will naturally detract from its potential beauty (for us), and
its usability (for our customers).
Adam continued:
>
> But back to the orginal question of how the kerberized java app gets
> its tickets. Let me summarize my understanding of the last couple notes
> from Mark and Roland, with respect to this question (and again, please
> forgive my relative unfamliarity with the details of java's security
> mechanisms). It seems there are two basic approaches for this:
>
> 1. The java applet could get the user's kerberos password and then get a TGT.
> From that point on, it gets its own tickets from the KDC, as needed.
>
> 2. The java applet could get tickets using the user's ticket cache. Assuming
> the cache has a TGT, the applet can also get tickets from the KDC.
>
> As Mark mentioned, #1 makes security people nervous, as it is quite risky and
> somewhat contrary to the intent of kerberos.
>
> As for #2, Roland points out that the applet probably can't (and should not
> be able to) access the user's ticket cache.
Ken Arnold (addressing an unrelated issue for the java-interest@java.sun.com
list members) also drives Roland's point home. This point was
also described by David R Richardson <normanb@citi.umich.edu> for the
java-kerberos list last week. Because the applets are not allowed to load
native methods, #1 will be the only way to go.
So the java kerberos applet can't share its ticket cache with other apps?
Tough applets, I say; a small price to pay.
>
> I also wonder about the applet's abililty to cache tickets -- can it save to a
> file, or must it keep everything it needs in memory? Also, what does the
> user have to do in order to allow java applets to open their own network
> connections (for getting a ticket from the KDC)?
I'd prefer to see the cache simply in applet-managed memory. This way,
it wouldn't conflict with any other cache and they'd go away
when the user terminates the browser session without requiring any
other explicit kdestroy action on their part.
>
>
> Of these two approaches, I don't see one as being clearly superior to the
> other. In either case, the user probably will (and should) have to make
> an acknowledgement of trusting the applet before it can do anything with
> kerberos. With #2, there would probably be some explicit mechanism for
> granting the applet access to the user's ticket cache. For #1, the user is
> putting significantly more trust in the applet (by giving it the kerberos
> password), though there may be ease-of-use reasons for doing it this way.
>
>
Yes, certainly the ease of use issue is important. Else, why would we
bother adapting our applications to the Web? Else, why would we bother
to use Kerberos to provide a "single login" access to multiple services?
--
#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz | |
# lbartz@infostream.cr.irs.gov | Ooo, ooo, |
# | Ooo, ooo, oooooo! |
# | I've got a gnu attitude! |
# voice (317) 226-7060 | |
# FAX (317) 226-6378 | |
#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
