GSS-API における資格の操作

「資格」とは、主体名に対するアプリケーションの要求の証明を提供するデータ構造です。アプリケーションは、資格を使って自身の大域アイデンティティーを確立します。さらに資格は、エンティティーの権限を確認する目的で使用される場合もあります。

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

ある特定の GSS-API 資格は単一の主体に対してのみ有効です。単一の資格には、その主体に対する要素が複数個含まれる可能性があります。それらの要素は機構ごとに 1 つずつ作成されます。複数のセキュリティー機構を備えたマシン上で獲得した資格は、それらの機構のサブセットを備えたマシンに転送された場合に有効になります。GSS-API は gss_cred_id_t 構造体を通じて資格にアクセスします。この構造体のことを「資格ハンドル」と呼びます。資格はアプリケーションに対して不透明です。したがって、アプリケーションは与えられた資格の詳細を知る必要はありません。

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

• GSS_C_INITIATE – セキュリティーコンテキストの起動のみを行うアプリケーションを識別します

• GSS_C_ACCEPT – セキュリティーコンテキストの受け入れのみを行うアプリケーションを識別します

• GSS_C_BOTH – セキュリティーコンテキストの起動と受け入れを行えるアプリケーションを起動します

GSS-API における資格の獲得

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

GSS-API ベースのアプリケーションが資格を獲得する方法には、次の 2 つがあります。

• gss_acquire_cred() または gss_add_cred() 関数を使用する方法

• コンテキスト確立時にデフォルトの資格を示す値 GSS_C_NO_CREDENTIAL を指定する方法

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

クライアントの資格は、そのクライアントの身元をほかのプロセスに対して証明します。サーバーが資格を獲得すると、セキュリティーコンテキストの受け入れが可能になります。したがって、クライアントがサーバーに ftp 要求を送る場合、そのクライアントはログイン時からすでに資格を獲得している可能性があります。クライアントがコンテキストを起動しようとすると、GSS-API は自動的にその資格を取得します。しかし、サーバープログラムは要求されたサービス (ftp) の資格を明示的に獲得します。

gss_acquire_cred() が正常終了すると、GSS_S_COMPLETE が返されます。有効な資格を返せない場合は、GSS_S_NO_CRED が返されます。その他のエラーコードについては、gss_acquire_cred(3GSS) のマニュアルページを参照してください。使用例については、第 6 章の「資格の獲得」を参照してください。

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