>>>>> "Ivan" == Ivan Popov <pin_at_medic.chalmers.se> writes:

    Ivan> You still manage authorization (of course) but can use
    Ivan> existing authentication services transparently, for any
    Ivan> service being offered to the end-user.

Sure, but what good do these authentications do?  AFAICT the main
purpose would be to track behavior so you can monitor the people you
are authenticating.  If the downstream host is going to provide
different privileges to different IDs authenticated by the same
service, they effectively need to create accounts for them anyway.

So authentication really is about protecting the authenticator, and
(given the real-time tracking ability that computers give) has
worrisome implications for privacy if you ask me.

    >> We already have Kerberos and SSH which have some of these
    >> features;

    Ivan> Which features do you mean they have?

    Ivan> Let's see. SSH is not an authentication service, it provides
    Ivan> a remote login service and a remote file access service.

I would say SSH _is_ an authentication service that happens to also
provide remote login and remote file access as typical applications.

    Ivan> Have you any way to let your sshd securely use Chalmers DCE
    Ivan> account database? Any other database you do not have
    Ivan> administrative control over?

I can't speak for Chalmers DCE, but the answer is "yes" for the XEmacs
CVS repository.

    Ivan> No, you'd need to get an account for your host, and you
    Ivan> won't.

    Ivan> How would you distinguish between "pin:....." entry in you
    Ivan> local passwd file if it happened to be present there, and my
    Ivan> "pin" account at Chalmers?

Simple.  The SSH keys are different.  Whether it counts as "secure" by
your standards or not, I can't say, but the system we use for XEmacs
CVS is to have a common account all of whose entries except one (the
account administrator's) are of the form

environment="CVSUSER=<xemacs-cvs-id>",
command="cvs"
<keyinfo>
<real email address>

Assuming no bugs in SSH, this authenticates the person with <keyinfo>
as having the identity corresponding to <real email address>, and
restricts them to accessing the cvs server.  People I trust to know
what they're talking about say this is about as secure as you can get
in an open source project.

Note that if you change the command to /bin/true, this is effectively
pure authentication.

Now, an important point is that the host is not owned or operated by
the XEmacs project, but the XEmacs admins (who have access to the
shell from this account) can add keys at their discretion.

There are some details that really should be fixed (for example, sshd
should log the key used for authentication, which it currently doesn't).

    Ivan> Then, to use it securely you need a service/host account in
    Ivan> each Kerberos realm you want to authenticate against... it
    Ivan> probably would hinder Kerberos realm adminitrators from
    Ivan> offering authentication services in large scale... :)

True, but I would not be willing to do any authorization based merely
on authentication.  So in the end you need to keep lists.  Those lists
might as well be of SSH public keys as of anything else, especially
s