Hello Michael,

> Well - I think one point needs to be discussed here: What do we accept to be 
> configured "statically" in the config-files:

do you mean on the client? Then the answer is clear - nothing.
Coda is global and you never know which Coda realms are going to be contacted
from some client.

> But who cares for the mapping string<->coda-number? Is it the users 
> responsibility to do `clog as <USERNAME>`? What happens, if <USERNAME> is 
> omitted, is the users numeric id taken for the mapping or the name? This is 
> something I have not yet understood concerning the current implementation...

Unix system's clog process' numeric uid has no relation to the Coda identity
which is going to be authenticated. It is the name which matters.
It is handy when it happens to coincide with the local user account name,
but it cannot be ever guaranteed - for the same reason as above - a client
can never know about all Coda realms and their identity names (and name
choice policies)

> This is really nice, but there must be some default for all that - users _are_ 
> lazy, they do want some kind of plug & play... This is the reason for all of 

Of course.
What I do in the morning is just plain
 clog
and it asks me for passwords for Chalmers DCE for my own realm
and even also Coda password for CMU realm, acquiring tokens for both.
(well, usually I do not use CMU realm so I do not bother acuiring tokens,
but the functionality is there)

> my talking - _how to determine the default_ ? People probably don't know 
> where they got (to stick to the example) their kerberos-tgt from, may it be 
> andrew.cmu.edu or cs.cmu.edu - doing more behind the scenes might help a lot, 

All that Kerberos cached credentials stuff is not so interesting for Coda
as default tgts live for say 10 hours, but tokens live for 25.
With other words we cache it longer that Kerberos usually does.
In the current "new" code I do not use tgts at all - 
it is rather straightforward to add if somebody would feel the necessity.

> although it should still be possible to specify that exactly on demand (i.e. 
> on the command-line).

Exactly. It is.

> >    2. locate the corresponding services
> >       "kdc of the DCE cell and if it is run on the standard port"
> >       "the host which accepts passwords over tcp connection and the port
> > number"
> But how to do that, e.g. should the kerberos-realm be explicitly specified or 
> possible values be discussed behind the scenes? Or should one simply use the 
> defaults provided by the service-specific config-files?

It is the contents of the proposed new
"Coda realm authentication advertisement service".
It is just a text stream/file with simple format, capable of advertising
any necessary host lists, ports, options and similar,
for every authentication method and authority.
Kerberos kdcs are present there too.
 
> > 3. possibly talk some other protocol(s) to fetch the resulting Coda 
> > token "rpc2 to send a Kerberos ticket and get a Coda token"
> Of what importance is that here? Might there be any problems if you used one 
> or the other? Isn't that only implementation-specific or are there 
> dependencies?

You can use only a protocol supported by the corresponding realm.
If the realm hands out tokens over an ssl connection, you have to use ssl.
If it is running a traditional auth2 daemon which talks rpc2, the client
has no choice except talking rpc2. If there are several possibilities,
then of course the client can choose either one.

There have been two scenarios:
 - set up an rpc2 connection to an auth2 daemon, prove the identity
   over that connection [using the password], then get a token via rpc2
 - acquire a kerberos service ticket for the authentication service,
   set up an rpc2 connection to an auth2 daemon, prove the identity
   over that connection [using the ticket], then get a token via rpc2

Now there is one more way:
 - make an ssl connection to the authentication server and directly
   get a ticket for an anonymous user
   (solves the server authentication problem for anonymous access)

The previous one can be[come] a special case of a general though questionnable:
 - make an ssl connection to the authentication server, supply
   an identity name and password over the connection, get the token
   over the same connection
   (would let us use authentication databases like NIS)

We could think about other and different ways of
 - contacting an authentication server
 - convincing ourselves that the server is the right one
 - convincing the server we are who we pretend to be
 - getting a token

I call a certain choice of those - an "authentication method".
So I'm implementing corresponding modules for authentication server (auth2)
and authentication client (clog).

Then different auth methods can happen to use the same auth databases
in a certain realm. Say I'd hand out tokens based on check against
Chalmers DCE cell via rpc2 - or ssl - or snail mail :)
In that case it is the client's responsibility to pick one of the methods,
but it is the server who has to talk about their availability.

Each authentication database (like Chalmers DCE cell) I call an "authority".
Each authority is identified in the context of a certain Coda realm
by a name, an "authority label". That gives us Coda identities like
pin/dce_at_xyz.chalmers.se
where "dce" is authority label, chosen by the Coda realm "xyz.chalmers.se"
administrator, and it refers, possibly, to Chalmers DCE cell.
"pin" is in that case a DCE account.

So, "dce" has sence in context of "xyz.chalmers.se"
and "pin" has sence in context of "dce"
the combination of all three is guaranteed to be unique in the whole world
as long as realms are located via DNS.

> >    4. locate the corresponding resources
> >       "which host and port that rpc2 daemon is running on"
> But that's only of importance on the server side, or have I understood 
> something completely wrong?

It is information the authentication _client_ desperately needs.

> What about using nsswitch on the auth2-server-side? This would provide a 
> generic interface for user-management (and you are still independet of any 
> existing passwd etc. (I would love to have an entry like "coda: files 
> ldap"...) 

What do you mean by "generic interface for user management"?
Coda identities management has little in common with
account management of a Unix system.

Would you make it clear
 - which database are you going to make available through NSS?
 - which programs would use it?
 - through which API?

The only thing Coda is dependent on is a list of groups,
while a group can contain other groups or identities.
This database is nice to be able to read from somewhere,
but I doubt nsswitch is in any way a suitable tool.

[note, in general a Coda realm does not need a database over
identities! It is groups and acls who decide which identities
are usable]

Nsswitch is an interface between existing API like getpw*()
and arbitrary carriers of the corresponding information.
It means that the different libnss_* modules have knowledge about
the APIs they implement. So no "coda: files nis ldap"
would be possible until we rewrite all of the corresponding service modules
so that they know about "coda: " lookup functions.

Then why would we bother replacing the standard libraries with our extended
ones? Even if we want different backends for our database(s), we would just
write them and use, without pretending to force them into an existing standard
(libnss_* APIs) - just to be able to share the configuration file with
other totally independent services?!

nsswitch has some sence when _one_ API is using _several_ databases
and then you have _one_ place to configure where it picks them.
SUN once made a choice of putting _several_ APIs into the same config file
and into each of libnss_* libraries - let us avoid doing that mistake again.

May be you meant "passwd: coda files nis ..." ?
Then - no way, again. Coda has no notion of a Unix account and hence
its identity information can not be expressed in terms of a passwd entry.
Even if you want to map/fake the information, it is the internal business
of a Unix system administration, in which way to do that mapping,
and from which Coda realms.
Rather you'd want it vice versa, populate a Coda realm with identities for most
of some Unix system's accounts - but it's another story, where passwd
and group databases can be of help - but most probably still not the same
as Coda groups and identities.

> But how to get to appropriate defaults? 

You do not need them as long as you supply the identity,
like xyz/abc_at_realm.some.where - that's all.

If you are too lazy to type, put it in a nice dot-file and clog will
find it.

clog even tries to guess some things when you do not supply them.
(like guesses that you apply for the same account names anywhere,
and hence your Coda identity might be the same as the local account name,
and uses "/default" authority name which should exist everywhere).

Anything else is supplied by the corresponding Coda realm, which you have
to supply explicitely, on the command line or in a user config file...

> But how can a coda-client/server get information, e.g. wheter it is using ssl 
> or not (even worse: ipsec...)

The server advertises which authentication methods with which parameters
can be used (and usually exactly one per authentication authority, easy
for the client to make a choice :)

> How may one get the correct config - would it be possible to get all that 
> from e.g. the DNS? (coda realm seems to be the problem, the matching servers, 
> of course, are a lot easier to fetch...)

You do the standard Coda auth servers discovery, via DNS SRV records,
falling back to DNS A records - and then just make tcp connections
to the found hosts to the found (or standard) ports and pick the host
who answers first.
The data you get contains all information about authentication
authorities and authentication methods with corresponding parameters
for the given Coda realm.

All of that is done by clog and seems to work pretty well.
It is even backward compatible with sites without that service,
assuming coda password authentication with standard parameters.

Thanks for your suggestions and questions Michael!

Regards,
--
Ivan