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では、開発者は独自のカスタムSASLメカニズムを使用することもできます。SASLメカニズムは、Java暗号化アーキテクチャ(JCA)を使用してインストールされます。
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セキュリティ・ドキュメント」を参照してください。
Java SASL APIは、この相互作用と使用方法のスタイルに従ってモデル化されています。インタフェースSaslClientおよびSaslServerがあり、これらはそれぞれクライアント側およびサーバー側のメカニズムを表します。アプリケーションはチャレンジと応答を表すバイト配列によって、メカニズムと相互に作用します。サーバー側のメカニズムは、充足されるまでチャレンジの発行と応答の処理を繰り返します。一方、クライアント側のメカニズムは、サーバーが充足されるまでチャレンジの評価と応答の発行を繰り返します。メカニズムを使用しているアプリケーションが、それぞれの反復を制御します。つまり、それは、チャレンジまたは応答をプロトコル・パケットから抽出してメカニズムに渡し、メカニズムから返された応答またはチャレンジをプロトコル・パケットに入れて、ピアに送信します。
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つの手段を提供します。
メカニズムは、javax.security.auth.callbackパッケージで定義されたコールバックを使用できます。これらは、認証を実行するアプリケーションを構築するのに便利なジェネリック・コールバックです。メカニズムは、レルムおよび認証情報を収集するためのコールバックなどの、SASL固有のコールバック、または(標準化されていない)メカニズム固有のコールバックを必要とする場合もあります。アプリケーションは様々なメカニズムに対応できるようにする必要があります。したがって、そのコールバック・ハンドラは、メカニズムが要求する可能性があるすべてのコールバックに対応できることが必要です。これは、任意のメカニズムに対しては一般的には不可能ですが、通常は配備および使用されているメカニズムは数が限定されているため、実現可能です。
// Get optional initial response byte[] response = (sc.hasInitialResponse() ? sc.evaluateChallenge(new byte[]) : null); String mechanism = sc.getMechanismName(); // 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をスローしてエラーを示します。応答が正しい場合、メカニズムはクライアントに送信されるチャレンジ・データを返し、認証が完了したかどうかを示します。チャレンジ・データは「成功」を示すデータを伴うことができます。これは、たとえば、ネゴシエーションされた状態をクライアントに完結させるために使用される場合があります。
セキュリティ層がネゴシエーション済みの場合、ピアとの後続の通信はすべてセキュリティ層を使用して発生します。セキュリティ層がネゴシエーション済みかどうかを判別するには、ネゴシエーション済みの保護の品質 (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);
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クラスを参照してください。
クライアント・メカニズム名 | パラメータ/入力 | コールバック | 構成プロパティ | 選択ポリシー |
---|---|---|---|---|
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 サブジェクト 承認 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クライアント・メカニズムは、承認IDパラメータが指定された場合、それをNameCallback
のデフォルト・ユーザー名として使用して、アプリケーション/エンドユーザーに認証IDを求めます。それ以外の場合、承認IDはCram-MD5メカニズムによって使用されません。認証IDのみがサーバーと交換されます。
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です。実際の最大バイト数は、この数の最小値およびピアの最大受信バッファ・サイズになります。
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 サブジェクト プロトコル 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ドキュメントで説明されていないパラメータについて説明します。
「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」です。
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メカニズムの実装を提供することが含まれます。クライアント・メカニズムを実装するには、SaslClientインタフェースで宣言されたメソッドを実装する必要があります。同様に、サーバー・メカニズムの場合は、SaslServerインタフェースで宣言されたメソッドを実装する必要があります。この説明では、クラスcom.example.SampleMechClientによって実装されるクライアント・メカニズム「SAMPLE-MECH」の実装を開発するものとします。メカニズムが必要とする入力、およびそれらを実装が収集する方法を決定する必要があります。たとえば、メカニズムがユーザー名/パスワードベースの場合、実装ではその情報をコールバック・ハンドラ・パラメータ経由で収集する必要性が高くなります。
次のステップでは、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プロバイダは、前述の手順を使用して、アプリケーションで利用可能にすることができます。