At the present time, OpenAFS does not have a single authentication library.
Instead, the auth package contains the old kaserver/kerberos-iv authentication
routines and all of the kerberos-v and krb524 translation code is replicated
in every tool that performs token acquisition.

At the 2011 hackathon in Pittsburgh the need for a consolidated authentication
library was discussed.  It is needed to reduce code complexity and make it
easier for third party credential acquisition tools to obtain support for
rxgk.  The below text outlines a design proposal which is in need of a
developer to turn it into a reality.

Thanks to Simon Wilkinson (Your File System, Inc.) for the design.

---

Overview

The plan is to create a single library for gaining afs tokens on Unix and
Windows, which combines together the functionality of the various existing
aklog and klog commands. The library should be capable of acquiring kas and
krb5 (both natively, and through a 524 converter) for rxkad, and of being
extended to support other mechanisms such as rxgk in the future. It should be
possible to gain tokens using a password, credentials held within a local
credentials cache, or those held within a krb5 keytab. It should also be
possible to use the existing aklog 'kimpersonate' functionality to produce
credentials using a forged service ticket.

This library will be used to implement a single binary which can perform
either password driven (klog style) or password free (aklog style) token
acquisition.  On Windows, this library would later be used to replace the
functionality in the NetIdMgr OpenAFS credentials provider.

Library Design

Whilst in the initial implementation, the library will be purely used by one
or more command line tools (see below), the intention is that it will also be
used by the proposed token renewing functionality for afsd
(http://gerrit.openafs.org/#change,4063), so it has to be capable of being
used as a proper library (good constructors, destructors, no resource leaks,
and stable over a long lived process).

The library is structured to be as extensible as possible. There is a token
acquisition context which contains all of the necessary configuration
information to be able to acquire tokens, and a single function which takes
that context and acquires the token which is the best fit for the incoming
request. This function is reusable over a particular configuration, so it can
be used by a long running process to easily renew credentials.

Here's a rough draft of how such an interface could be structured ...

/* Create a new acqusition context */
auth_gettoken_ctx *
auth_GetToken_BuildContext(void);

void
auth_GetToken_DestroyContext(auth_gettoken_ctx **ctx);

typedef enum {
    AUTH_GETTOKEN_METHOD_PASSWORD,
    AUTH_GETTOKEN_METHOD_KEYTAB,
    AUTH_GETTOKEN_METHOD_CREDENTIALS
} auth_InitialMethod;
    
/* Add an initial credential acquistion method */
int
auth_GetToken_EnableInitialMethod(auth_gettoken_ctx *ctx,
                  auth_InitialMethod method);

typedef enum {
    AUTH_GETTOKEN_METHOD_RXKAD_K5,
    AUTH_GETTOKEN_METHOD_RXKAD_K524,
    AUTH_GETTOKEN_METHOD_RXKAD_KAS,
    AUTH_GETTOKEN_METHOD_RXGK
} auth_GetTokenMethod;

/* Add a mechanism for acquiring a token for a particular type */
int
auth_GetToken_EnableTokenMethod(auth_gettoken_ctx *ctx,
                auth_GetTokenMethod method);

typedef enum {
    AUTH_GETTOKEN_CONFIG_PRINCIPAL,
    AUTH_GETTOKEN_CONFIG_KEYTAB,
    AUTH_GETTOKEN_CONFIG_PASSWORD,
    AUTH_GETTOKEN_CONFIG_LIFETIME
    AUTH_GETTOKEN_CONFIG_REALM,
    AUTH_GETTOKEN_CONFIG_SETPAG,
    ...
} auth_GetTokenConfigKey;
    
/* Add configuration for a particular key */
int
auth_GetToken_AddConfiguration(auth_gettoken_ctx *ctx,
                   auth_GetTokenConfigKey key,
                   char *value);

int
auth_GetTokens(auth_gettoken_ctx *context,
           struct afsconf_cell *cell,
               int force,
               int setpag);

Command Line Tool Design

The intention is to provide a single command line tool which provides the
functionality of all of the various log tools. This can be done by simply
determining the name that the command is invoked by (aklog or klog), and
setting up the appropriate command parser. The existing additional
functionality of all commands should be preserved (for example, aklog's path
walk function)

Implementation

The best fit within the OpenAFS tree for the new interfaces is the 'auth'
library, ideally as one or more new pieces of source code. It is envisaged
that this new code will replace the current token acquisition implementations
in src/aklog/aklog.c, src/aklog/klog.c, src/kauth/klog.c and
src/kauth/manylog.c with a single source file in src/auth.

The src/aklog/aklog.c file is the best starting point - it has by far the
cleanest architecture, and it should serve as a solid base for this work.

krb524 functionality has been removed from both MIT and Heimdal Kerberos
implementations over the last couple of years.  krb524 will need to be
implemented within the openafs code base.  The OpenVision libkrb524.a can be
used as a starting point for that work.

  https://github.com/krb5/krb5-anonsvn/tree/tags%2Fkrb5-1-3-6-final/src/krb524

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to