Coda File System

identities and authentication methods (was: More bugs in krb5.c!?)

From: Ivan Popov <pin_at_medic.chalmers.se>
Date: Tue, 4 May 2004 16:20:40 +0200
On Fri, Apr 23, 2004 at 02:49:40PM +0200, Ivan Popov wrote:

> 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.

I have looked at my own notes and at the coressponding modular clog
implementation. In fact, it was done differently.

The client asks the server about all details of <name>/<authority-label>
and it implies one and only one method to be used for authentication.

It did not support using several methods against the _same_ authentication
database (seldom useful but possible). Now it does :)
The realm admin may choose additional authentication method labels
relating to the same authority label. The "user seen" syntax will be
in that case
 <name>/<authoritylabel>[-<methodlabel>]@<codarealm>
which would relate to <name>/<authoritylabel> identity anyway,
independently of the method chosen.
Normally it would not be needed but can be useful under special circumstances.

It may be worth to point out that it is the Coda realm discretion to hand out
tokens containing something related to the <name>/<authority> used for the
authentication. Technically speaking it does not _have_ to.
Nevertheless it should be a sane administrative decision to do so - as it is
a clean namespace usable by both authentication and authorization.
Any extra layer of mapping would make it confusing without giving any real
advantage.
ACLs and groups are the right tool - powerful enough to express most
of the authorization policies to be imagined.

As different ways to talk to the same database may have different
security properties, sometimes we should not treat them as equal.
In that case a natural solution would be to assign different authority labels
and consequently different identities, even if the underlying database
and the possible corresponding physical user are the same.

Again, thanks for the discussion Michael!

Regards,
--
Ivan
Received on 2004-05-04 10:25:58