> > 1) Kerberos should normally be invisible to users; there should be a
> > TGT whenever the user is logged in.
> Yes, for a single realm. The problem is that with the Web you are reading
> documents from all over (many possible realms). Are you going to require
> that the user kinit in a shell window for each document at a different
> site (possibly having to exit the browser each time for line-mode browsers
> with no job control)?
Well, this is the problem. The solution is not to use something like
Kerberos to authenticate a user to a publisher, since Kerberos does not scale to
the level we are going to need on the Global Internet.
The easy solution is to support the idea of "authentication servers"
where the user is a member or subscriber to an authentication server which is
responsible to identify the particular user to potential publishers. The
publisher is a subscriber to the same or a different authentication server (and
in this case, we assume that the authentication servers have a trusted method to
share the burden.)
Let me try a real world example:
aUser subscribes to AuthenticationServer-A.
(happens only once)
aUser authenticates herself to AuthenticationServer-A via Kerberos.
(happens once per session)
aUser is now ready to receive documents.
-----------------------------------------------------
aPublisher subscribes to AuthenticationServer-B.
(happens only once)
aPublisher authenticates itself to AuthenticationServer-B.
(happens when publisher reboots)
aPublisher is now ready for business.
-----------------------------------------------------
aUser wishes to retrieve aDocument from aPublisher
aUser requests aDocument from aPublisher
-- Along with the request goes something along the lines of:
AuthAgency AuthMethod UserCredentials
---------- ---------- ---------------
Server-A Kerberos [HOSTNAME]
[USERNAME]
[KERB-TICKET] (opaque data)
a URA (Uniform Resource Authenticator) might look like:
Kerberos://Server-A/hostname/username/kerb-ticket
aPublisher checks with AuthenticationServer-B for aUser's credentials
AuthenticationServer-B does not recognize aUser
AuthenticationServer-B contacts AuthenticationServer-A and requests
credentials for aUser
AuthenticationServer-A returns the proper credentials and...
well, you get the picture....
The idea here is that Kerberos by itself is not an authentication
service. It is a mechanism which can be used to develop such a service.
I would assume that all the AuthenticationServers might use Kerberos to
share info between them, and that all the Users might use Kerberos to
authenticate themselves to the AuthenticationServers. Of course, there is room
for more and less robust mechanisms as well, depending on the publisher's needs.
There needs to be a major infrastructure of authenticating and authorizing
capabilities on the Internet to support "publishing." It is not simply a
question of client/server (consumer/producer) because the model does not scale.
> > 3) It's bad policy for users to get into the habit of entering their
> > passwords into programs other than passwd, kinit and login.
> I cannot think of any other reasonable solution with the current
> technology (and I'm not interested in rolling my own).
Ahhhh... but I am. <smile> O'Reilly is hoping to take a lead here, and
we are actively developing an document which outlines the problems and proposes
a solution. We are also developing a testbed application, and will ultimately
make this available to other publishers and the network at large.
Anyone interested in particpating, (at this point, in a discussion, but
perhaps in the beta-release), should drop me a line.
</rr>