Java SASL API
プログラミングおよび配備ガイド


  1. はじめに
  2. API の概要
  3. SASL 機構をインストールおよび選択する方法
  4. SunSASL プロバイダ
  5. SASL セキュリティープロバイダの実装

はじめに

SASL とは

SASL (Simple Authentication and Security Layer) は、認証およびクライアントアプリケーションとサーバーアプリケーション間のセキュリティー層の確立 (オプション) を行うプロトコルを指定するインターネット標準 (RFC 2222) です。SASL は認証データの交換方法を定義しますが、そのデータの内容は指定しません。認証データの内容およびセマンティクスを指定する特定の「認証機構」が適合できるフレームワークです。

SASL は、Lightweight Directory Access Protocol、バージョン 3 (LDAP v3) や Internet Message Access Protocol、バージョン 4 (IMAP v4) などのプロトコルによって使用され、プラグイン可能な認証を有効にします。認証メソッドをプロトコルに固定する代わりに、LDAP v3 および IMAP v4 は SASL を使用して認証を実行します。したがって、さまざまな SASL 機構による認証が可能になります。

さまざまなセキュリティーレベルおよび配備シナリオ用にインターネットコミュニティーによって定義された、多数の標準 SASL 機構があります。その範囲はセキュリティーなし (匿名認証など) から高セキュリティー (Kerberos 認証など) にいたるまで、さまざまなレベルがあります。

Java SASL API

Java SASL API は、SASL 機構を使用するアプリケーション用のクラスおよびインタフェースを定義します。Java SASL API は、機構に依存しないように定義されています。API を使用するアプリケーションを、特定の SASL 機構の使用に固定する必要はありません。この API は、クライアントとサーバーの両方のアプリケーションをサポートしています。アプリケーションは、受動的な辞書攻撃の影響を受けやすいかどうか、および匿名認証を受け入れるかどうかなど、必要なセキュリティー機能に基づいて使用する機構を選択できます。

Java SASL API では、開発者は独自のカスタム SASL 機構を使用することもできます。SASL 機構は、Java 暗号化アーキテクチャー (JCA) を使用してインストールされます。

SASL をいつ使用するか

SASL は、プラグイン可能な認証とセキュリティー層をネットワークアプリケーションに提供します。Java SE には、Java Secure Socket Extension (JSSE) や Java Generic Security Service (Java GSS) など、同様の機能を提供するその他の機能があります。JSSE は、SSL および TLS プロトコルの Java 言語バージョンに、フレームワークと実装を提供します。Java GSS は、Generic Security Service Application Programming Interface (GSS-API) 用の Java 言語バインディングです。Java SE では、この API の下で現在サポートされている機構は、Kerberos v5 のみです。

JSSE および Java GSS と比較すると、SASL は相対的に軽量であり、最近のプロトコルの中で一般的です。一般的かつ軽量な (インフラストラクチャーサポートの点で) SASL 機構がいくつか定義されているという利点もあります。一方、主要な JSSE および Java GSS 機構は相対的に重量のある機構を持ち、より精巧なインフラストラクチャー (それぞれ公開鍵インフラストラクチャーおよび Kerberos) を必要とします。

SASL、JSSE、および Java GSS は、しばしば併用されます。たとえば、一般的なパターンでは、アプリケーションは安全なチャネルを確立するために JSSE を使用し、クライアントのユーザー名/パスワードベースの認証には SASL を使用します。GSS-API 機構の上位層となる SASL 機構もあります。一般的な例は、LDAP で使用される SASL GSS-API/Kerberos v5 機構です。

プロトコルをゼロから定義および構築する場合を除き、どの API を使用するかを決定する場合の最大要因は、多くの場合プロトコル定義です。たとえば、LDAP および IMAP は SASL を使用するように定義されているので、これらのプロトコルに関係するソフトウェアは Java SASL API を使用するようにしてください。Kerberos アプリケーションおよびサービスを構築する場合、使用する API は Java GSS です。プロトコルとして SSL/TLS を使用するアプリケーションおよびサービスを構築する場合、使用する API は JSSE です。JSSE と Java GSS をいつ使用するかについての詳細は、「Java セキュリティードキュメント」を参照してください。

API の概要

SASL はチャレンジ応答プロトコルです。サーバーはクライアントにチャレンジを発行し、クライアントはチャレンジに基づいて応答を送信します。この交換は、サーバーが充足してチャレンジを発行しなくなるまで続きます。これらのチャレンジおよび応答は、任意の長さのバイナリトークンです。カプセル化を行うプロトコル (LDAP や IMAP など) は、これらのトークンの符号化および交換方法を指定します。たとえば、LDAP は、SASL トークンが LDAP バインド要求および応答にどのようにカプセル化されるかを指定します。

Java SASL API は、この相互作用と使用方法のスタイルに従ってモデル化されています。インタフェース SaslClient および SaslServer があり、これらはそれぞれクライアント側およびサーバー側の機構を表します。アプリケーションはチャレンジおよび応答を表すバイト配列によって、機構と相互に作用します。サーバー側の機構は、充足されるまでチャレンジの発行と応答の処理を繰り返します。一方、クライアント側の機構は、サーバーが充足されるまでチャレンジの評価と応答の発行を繰り返します。機構を使用しているアプリケーションが、それぞれの繰り返しを制御します。つまり、機構を使用しているアプリケーションは、チャレンジまたは応答をプロトコルパケットから抽出して機構に渡し、機構から返された応答またはチャレンジをプロトコルパケットに入れて、ピアに送信します。

機構の作成

SASL 機構を使用するクライアントコードおよびサーバーコードは、特定の機構を使用するように固定はされていません。SASL を使用する多くのプロトコルでは、サーバーは、サポートする SASL 機構のリストを (静的または動的に) 公開します。クライアントは、セキュリティー要件に基づいて、これらの 1 つを選択します。

Sasl クラスが、SaslClient および SaslServer のインスタンスの作成に使用されます。次に、使用可能な SASL 機構のリストを使用して、アプリケーションがどのように SASL クライアント機構を作成するかの例を示します。

String[] mechanisms = new String[]{"DIGEST-MD5", "PLAIN"}; SaslClient sc = Sasl.createSaslClient(mechanisms, authzid, protocol, serverName, props, callbackHandler);
プラットフォームによってサポートされる機構の可用性およびパラメータで提供されるその他の構成情報に基づいて、Java SASL フレームワークは一覧されている機構の 1 つを選択し、SaslClient のインスタンスを返します。

選択された機構の名前は、通常、アプリケーションプロトコルによってサーバーに転送されます。機構名を受信すると、サーバーは、クライアントから送信された応答を処理するために、対応する SaslServer オブジェクトを作成します。次に、サーバーが SaslServer のインスタンスを作成する方法の例を示します。

SaslServer ss = Sasl.createSaslServer(mechanism, protocol, myName, props, callbackHandler);

機構に入力を渡す

Java SASL API は汎用フレームワークなので、多数の異なるタイプの機構に対応できる必要があります。各機構は入力によって初期化される必要があり、先に進むために入力を必要とする場合があります。この API は、アプリケーションが機構に入力を渡すための 3 つの手段を提供します。

  1. 共通入力パラメータ。 アプリケーションはあらかじめ定義されたパラメータを使用して、SASL 仕様によって定義された、機構によって共通に必要とされる情報を提供します。SASL クライアント機構の場合、入力パラメータは承認 ID、プロトコル ID、およびサーバー名です。SASL サーバー機構の場合、共通入力パラメータはプロトコル ID および (完全修飾された固有の) サーバー名です。

  2. プロパティーパラメータ。 アプリケーションはプロパティーパラメータを使用して構成情報を提供します。このプロパティーパラメータは、プロパティー名のプロパティー値 (文字列以外の場合もありうる) へのマッピングです。Java SASL API は、保護の品質暗号の強度、および最大バッファーサイズなど、いくつかの標準プロパティーを定義しています。パラメータは、特定の機構に固有の非標準のプロパティーを渡す場合にも使用できます。

  3. コールバック。 アプリケーションはコールバックハンドラパラメータを使用して、あらかじめ決定できない入力、または機構間で共通でない場合がある入力を渡します。機構は入力データを必要とする場合、アプリケーションによって渡されたコールバックハンドラを使用してデータを収集します。アプリケーションのエンドユーザーから収集する場合もあります。たとえば、機構は、アプリケーションのエンドユーザーが名前とパスワードを入力するよう要求する場合があります。

    機構は、javax.security.auth.callback パッケージで定義されたコールバックを使用できます。これらは、認証を実行するアプリケーションを構築するのに便利な総称コールバックです。機構は、レルムおよび認証情報を収集するためのコールバックなどの、 SASL 固有のコールバック、および (標準化されていない) 機構固有のコールバックを必要とする場合もあります。 アプリケーションはさまざまな機構に対応できるようにしてください。したがって、そのコールバックハンドラは、機構が要求する可能性があるすべてのコールバックに対応できることが必要です。このことは、任意の機構に対しては一般的には不可能ですが、通常は配備および使用されている機構は数が限定されているので、可能です。

機構の使用

アプリケーションが機構を作成すると、アプリケーションは機構を使用して SASL トークンを取得し、ピアと交換します。 通常、クライアントはアプリケーションプロトコルによって、どの機構を使用するかをサーバーに指示します。一部のプロトコルでは、クライアントは初期応答を持つ機構用に、要求にオプションの「初期応答」を付加できます。この機能は、認証に必要なメッセージ交換の数を減らすために使用できます。次に、クライアントが認証に SaslClient をどのように使用するかの例を示します。
// Get optional initial response byte[] response = (sc.hasInitialResponse() ? sc.evaluateChallenge(new byte[]) : null); String mechanism = sc.getName(); // Send selected mechanism name and optional initial response to server send(mechanism, response); // Read response msg = receive(); while (!sc.isComplete() && (msg.status == CONTINUE || msg.status == SUCCESS)) { // Evaluate server challenge response = sc.evaluateChallenge(msg.contents); if (msg.status == SUCCESS) { // done; server doesn't expect any more SASL data if (response != null) { throw new IOException( "Protocol error: attempting to send response after completion"); } break; } else { send(mechanism, response); msg = receive(); } }
クライアントアプリケーションは機構 (sc) を使用して認証の各ステップを繰り返し、サーバーから取得したチャレンジを評価してサーバーに応答を返信します。クライアントアプリケーションは機構またはアプリケーションレベルのプロトコルが認証が完了したことを示すまで、または機構がチャレンジを評価できない場合に、このサイクルを続行します。機構がチャレンジを評価できない場合、エラーを示す例外をスローし、認証を終了します。完了状態に関して機構とプロトコルの間で不一致がある場合は、認証交換に障害があることを示す可能性があるため、エラーとして処理します。

次に、サーバーが SaslServer をどのように使用するかの例を示します。

// Read request that contains mechanism name and optional initial response msg.receive(); // Obtain a SaslServer to perform authentication SaslServer ss = Sasl.createSaslServer(msg.mechanism, protocol, myName, props, callbackHandler); // Perform authentication steps until done while (!ss.isComplete()) { try { // Process response byte[] challenge = sc.evaluateResponse(msg.contents); if (ss.isComplete()) { send(mechanism, challenge, SUCCESS); } else { send(mechanism, challenge, CONTINUE); msg.receive(); } } catch (SaslException e) { send(ERROR); sc.dispose(); break; } }
サーバーアプリケーションはクライアントの応答を機構 (ss) に渡して処理することによって、認証の各ステップを繰り返します。応答が不正な場合、サーバーがエラーを報告して認証を終了できるように、機構は SaslException をスローしてエラーを示します。応答が正しい場合、機構はクライアントに送信されるチャレンジデータを返し、認証が完了したかどうかを示します。チャレンジデータは「成功」を示すデータを伴うことができます。これは、たとえば、ネゴシエーションされた状態をクライアントに完結させるために使用される場合があります。

ネゴシエーション済みのセキュリティー層の使用

認証のみをサポートする SASL 機構だけでなく、認証後にネゴシエーション済みのセキュリティー層の使用をサポートする SASL 機構もあります。セキュリティー層の機能はアプリケーションが SSL/TLS などのほかの手段を使用してピアと安全に通信する場合は、使用されない場合がよくあります。

セキュリティー層がネゴシエーション済みの場合、ピアとの後続の通信はすべてセキュリティー層を使用して発生します。セキュリティー層がネゴシエーション済みかどうかを判別するには、ネゴシエーション済みの保護の品質 (QOP) を機構から取得します。次に、セキュリティー層がネゴシエーション済みかどうかを判別する方法の例を示します。

String qop = (String) sc.getNegotiatedProperty(Sasl.QOP); boolean hasSecurityLayer = (qop != null && (qop.equals("auth-int") || qop.equals("auth-conf")));
Sasl.QOP プロパティーが整合性または機密性、あるはその両方がネゴシエーション済みであることを示している場合、セキュリティー層はネゴシエーション済みです。

ネゴシエーション済みの層を使用してピアと通信するには、アプリケーションは最初に wrap メソッドを使用し、ピアに送信されるデータを符号化して「ラップされた」バッファーを生成します。次に、ラップされたバッファー内のオクテットの数を表す長さフィールドとそれに続いてラップされたバッファーの内容をピアに転送します。オクテットのストリームを受信するピアは長さフィールドを除くバッファーを unwrap に渡し、ピアによって送信された復号化されたバイトを取得します。 このプロトコルの詳細は RFC 2222 で説明されています。次に、クライアントアプリケーションがセキュリティー層を使用してアプリケーションデータをどのように送受信するかの例を示します。

// Send outgoing application data to peer byte[] outgoing = ...; byte[] netOut = sc.wrap(outgoing, 0, outgoing.length); send(netOut.length, netOut); // send to peer // Receive incoming application data from peer byte[] netIn = receive(); // read length and ensuing bytes from peer byte[] incoming = sc.unwrap(netIn, 0, netIn.length);

SASL 機構をインストールおよび選択する方法

SASL 機構の実装は、SASL セキュリティープロバイダによって提供されます。各プロバイダは 1 つ以上の SASL 機構をサポートでき、Java 暗号化アーキテクチャー (JCA) に登録されます。J2SE 5 では、デフォルトで SunSASL プロバイダが JCA プロバイダとして自動的に登録されます。このプロバイダを削除するか、JCA プロバイダとしての優先順位を変更するには、次の行を変更します。
security.provider.7=com.sun.security.sasl.Provider
これは、Java セキュリティープロパティーファイル ($JAVA_HOME/lib/security/java.security) にあります。

SASL プロバイダを追加または削除するには、セキュリティープロパティーファイルで対応する行を追加または削除します。たとえば、SASL プロバイダを追加し、その機構が SunSASL プロバイダによって実装されている同じ機構よりも優先して選択されるようにする場合は、セキュリティープロパティーファイルに小さい番号で行を追加します。

security.provider.7=com.example.MyProvider security.provider.8=com.sun.security.sasl.Provider

この場合、java.security.Security クラスを使用して、プログラムで独自のプロバイダを追加することもできます。たとえば、次のサンプルコードは、使用可能な SASL セキュリティープロバイダのリストに com.example.MyProvider を登録します。

Security.addProvider(new com.example.MyProvider());
アプリケーションが 1 つ以上の機構名を指定して SASL 機構を要求すると、SASL フレームワークは、登録済みプロバイダのリストを順に検索して、その機構をサポートする登録済みの SASL プロバイダを探します。次に、プロバイダは、要求された機構が選択ポリシープロパティーに一致するかどうかを判別し、一致する場合は、機構の実装を返します。

選択ポリシープロパティーは特定の攻撃に対する影響の受けやすさなど、機構のセキュリティー面を指定します。これらは、実装というよりも機構の特性 (定義) です。したがって、すべてのプロバイダは特定の機構について同じ結果になるはずです。たとえば、PLAIN 機構は、どのように実装されるかにかかわらず、平文攻撃の影響を受けやすくなります。選択ポリシープロパティーが指定されない場合、機構の選択に制限はありません。これらのプロパティーを使用して、アプリケーションは、実行環境に配備される可能性がある機構について、適していないものを使用しないようにすることができます。たとえば、平文攻撃の影響を受けやすい機構の使用を許可しない場合、アプリケーションは次のサンプルコードを使用する場合があります。

Map props = new HashMap();
props.add(Sasl.POLICY_NOPLAINTEXT, "true");
SaslClient sc = Sasl.createSaslClient(mechanisms,
    authzid, protocol, serverName, props, callbackHandler);
選択ポリシープロパティーの詳細は、Sasl クラスを参照してください。

SunSASL プロバイダ

SunSASL プロバイダは、次のクライアント機構およびサーバー機構をサポートします。

クライアント機構

SunSASL プロバイダは、LDAP、IMAP、および SMTP などの、一般的なプロトコルで使用される複数の SASL 機構をサポートします。次の表は、クライアント機構とそれらに必要な入力の概要です。

クライアント機構名 パラメータ/入力 コールバック 構成プロパティー 選択ポリシー
CRAM-MD5 承認 ID (デフォルトのユーザー名として) NameCallback
PasswordCallback
  Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
DIGEST-MD5 承認 ID
プロトコル ID
サーバー名
NameCallback
PasswordCallback
RealmCallback
RealmChoiceCallback
Sasl.QOP
Sasl.STRENGTH
Sasl.MAX_BUFFER
Sasl.SERVER_AUTH
「javax.security.sasl.sendmaxbuffer」
「com.sun.security.sasl.digest.cipher」
Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
EXTERNAL 承認 ID
外部チャネル
    Sasl.POLICY_NOPLAINTEXT
Sasl.POLICY_NOACTIVE
Sasl.POLICY_NODICTIONARY
GSSAPI JAAS Subject
承認 ID
プロトコル ID
サーバー名
  Sasl.QOP
Sasl.MAX_BUFFER
Sasl.SERVER_AUTH
「javax.security.sasl.sendmaxbuffer」
Sasl.POLICY_NOACTIVE
Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
PLAIN 承認 ID NameCallback
PasswordCallback
  Sasl.POLICY_NOANONYMOUS

SunSASL プロバイダのこれらの機構を使用するアプリケーションは、必要なパラメータ、コールバック、およびプロパティーを提供する必要があります。プロパティーには適切なデフォルト値が設定されているため、アプリケーションがデフォルト値をオーバーライドする場合にのみ設定する必要があります。ほとんどのパラメータ、コールバック、およびプロパティーは、API ドキュメントで説明されています。次のセクションでは、機構固有の動作、および API ドキュメントで説明されていないパラメータについて説明します。

Cram-MD5

Cram-MD5 クライアント機構は承認 ID パラメータが指定された場合、その承認 ID パラメータを NameCallback 内でデフォルトのユーザー名として使用して、アプリケーション/エンドユーザーに承認 ID を求めます。それ以外では、承認 ID は Cram-MD5 機構によって使用されません。認証 ID のみがサーバーと交換されます。

Digest-MD5

Digest-MD5 機構は、ダイジェスト認証およびオプションでセキュリティー層を確立する場合に使用されます。セキュリティー層とともに使用する Triple DES、DES、および RC4 (128、56、および 40 ビット) の暗号を指定します。Digest-MD5 機構は、プラットフォームで使用可能な暗号のみをサポートできます。たとえば、プラットフォームが RC4 暗号をサポートしない場合、Digest-MD5 機構はその暗号を使用しません。

Sasl.STRENGTH プロパティーは、「high」、「medium」、および「low」設定をサポートしており、デフォルトは「high,medium,low」です。暗号は、次のように強度設定にマッピングされています。

強度 暗号 暗号 ID
high Triple DES
RC4 128  ビット
3des rc4
medium DES
RC4 56  ビット
des rc4-56
low RC4 40  ビット rc4-40

特定の強度に複数の選択肢がある場合、選択される暗号は、基盤となるプラットフォームでの暗号の可用性によって決まります。使用する暗号を明示的に指定するには、「com.sun.security.sasl.digest.cipher」プロパティーを対応する暗号 ID に設定します。このプロパティー設定は、Sasl.STRENGTH および基盤となるプラットフォームで利用可能な暗号と互換性を持たせてください。たとえば、「low」に設定されている Sasl.STRENGTH と「3des」に設定されている「com.sun.security.sasl.digest.cipher」には、互換性がありません。「com.sun.security.sasl.digest.cipher」プロパティーには、デフォルトはありません。

「javax.security.sasl.sendmaxbuffer」プロパティーは、最大送信バッファーサイズ (の文字列表現) をバイト単位で指定します。デフォルト値は 65536 です。実際の最大バイト数は、この数の最小値およびピアの最大受信バッファーサイズになります。

GSSAPI

GSSAPI 機構は、Kerberos v5 認証およびオプションでセキュリティー層の確立に使用されます。機構は呼び出し側スレッドの Subject がクライアントの Kerberos 資格を含むこと、または Kerberos に暗黙的にログインすることによって資格が取得されることを想定しています。クライアントの Kerberos 資格を取得するには、Java Authentication and Authorization Service (JAAS) を使用し、Kerberos ログインモジュールを使用してログインします。詳細および例は、「Kerberos を使った Java GSS-API および JAAS のチュートリアル」を参照してください。JAAS 認証を使用して Kerberos 資格を取得したあとで、SASL GSSAPI 機構を使用するコードを doAs または doAsPrivileged 内に配置します。
LoginContext lc = new LoginContext("JaasSample", new TextCallbackHandler()); lc.login(); lc.getSubject().doAs(new SaslAction()); class SaslAction implements java.security.PrivilegedAction { public class run() { ... String[] mechanisms = new String[]{"GSSAPI"}; SaslClient sc = Sasl.createSaslClient(mechanisms, authzid, protocol, serverName, props, callbackHandler); ... } }
JAAS プログラミングを明示的に行わずに Kerberos 資格を取得するには、「Kerberos を使った Java GSS-API および JAAS のチュートリアル」を参照してください。この方法を使用する場合は、コードを doAs または doAsPrivileged 内にラップする必要はありません。

「javax.security.sasl.sendmaxbuffer」プロパティーは、最大送信バッファーサイズ (の文字列表現) をバイト単位で指定します。デフォルト値は 65536 です。実際の最大バイト数は、この数の最小値およびピアの最大受信バッファーサイズになります。

サーバー機構

次の表は、サーバー機構とそれらに必要な入力の概要です。

サーバー機構名 パラメータ/入力 コールバック 構成プロパティー 選択ポリシー
CRAM-MD5 サーバー名 AuthorizeCallback
NameCallback
PasswordCallback
  Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
DIGEST-MD5 プロトコル ID
サーバー名
AuthorizeCallback
NameCallback
PasswordCallback
RealmCallback
Sasl.QOP
Sasl.STRENGTH
Sasl.MAX_BUFFER
「javax.security.sasl.sendmaxbuffer」
「com.sun.security.sasl.digest.realm」
「com.sun.security.sasl.digest.utf8」
Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
GSSAPI JAAS Subject
プロトコル ID
サーバー名
AuthorizeCallback Sasl.QOP
Sasl.MAX_BUFFER
「javax.security.sasl.sendmaxbuffer」
Sasl.POLICY_NOACTIVE
Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT

SunSASL プロバイダのこれらの機構を使用するアプリケーションは、必要なパラメータ、コールバック、およびプロパティーを提供する必要があります。プロパティーには適切なデフォルト値が設定されているため、アプリケーションがデフォルト値をオーバーライドする場合にのみ設定する必要があります。

サーバー機構のすべてのユーザーには、AuthorizeCallback を処理するコールバックハンドラが必要です。これは、要求された承認 ID に代わって認証済みのユーザーが操作できるかどうかを判別するため、および承認されたユーザーの正規化された名前を取得するために (正規化が適用可能な場合)、機構によって使用されます。

ほとんどのパラメータ、コールバック、およびプロパティーは API ドキュメントで説明されています。次のセクションでは、機構固有の動作、および API ドキュメントで説明されていないパラメータについて説明します。

Cram-MD5

Cram-MD5 サーバー機構は NameCallback および PasswordCallback を使用して、SASL クライアントの応答の検証に必要なパスワードを取得します。コールバックハンドラは、パスワードを取得するための鍵として NameCallback.getDefaultName() を使用します。

Digest-MD5

Digest-MD5 サーバー機構は RealmCallbackNameCallback、および PasswordCallback を使用して、SASL クライアントの応答の検証に必要なパスワードを取得します。コールバックハンドラは、パスワードを取得するための鍵として RealmCallback.getDefaultText() および NameCallback.getDefaultName() を使用します。

「javax.security.sasl.sendmaxbuffer」プロパティーについては、Digest-MD5 クライアントの項で説明しています。

「com.sun.security.sasl.digest.realm」プロパティーは、サーバーがサポートするレルムの名前を空白で区切ったリストを指定するために使用されます。このリストは、チャレンジの一部としてクライアントに送信されます。このプロパティーが設定されていない場合、デフォルトのレルムはサーバーの名前です (パラメータとして指定)。

「com.sun.security.sasl.digest.utf8」プロパティーは、使用する文字エンコーディングを指定するために使用されます。「true」は UTF-8 エンコーディングを使用することを意味し、「false」は ISO Latin 1 (ISO-8859-1) を使用することを意味します。デフォルトは「true」です。

GSSAPI

GSSAPI サーバー機構には、Kerberos 資格および「javax.security.sasl.sendmaxbuffer」プロパティーに関して、GSSAPI クライアント機構と同じ要件があります。

デバッグおよび監視

SunSASL プロバイダは、ロギング API を使用して、実装のログを出力します。この出力は、ロギング構成ファイルおよびプログラム上の API (java.util.logging) を使用して制御できます。SunSASL プロバイダによって使用されるロガー名は、「javax.security.sasl」です。次に、SunSASL プロバイダの FINEST ロギングレベルを有効にするサンプルロギング構成ファイルを示します。
javax.security.sasl.level=FINEST handlers=java.util.logging.ConsoleHandler java.util.logging.ConsoleHandler.level=FINEST

次の表に、機構およびそれらが生成するロギング出力を示します。

機構 ロギングレベル ログ記録される情報
CRAM-MD5 FINE 構成プロパティー。チャレンジおよび応答メッセージ
DIGEST-MD5 INFO エンコーディングの問題のために破棄されたメッセージ
(不一致の MAC、不正なパディングなど)
DIGEST-MD5 FINE 構成プロパティー。チャレンジおよび応答メッセージ
DIGEST-MD5 FINER チャレンジおよび応答メッセージに関するより詳細な情報
DIGEST-MD5 FINEST セキュリティー層で交換されるバッファー
GSSAPI FINE 構成プロパティー。チャレンジおよび応答メッセージ
GSSAPI FINER チャレンジおよび応答メッセージに関するより詳細な情報
GSSAPI FINEST セキュリティー層で交換されるバッファー

SASL セキュリティープロバイダの実装

SASL セキュリティープロバイダの実装には、3 つの基本的な手順があります。
  1. SaslClient または SaslServer インタフェースを実装するクラスを記述します。
  2. クラスのインスタンスを作成するファクトリクラス (SaslClientFactory または SaslServerFactory を実装) を記述します。
  3. ファクトリを登録する JCA プロバイダを記述します。

最初のステップでは、SASL 機構を実装します。クライアント機構を実装するには、SaslClient インタフェースで宣言されたメソッドを実装する必要があります。同様に、サーバー機構の場合は、SaslServer インタフェースで宣言されたメソッドを実装する必要があります。 この説明では、クライアント機構「SAMPLE-MECH」の実装を開発するとします。この機構は、クラス com.example.SampleMechClient によって実装されます。機構が必要とする入力、およびそれらを実装が収集する方法を決定します。たとえば、機構がユーザー名/パスワードベースの場合、実装ではその情報をコールバックハンドラパラメータ経由で収集する必要性が高くなります。

次のステップでは、com.example.SampleMechClient のインスタンスを作成するファクトリクラスを記述します。ファクトリは Sasl.POLICY_* プロパティーによって記述されるように、サポートする機構の特性を決定する必要があります。そうすることにより、互換性のあるポリシープロパティーを使用して API ユーザーが要求したときに、機構のインスタンスを返すことができます。ファクトリは、また、機構を作成する前にパラメータの妥当性をチェックする場合もあります。この説明では、ファクトリクラスの名前を com.example.MySampleClientFactory とします。サンプルファクトリは 1 つの機構のみを処理しますが、1 つのファクトリは任意の数の機構を処理できます。

最後のステップでは、JCA プロバイダを作成します。JCA プロバイダを作成する手順は、「Java 暗号化アーキテクチャー用プロバイダの実装方法」に詳細に説明されています。 SASL クライアントファクトリは、次の形式のプロパティー名を使用して登録されます。

SaslClientFactory.mechName
一方、SASL サーバーファクトリは、次の形式のプロパティー名を使用して登録されます。
SaslServerFactory.mechName
mechName は、SASL 機構の名前です。これは、SaslClient.getMechanismName() および SaslServer.getMechanismName() によって返された名前です。この例で、プロバイダが「SAMPLE-MECH」機構を登録する方法を次に示します。
put("SaslClientFactory.SAMPLE-MECH", "com.example.MySampleClientFactory");
1 つの SASL プロバイダが、多数の機構を処理する場合があります。そのため、関連するファクトリを登録する put の呼び出しが多数ある場合があります。 完了した SASL プロバイダは、前述の手順を使用して、アプリケーションで利用可能にすることができます。



Copyright © 2006 Sun Microsystems, Inc. All rights reserved.