Oracle® Solaris 11 セキュリティー開発者ガイド

印刷ビューの終了

更新: 2014 年 7 月
 
 

SASL ライブラリの基本

SASL ライブラリは libsasl と呼ばれます。libsasl は、正しく記述された SASL コンシューマアプリケーションがシステム上で利用可能な任意の SASL プラグインを使用できるようにするためのフレームワークです。プラグインという用語は、SASL にサービスを提供するオブジェクトを指すために使用されます。プラグインは libsasl の外部に存在します。SASL プラグインを使用すれば、認証およびセキュリティー保護、名前の標準化、および補助プロパティー (パスワードなど) の検索を行えます。暗号化アルゴリズムは libsasl 内にではなくプラグイン内に格納されます。

libsasl は、コンシューマ (アプリケーションとライブラリ) に対してアプリケーションプログラミングインタフェース (API) を提供します。サービスプロバイダインタフェース (SPI) は、プラグインが libsasl にサービスを提供するために用意されたものです。libsasl はネットワークやプロトコルを認識しません。したがって、クライアントとサーバー間でデータの送受信を行うのは、アプリケーションの責任です。

SASL はユーザーに対して 2 つの重要な識別子を使用します。「認証 ID」(authid) は、ユーザーを認証するためのユーザー ID です。認証 ID は、システムへのアクセスをユーザーに許可します。承認 ID (userid) は、ユーザーが特定のオプションの使用を許可されているかどうかを検査する際に使用されます。

SASL クライアントアプリケーションと SASL サーバーアプリケーションは、共通の SASL メカニズムとセキュリティーレベルの折衝を行います。 通常の場合、SASL サーバーアプリケーションが、自身が受け入れ可能な認証メカニズムのリストをクライアントに送信します。その後、SASL クライアントアプリケーションは、自身の要求にもっとも合う認証メカニズムを決定できます。この時点から、両者で合意した認証メカニズムに基づいて、「クライアントとサーバー間における一連の SASL 認証データの交換」として認証が実行されます。この交換は、認証に成功または失敗するか、あるいはクライアントかサーバーによって処理が中止されるまで継続されます。

認証処理中に、SASL 認証メカニズムはセキュリティー層の折衝を行えます。セキュリティー層が選択された場合、SASL セッションが継続する限りその層を使用する必要があります。

SASL アーキテクチャー

次の図に、SASL の基本アーキテクチャーを示します。

図 7-1  SASL アーキテクチャー

image:クライアントとサーバーの関係において SASL の主要構成要素が協調動作する様子を示しています。

クライアントアプリケーションとサーバーアプリケーションはそれぞれ、libsasl のローカルコピーに対して SASL API 経由で呼び出しを行います。libsasl は、SASL サービスプロバイダインタフェース (SPI) 経由で SASL メカニズムと通信します。

セキュリティーメカニズム

    セキュリティーメカニズムプラグインは、libsasl にセキュリティーサービスを提供します。セキュリティーメカニズムが提供する一般的な機能のいくつかを、次に示します。

  • クライアント側での認証

  • サーバー側での認証

  • 整合性 (転送データが変更されていないことの検査)

  • 機密性 (転送データの暗号化と復号化)

SASL セキュリティー強度係数 (SSF)

SSF (セキュリティー強度係数) は、SASL 保護の強さを示します。メカニズムがセキュリティー層をサポートしている場合、クライアントとサーバーは SSF の折衝を行います。SSF の値は、SASL 折衝開始前に指定されたセキュリティープロパティーに基づいて決められます。折衝で 0 以外の SSF が決定された場合、認証完了時にクライアントとサーバーの両方でそのメカニズムのセキュリティー層を使用する必要があります。

    SSF は次のような整数値で表現されます。

  • 0 – 保護なし。

  • 1 – 整合性検査のみ。

  • >1 – 認証、整合性、および機密性のサポート。その数値は暗号化の鍵の長さを表します。

機密性と整合性の処理はセキュリティーメカニズムによって実行されます。libsasl はそれらの要求を調整する役割を果たします。


注 - SASL クライアントは折衝時に、最大の SSF を持つメカニズムを選択します。ただし、実際に選択された SASL メカニズムはその後、それよりも低い SSF の折衝を行う可能性があります。

SASL における通信

アプリケーションは libsasl API 経由で libsasl と通信します。libsasl はアプリケーションによって登録されたコールバックを介して追加情報の要求を行えます。アプリケーションがプラグインを直接呼び出すことはなく、必ず libsasl 経由でプラグインを呼び出します。プラグインは通常、libsasl フレームワークのプラグインを呼び出します。すると、フレームワークがアプリケーションのコールバックを呼び出します。SASL プラグインはアプリケーションを直接呼び出すことも可能です。ただしその際、アプリケーションは、プラグインからの呼び出しと libsasl からの呼び出しを区別できません。

    コールバックは、次のようにさまざまな分野で役に立ちます。

  • libsasl はコールバックを使用することで、認証を完了するのに必要な情報を取得できます。

  • libsasl コンシューマアプリケーションはコールバックを使用することで、プラグインや構成データの検索パスを変更したり、ファイルを検証したり、さまざまなデフォルト動作を変更したりできます。

  • サーバーはコールバックを使用することで、承認ポリシーを変更したり、異なるパスワード検証方式を提供したり、パスワード変更情報を取得したりできます。

  • クライアントとサーバーはコールバックを使用することで、エラーメッセージの言語を指定できます。

アプリケーションが登録するコールバックには、 大域とセッションの 2 種類があります。さらに、libsasl では多数のコールバック ID が定義されており、それらの ID を使ってさまざまな種類のコールバックを登録できるようになっています。特定の種類のコールバックが登録されていない場合、libsasl はデフォルトの動作を実行します。

セッションコールバックは大域コールバックをオーバーライドします。ある ID に対してセッションコールバックが指定された場合、そのセッションでは大域コールバックは呼び出されません。コールバックによっては、大域でなければなりません。これは、それらのコールバックがセッションの外側で呼び出されるためです。

    次のような処理は大域コールバックにする必要があります。

  • プラグイン読み込み時の検索パスの決定

  • プラグインの検証

  • 構成データの検索

  • エラーメッセージのロギング

  • libsasl またはプラグインに関するその他の大域構成

特定の SASL コールバック ID の SASL コールバックとして、NULL コールバック関数を登録できます。NULL コールバック関数は、必要なデータを提供する準備がクライアント側に整っていることを示します。SASL コールバック ID には必ず、接頭辞 SASL_CB_ が付いています。

SASL が提供する次のコールバックは、クライアントまたはサーバーで使用できます。

SASL_CB_GETOPT

SASL オプションを取得します。オプションを設定すると、libsasl(3LIB) とその関連プラグインの動作が変更されます。クライアントまたはサーバーで使用できます。

SASL_CB_LOG

libsasl とそのプラグインに対するロギング機能を設定します。デフォルトの動作は「syslog の使用」です。

SASL_CB_GETPATH

SASL プラグイン検索パスのコロン区切りリストを取得します。

    デフォルトの SASL プラグイン検索パスは次のとおりです。

  • 32 ビット SPARC アーキテクチャー: /usr/lib/sasl

  • 32 ビット x86 アーキテクチャー: /usr/lib/sasl

  • 64 ビット SPARC アーキテクチャー: /usr/lib/sasl/sparcv9

  • x64 アーキテクチャー: /usr/lib/sasl/amd64

SASL_CB_GETCONF

SASL サーバーの構成ディレクトリへのパスを取得します。デフォルトは /etc/sasl です。

SASL_CB_LANGUAGE

優先順に並んだ RFC 1766 言語コードのコンマ区切りリストを指定します。このリストは、クライアントおよびサーバーのエラーメッセージとクライアントのプロンプトで使用されます。デフォルトは i-default です。

SASL_CB_VERIFYFILE

構成ファイルとプラグインファイルを検証します。

SASL が提供する次のコールバックは、クライアント専用です。

SASL_CB_USER

クライアントのユーザー名を取得します。このユーザー名は承認 ID と同一です。LOGNAME 環境変数がデフォルトになります。

SASL_CB_AUTHNAME

クライアントの認証名を取得します。

SASL_CB_PASS

クライアントのパスフレーズベースのパスワードを取得します。

SASL_CB_ECHOPROMPT

指定されたチャレンジプロンプトの結果を取得します。クライアントからの入力をエコーできます。

SASL_CB_NOECHOPROMPT

指定されたチャレンジプロンプトの結果を取得します。クライアントからの入力をエコーするべきではありません。

SASL_CB_GETREALM

認証に使用するレルムを設定します。

SASL が提供する次のコールバックは、サーバー専用です。

SASL_CB_PROXY_POLICY

認証されたユーザーが指定されたユーザーの代理役として承認されているかどうかを検査します。このコールバックが登録されていない場合、認証されたユーザーと承認されるべきユーザーが同一でなければなりません。これらの ID が同一でない場合、認証が失敗します。標準でない承認ポリシーを処理するには、サーバーアプリケーションを使用してください。

SASL_CB_SERVER_USERDB_CHECKPASS

呼び出し元から提供されたユーザーデータベースに対して平文パスワードを検証します。

SASL_CB_SERVER_USERDB_SETPASS

ユーザーデータベース内に平文パスワードを格納します。

SASL_CB_CANON_USER

アプリケーションから提供されたユーザー標準化関数を呼び出します。

最初の SASL ライブラリ初期化時に、サーバーとクライアントは必要な大域コールバックのすべてを宣言します。大域コールバックが利用可能なのは、SASL セッション初期化前と SASL セッション中です。セッション初期化前には、プラグインの読み込み、データのロギング、構成ファイルの読み取りなどのタスクがコールバックによって実行されます。SASL セッションの開始時に、追加のコールバックを宣言できます。そうしたコールバックは、必要に応じて大域コールバックをオーバーライドできます。

SASL 接続コンテキスト

libsasl は SASL 接続コンテキストを使用して、SASL クライアントと SASL サーバーの両方に対する各 SASL セッションの状態を格納します。各コンテキストは、同時に 1 つの認証および 1 つのセキュリティーセッションでしか使用できません。

    格納される状態としては、次のような情報があります。

  • サービス、名前情報およびアドレス情報、プロトコルフラグなどの接続情報

  • 接続に固有のコールバック

  • SASL SSF の折衝に使われるセキュリティープロパティー

  • 認証の状態とセキュリティー層の情報