セキュリティコンテキストを確立および保守するには、2 種類のプリンシパル名が必要です。
サーバープリンシパル名は常に NULL で終わる ASCII 文字列として、service@host の形式で指定されます (たとえば、nfs@eng.acme.com)。
クライアントがセキュリティコンテキストを作成するときは、サーバープリンシパル名を上記の形式で指定します (「コンテキストの作成」を参照)。同様に、サーバーが表現するプリンシパル名を設定する必要がある場合は rpc_gss_set_svc_name() を使用します。この関数は、上記の形式のプリンシパル名を引数として取ります。
(サーバーが受信する) クライアントプリンシパル名は rpc_gss_principal_t 構造体形式から取れます。これは、使用される機構によって決まる、カウントと不定バイト文字列です。この構造体については、rpcsec_gss(3N) のマニュアルページを参照してください。
サーバーには、起動時、そのプリンシパル名を設定しておく必要があります (サーバーは複数のプリンシパルとして動作する可能性があります)。rpc_gss_set_svc_name() を使用すればプリンシパル名が設定されます。
char *principal, *mechanism; u_int req_time; principal = "nfs@eng.acme.com"; mechanism = "kerberos_v5"; req_time = 10000; /* 資格が有効である時間 */ rpc_gss_set_svc_name(principal, mechanism, req_time, SERV_PROG, SERV_VERS);
Kerberos は req_time パラメータを無視します。他の認証システムはこのパラメータを使用できます。
詳細は、rpc_gss_set_svc_name(3N) のマニュアルページを参照してください。
サーバーはクライアントプリンシパル名を操作できる必要があります。たとえば、クライアントプリンシパル名をアクセス制御リストと比較するときや、そのクライアントの資格が存在するかどうか UNIX 資格を検索するときなどです。このようなプリンシパル名は rpc_gss_principal_t 構造体ポインタの形式で保存されます (rpc_gss_principal_t についての詳細は、rpcsec_gss(3N) のマニュアルページを参照)。サーバーが受信したプリンシパル名を既知のエンティティの名前と比較したい場合、受信した形式でプリンシパル名を生成できる必要があります。
rpc_gss_get_principal_name() の呼び出しでは、ネットワーク上でユーザーを一意に識別するためのいくつかのパラメータを入力する必要があり、プリンシパル名を rpc_gss_principal_t 構造体ポインタとして生成します。
rpc_gss_principal_t *principal; rpc_gss_get_principal_name(principal, mechanism, name, node, domain); . . .
次に、rpc_gss_get_principal_name() の引数を示します。
principal は、設定する rpc_gss_principal_t 構造体へのポインタです。
mechanism は使用するセキュリティ機構です (生成されるプリンシパル名は機構に依存します)。
name はユーザー名またはサービス名です (joeh や nfs など)。あるいは、ユーザー定義のアプリケーション名にもなります。
node は UNIX マシン名などです。
domain は DNS、NIS、または NIS+ のドメイン名、あるいは Kerberos レルムなどです。
各セキュリティ機構には異なる識別パラメータが必要です。たとえば、Kerberos V5 には、ユーザー名と (オプションとして) 修飾されたノードとドメイン名 (Kerberos の用語では、ホストとレルムの名前) が必要です。
詳細は、rpc_gss_get_principal_name(3N) のマニュアルページを参照してください。
プリンシパル名を解放するには、free() ライブラリを呼び出します。