With the addition of Kerberos referrals support in MIT Kerberos 1.6, the
hack that we have used for determining when aklog should auto-register a
user a a foreign entity in the pt database no longer works.

When a referral is used the client is handed by the Kerberos library a
service ticket of the form "afs/cell@" instead of "afs/[EMAIL PROTECTED]".
This is because when referrals are used the client does not know the
realm.  If the library stored the service ticket as "afs/[EMAIL PROTECTED]"
then when the application wanted to re-use it, it would not be found in
the cache.  While it might be nice for the Kerberos ticket data
structure to contain both the requested and obtained service principal
names, this would be a backward incompatible change which we are
unlikely to see implemented.

As a result, the client in unable to determine whether the token it has
obtained represents a local or foreign user.  The only way this can be
determined is by asking a server to report back who the user has
authenticated as.

My proposal is to add a new RPC:

struct prwhoami {
  afs_int32 flags;
  afs_int32 id;
  char name[PR_MAXNAMELEN];
}
typedef struct prwhoami prwhoami;

WhoAmI(
  OUT prwhoami *who
) = NNN;

The server will return to the caller the name that would be looked up in
the database plus either the actual assigned AFSID or ANONYMOUSID.

This new RPC is intentionally old-style.  In much the same way that we
will need to add pr_CreateUserEx() in order to support multiple name
types, we will need to add pr_WhoAmIEx() to support multiple name types.

The pr_WhoAmI RPC would be used to solve the pts registration problem as
follows:

* aklog would obtain a token
* make a call to pr_WhoAmI to obtain the name and id from the ptserver
* if the id is ANONYMOUSID then it would proceed to call pr_CreateUser
with the name provided by the server.

Comments?

This is OpenAFS RT ticket 64147
http://rt.central.org/rt/Ticket/Display.html?id=64147

Jeffrey Altman
Secure Endpoints Inc.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to