セキュリティコンテキストを確立し、保持するには、次の 2 つのタイプの主体名が必要です。
サーバーの主体名は、通常、「service@host」の形式の NULL で終わる ASCII 文字列で指定します。たとえば、 nfs@eng.acme.com のように指定します。
クライアントがセキュリティコンテキストを作成する時には、この形式でサーバーの主体名を指定します。 コンテキストの作成 を参照してください。 同様にサーバーは、表示する主体名を設定する必要がある場合は、rpc_gss_set_svc_name () を使用します。この関数は、引数としてこのフォーマットの主体名をとります。
サーバーが受信するクライアントの主体名は、rpc_gss_principal_t 構造の形式をとります。それは、使用するメカニズムによって決定される、特定の長さを持つ隠されたバイト列になります。この構造については、rpcsec_gss(3NSL) のマニュアルページを参照してください。
サーバーは、起動時に、そのサーバーを表わす主体名を指定する必要があります 。1 つのサーバーが、複数の主体として機能する場合もあります。次のプログラムで示すように、 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(3NSL) のマニュアルページを参照してください。
サーバーは、クライアントの主体名で稼動する必要があります。 たとえば、クライアントの主体名をアクセス制御リストと比較するため、またはクライアントの UNIX 資格が存在する場合にはそれを検出するために必要です。このような主体名は、rpc_gss_principal_t 構造体ポインタとして保存されます。 rpc_gss_principal_t についての詳細は、rpcsec_gss(3NSL) のマニュアルページを参照してください。 サーバーが、受信した主体名を既知のエンティティの名前と比較する必要がある場合、サーバーは、この形式で主体名を生成する必要があります。
次のプログラムで示すように、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(3NSL) のマニュアルページを参照してください。
主体名は、free() ライブラリコールを使用して解放します。