Re: Behavioural differences in Heimdal and MIT [was: Re: API differences between Heimdal and MIT]

[Buck Huppmann <buckh@pobox.com>]

On Wed, Feb 15, 2006 at 11:52:46AM +0100, Gabor Gombas wrote:

> Maybe the proper solution would be to allow different backends (LDAP,
> RDBMS etc.) for getting the information that is now contained in the
> .k5login file. That would allow completely avoiding file system access
> until the authentication/authorization process has finished.

that's ``thinking outside the box''. actually, MIT's krb5 allows you to
use

[realm]
    EXAMPLE.COM = {
	auth_to_local = DEFAULT
	auth_to_local = RULE:[3:$1,$2,$3,$0](rsyncer,.*,myhostname\..*,MYREALM)s/,.*//
	# if you #define ANAME_DB in src/lib/krb5/os/an_to_ln.c and get
	# it to link
	auth_to_local = DB:/path/to/Berkeley-DB
    }
(although only in the config for the default realm and [except for
the DEFAULT rule] applies to authenticated principals from any realm,
which i think is broken. j)

> 
> I see two possible approaches:
> 
> 1. Provide a callback that can be used to replace just the reading of
>    the .k5login file, leaving the content parsing/decision making in
>    Heimdal, or

interesting idea. of course, then the temptation is for the library
to unload more features (credential storage) onto the app . . .

> 2. Moving the decision making completely to the callback. This is more
>    general but applications may need to implement more logic than with
>    the first approach.

another mech is to make more of the auth_to_local stuff configurable.
maybe adding
	auth_to_local = PROGRAM:timeout=5s:/something/that/knows/who's/authorized/for/what
	auth_to_local = PROGRAM:timoeut=5s:/something/that/can/use/a/delegated/cred/to/access/an/AFS/volume/for/the/user
	auth_to_local = PROGRAM:timeout=5s:/something/that/asks/a/dedicated/mapping/service
capabilites, say. this might need to be an appdefault, since different
programs might need different program flavors or different args, depend-
ing on their operating uid

getting completely outside the box, the application needn't even call
krb5_kuserok() and just do what it thinks is right, given the auth-
enticated principal. i think that's probably the right thing to do,
since kerberos is an authentication system, after all, not an author-
ization system. (i am still waiting for somebody to invent the author-
ization system . . . )