test

GSS-API のプログラミング

資格

資格とは、プリンシパル名に対するアプリケーションの要求の証明を提供するデータ構造です。アプリケーションは資格を使用して、ID を確立します。資格はプリンシパルの「識別バッジ」であると考えることもできます。つまり、人、マシン、またはプログラムが本当に要求したとおりのプリンシパルであるかどうか、また多くの場合は、どのような特権を持っているかを証明する情報の集合です。

GSS-API 自身は資格を提供しません。資格は、GSS-API 関数が呼び出される前に、GSS-API の下にあるセキュリティ機構によって作成されます。たとえば、多くの場合、ユーザーはシステムにログインするときに資格を受け取ります。

1 つの GSS-API 資格は単一のプリンシパルだけに有効です。単一の資格は、その単一のプリンシパルに対して複数の (つまり、機構ごとに作成される) 要素を持つことができます。図 1–7 を参照してください。つまり、複数のセキュリティ機構を持つ 1 台のマシン上で獲得された資格は、それらの機構のサブセットだけを持つマシンに転送されるときに有効です。GSS-API は gss_cred_id_t 構造体を通じて資格にアクセスします。この構造体のことを「資格ハンドル」と呼びます。資格はアプリケーションでは意識する必要はありません。ユーザーは、与えられた資格の詳細を知っている必要はありません。

図 1–7 汎用的な GSS-API 資格

Graphic

資格には 3 つの形式があります。

資格の獲得

セキュリティコンテキストが確立できるようになるまでに、サーバーとクライアントはそれぞれの資格を獲得する必要があります。獲得後、資格は有効期間が満了するまで何度も使用できます。資格が満了したときは、もう一度資格を獲得し直す必要があります。クライアントが使用する資格とサーバーが使用する資格とでは、その有効期間が異なる場合があります。

GSS-API ベースのアプリケーションは、次の 2 つの方法のどちらかで資格を獲得します。

ほとんどの場合、コンテキスト起動側 (クライアント) はログイン時に資格を受け取るため、gss_acquire_cred() を呼び出すのはコンテキスト受け入れ側 (サーバー) だけです。したがって、コンテキスト起動側は通常、デフォルトの資格だけを指定します。コンテキスト受け入れ側は gss_acquire_cred() を使用せずに、デフォルトの資格を使用することもできます。

起動側の資格は、他のプロセスに対してその ID を証明します。一方、受け入れ側は、セキュリティコンテキストを受け入れるための資格を獲得します。ここでは、クライアントがサーバーに ftp 要求を行う場合を考えます。クライアントはログイン時からすでに資格を持っています。そして、クライアントがコンテキストを起動しようとすると、GSS-API は自動的にその資格を取り出します。しかし、サーバープログラムは要求されたサービス (ftp) の資格を明示的に獲得します。

次に、gss_acquire_cred() の構文を示します。

例 1–5 


OM_uint32 gss_acquire_cred (
OM_uint32         *minor_status,
const gss_name_t  desired_name,
OM_uint32         time_req,
const gss_OID_set desired_mechs,
gss_cred_usage_t  cred_usage,
gss_cred_id_t     *output_cred_handle,
gss_OID_set       *actual_mechs,
OM_uint32         *time_rec)

minor_status

実際の機構が返す状態コード。

desired_name

資格を獲得すべきプリンシパルの名前。上記例では「ftp」です。この引数は gss_import_name() で作成されます (名前を参照)。

desired_name を GSS_C_NO_NAME に設定した場合、汎用の資格が戻されます。つまり、GSS-API のコンテキスト起動ルーチンとコンテキスト受け入れルーチンは資格に関してデフォルトの動作を使用します。言い換えると、gss_acquire_cred() に GSS_C_NO_NAME を渡すと、gss_init_sec_context() または gss_accept_sec_context() にデフォルトの資格要求 (GSS_C_NO_CREDENTIAL) を渡したときと同じ資格が戻ります。詳細は コンテキストの起動 (クライアント) と コンテキストの受け入れ (サーバー) を参照してください。

time_req

資格が有効であるべき時間 (秒)。GSS_C_INDEFINITE を指定すると、最大の可能な有効期間を要求することができます。

desired_mechs

アプリケーションがこの資格で使用したい実際の機構の集合。これは gss_OID_set データ構造体であり、それぞれが適切な機構を表す 1 つまたは複数の gss_OID 構造体を持ちます。可能な限り、GSS_C_NO_OID_SET を指定して、GSS-API からデフォルトのセットを取得してください。

cred_usage

この資格をどのように使用するかを示すフラグ。コンテキストを起動する場合は GSS_C_INITIATE、コンテキストを受け入れる場合は GSS_C_ACCEPT、または両方の場合は GSS_C_BOTH に設定します。

output_cred_handle

この関数から戻される資格ハンドル。

actual_mechs

この資格で使用できる機構のセット。どの機構であるかを知る必要がない場合は、NULL に設定します。

time_rec

資格が実際に有効である時間 (秒)。時間が重要でない場合は、NULL に設定します。

正常に終了した場合、gss_acquire_cred() は GSS_S_COMPLETE を戻します。有効な資格を戻すことができない場合、gss_acquire_cred() は GSS_S_NO_CRED を戻します。他のエラーコードについては、gss_acquire_cred(3GSS) のマニュアルページを参照してください。資格を獲得する例については、資格の獲得(プログラムリストは server_acquire_creds()) を参照してください。

gss_add_cred() は gss_acquire_cred() と似ています。しかし gss_add_cred() は、既存の資格に基づいて新しい資格ハンドルを作成するか、既存の資格に新しい資格要素を追加することを、アプリケーションに可能にします。GSS_C_NO_CREDENTIAL を既存の資格として指定した場合、gss_add_cred() はデフォルトの動作に基づいて新しい資格を作成します。詳細は、gss_add_cred(3GSS) のマニュアルページを参照してください。