On Tue, 8 Dec 1998, Neil Dunbar wrote:

> I've just started playing with Coda here. All seems like useful stuff,
> especially when integrated with a Kerberos realm. One thing which
> would be handy though would be the mapping of several names
> onto a single user ID.
> 
> The reason that I thought this would be useful was that many
> Kerberos realms append an instance value to the end of a user
> ID to designate the function of the principal (for example
> "nd/admin" to designate my administrative hat as opposed to
> my regular, joe user hat). Unfortunately, this principal cannot
> be used to log in to Coda, because there isn't a 1-to-1 mapping
> between the Coda user name and the Kerberos principal (and
> you don't really want to be creating multiple UIDs to deal with
> the same person under different principals).

The alias support looks very useful -- especially if multiple different
users are mapped to a single coda identity.  However, I'm tempted to
handle the kerberos behavior a little different.  I don't know if you've
ever used Kerberos with AFS, but one popular way of handling this is to
allow different instances to be different roles, if desired.  For example,
I might want my krbIV instance robert.admin_at_WATSON.ORG to be a member of
the SystemAdministrators group in Coda, but have my normal
robert.*@WATSON.ORG map to the same robert VID in the Coda realm.  As
such, my feeling was that a mapping algorithm of the form:

1) Look for a matching alias, resolve aliases until aliases run out

2) Look for an exact match is found (i.e., robert.admin) for the username,
use that. 

2) If not, look for a match on the principal without the instance (i.e.,
robert.root might just be mapped to robert in the Coda realm) 

3) reject the authentication (there is no matching identity in the Coda
realm) 

The alias mechanism is more general, but in a kerberos environment the
steps 2 and 3 might be useful.  Presumably the equivilent behavior in K5
is robert/... instead (I don't use K5 much so don't have much experience
with common policies for naming of principals/instances).

I'm planning on revamping the kerberos patches for the next release, once
I finish up the last component of the coda-crypto modifications, which
should be after the end of IETF.

Sometime soon (next week?) I should also have a client-side PAM module to
acquire coda tokens based either on the user's password or on a krbIV
credential.  I don't have a KrbV realm lying around, so haven't had a
chance to look into that much yet.  Needless to say, unlike Kerberos, Coda
authentication tokens cannot be used to authenticate users to a client
machine (that is, as a replacement for the password database, etc) as Coda
does not provide user-user or user-service authentication, only user-coda
authentication.

  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/