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);

アプリケーションがメカニズムを作成すると、アプリケーションはメカニズムを使用してSASLトークンを取得し、ピアと交換します。通常、クライアントはアプリケーション・プロトコルによって、どのメカニズムを使用するかをサーバーに指示します。一部のプロトコルでは、クライアントは初期応答を持つメカニズム用に、要求にオプションの初期応答を付加できます。この機能は、認証に必要なメッセージ交換の数を減らすために使用できます。次に、クライアントが認証にSaslClientをどのように使用するかの例を示します。

    // 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をスローしてエラーを示します。応答が正しい場合、メカニズムはクライアントに送信されるチャレンジ・データを返し、認証が完了したかどうかを示します。チャレンジ・データは「成功」を示すデータを伴うことができます。これは、たとえば、ネゴシエーションされた状態をクライアントに完結させるために使用される場合があります。

セキュリティ層がネゴシエーション済みの場合、ピアとの後続の通信はすべてセキュリティ層を使用して発生します。セキュリティ層がネゴシエーション済かどうかを判別するには、ネゴシエーション済のSasl.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で説明されています。例10-1では、クライアント・アプリケーションでセキュリティ層を使用してアプリケーション・データがどのように送受信されるかを示します。

// 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);

次の表は、クライアント・メカニズムとそれらに必要な入力の概要です。

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

Cram-MD5

Cram-MD5クライアント・メカニズムは、承認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です。暗号は、次のように強度設定にマッピングされています。

特定の強度に複数の選択肢がある場合、選択される暗号は、基盤となるプラットフォームでの暗号の可用性によって決まります。使用する暗号を明示的に指定するには、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です。実際の最大バイト数は、この数の最小値およびピアの最大受信バッファ・サイズになります。

NTLM

NT LAN Manager (NTLM)はMicrosoftが提供するセキュリティ・プロトコルで、Microsoftの各種サービス(IIS WebサーバーやExchangeメール・サーバーなど)へのアクセスに使用されます。SASLメカニズムとして、Microsoft Exchange Serverへのアクセスに使用できます。また、NTLMスキームでのHTTP認証にも役立ちます。

NTLMメカニズムは、NTLM認証に使用されます。セキュリティ層は提供しません。これは、javax.security.sasl.qop環境プロパティをauthにのみ設定できることを意味します。

LMCompatibilityLevelレジストリ値がサーバー上で高い値に設定されている場合、一部の低い値のリクエストはサポートされません。ただし、サーバーからクライアントに、より高いバージョンを使用するように通知するプロトコルはないため、ユーザーはクライアント側で適切なバージョンを手動で選択する必要があります。

デバッグを有効にするには、システム・プロパティntlm.debugを任意の値に設定します

メカニズムの作成時またはコールバックを介して次の情報を指定します。

認証後、クライアントは、サーバーによって提供されるcom.sun.security.sasl.html.domainという名前のネゴシエーション済のプロパティを受け取り、サーバーは、com.sun.security.sasl.ntlm.hostnameという名前(クライアントがこのサーバーへのアクセスに使用するホスト名)のネゴシエーション済のプロパティを受け取ります。

次の表は、サーバー・メカニズムとそれらに必要な入力の概要です。

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

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

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

Cram-MD5

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

Digest-MD5

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

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

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

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

次の表は、GSSAPIクライアント・メカニズムとそれらに必要な入力の概要です。

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

GSSAPI

GSSAPIメカニズムは、Kerberos v5認証およびオプションでセキュリティ層の確立に使用されます。メカニズムは呼出し側スレッドのSubjectがクライアントのKerberos資格を含むこと、またはKerberosに暗黙的にログインすることによって資格が取得されることを想定しています。クライアントのKerberos資格を取得するには、Java Authentication and Authorization Service (JAAS)を使用し、Kerberosログイン・モジュールを使用してログインします。詳細および例は、「JAASおよびJava GSS-APIチュートリアルの紹介」を参照してください。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<Void> {
   public Void run() {
       // ...
       String[] mechanisms = new String[]{"GSSAPI"};
       SaslClient sc = Sasl.createSaslClient(
           mechanisms, authzid, protocol, serverName, props, callbackHandler);
       // ...
   }
}

JAASプログラミングを明示的に行わずにKerberos資格を取得するには、「Java GSS-APIを使用した、JAASプログラミングなしのセキュアなメッセージ交換」を参照してください。この方法を使用する場合は、コードをdoAsまたはdoAsPrivileged内にラップする必要はありません

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

com.sun.security.jgss.inquiretype.type_nameネゴシエーション済プロパティには、ExtendedGSSContext.inquireSecContext(InquireType)メソッドにより戻された値が含まれます。ここで、type_nameはInquireType列挙パラメータの文字列形式です(小文字)。

次の表は、GSSAPIサーバー・メカニズムとそれらに必要な入力の概要です。

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

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

ほとんどのパラメータ、コールバック、およびプロパティはAPIドキュメントで説明されています。