[3640] in java-interest
[very late] Re: How java apps get krb tickets?
daemon@ATHENA.MIT.EDU (Larry S. Bartz)
Mon Nov 20 21:44:09 1995
Date: Mon, 20 Nov 1995 19:50:29 -0500 (EST)
From: "Larry S. Bartz" <lsbart35@emmo.indy.cr.irs.gov>
To: Mark Eichin <eichin@cygnus.com>
Cc: acain@snapple.ncsa.uiuc.edu, java-kerberos@lists.Stanford.EDU,
www-kerberos@lists.Stanford.EDU, java-interest@java.sun.com
In-Reply-To: <199511142006.PAA05687@tweedledumber.cygnus.com>
I'm sorry to be so late in my reply. The furlough really slowed
me down.
On Tue, 14 Nov 1995, Mark Eichin wrote:
> Date: Tue, 14 Nov 1995 15:06:18 -0500
> From: Mark Eichin <eichin@cygnus.com>
> To: lsbart35@emmo.indy.cr.irs.gov
> Cc: acain@snapple.ncsa.uiuc.edu, java-kerberos@lists.Stanford.EDU,
> www-kerberos@lists.Stanford.EDU, java-interest@java.sun.com
> Subject: Re: How java apps get krb tickets?
>
>
> If you have the java app prompt for a password and get it's own non
> cached tickets, you've eliminated the entire single-signon aspect of
> kerberos... unless, of course, you expect that users will *only* be
> using kerberos through this java app; do you? Or are they just going
> to have to give eudora their password again because the cache isn't
> shared? (It also ignores forwarded credentials in V5, but presumably
> the user is running the app locally anyhow...)
> _Mark_
>
Yeah, when I said "tough applets" about the potential for a java applet
to manage its own private ticket cache I really shot my "Grand Integration"
argument in the head, didn't I? I really was only thinking about kerberized
Web apps, because right now there is no other Kerberos in my environment.
Having a suite of kerberized java applets which don't share the
ticket cache would satisfy only the ignorant. It wouldn't be a
Good Thing, I (being slightly less ignorant than I was last week)
must agree.
The good news is that messages from Adam Jack, Marc Horowitz, and David
Richardson on this subject last week appear to indicate that Sid Conklin's
work may proceed with a significant potential for successful implementation.
What do you say, Sid? Has your alarm subsided? Do you see a way, based
upon the suggestions that Kerberos could be supported by native methods
which are not loaded interactively?
What is the potential for this approach in non-UNIX clients? Are the
necessary kerberos libraries freely available?
I really expected a little more "official" input on this question, since
Sun's HotJava White Paper made such a big deal over HotJava/Java's
potential for accomodating various authentication, authorization, and
security schemes.
--
#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# 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
