Java GSS-APIおよびJSSEのどちらも、次の基本的なセキュリティ機能セットを提供します。

1. クライアント/サーバーの認証
2. 転送データの暗号化および整合性保護

ただし、この2つには、重要な相違点があります。 このドキュメントでは、使用中の環境でどちらのセキュリティ・メカニズムを使用するかを判断するのに役立つ、いくつかの相違点を示します。

1. Kerberosシングル・サインオンのサポート

   Java 2 Standard Editionでは、GSS-APIにKerberosのサポートが必須のセキュリティ・メカニズムとして含まれます。 これは、使用するデスクトップがKerberosをサポートする場合、ユーザーにパスワードの入力を決して求めない、Java GSS-APIベースのアプリケーションを記述できることを意味します。

   現在のところ、JSSEはKerberosベースの認証を使用する暗号化方式群をサポートしていません。 この暗号化方式群のサポートは、Internet Engineering Task Force (IETF)によるTLSプロトコルの標準化作業に依存しています。

2. 通信API

   JSSEは、ソケット・ベースのAPIをサポートします。 JSSEソケットはjava.net内のソケット・クラスを拡張し、JSSEソケット・ファクトリはjavax.net内のソケット・ファクトリを拡張します。 このため、記述したアプリケーションでソケット・ファクトリを介したセキュリティの構成が必要な場合、JSSEの方が適しています。 JSSEソケットでは、信頼できる転送手段を使用する必要があります。 一般に、実装にはTCPが使用されます。

   一方、Java GSS-APIはトークン・ベースのAPIであり、通信の実行はアプリケーションに依存します。 これは、アプリケーションが、TCPソケット、UDPデータグラム、またはJava GSS-APIにより生成されたトークンの転送を許可するほかの任意のチャンネルを使用できることを意味します。 使用するアプリケーションがさまざまな通信プロトコルを必要とする場合、Java GSS-APIの方が適しています。 Java GSS-APIは、入力および出力ストリームを使用して、トークンの読み取りおよび書込みを実行できます。 ただし、ストリーム自体を設定する必要があります。

3. クレデンシャルの委譲

   Java GSS-APIを使用すると、Kerberosの使用時に、クライアントからサーバーへクレデンシャルを委譲できます。 アプリケーションが、バックエンド層との通信時に中間的存在がクライアントを装う必要がある多層環境に配備されている場合は、Java GSS-APIの方が適しています。

4. 選択的暗号化

   Java GSS-APIはトークン・ベースであるため、特定のメッセージ(すべてではない)を選択的に暗号化できます。 使用するアプリケーションでプレーン・テキストと暗号テキストのメッセージを混在させる必要がある場合には、Java GSS-APIの方が適しています。

5. プロトコル要件

   JSSEはRFC 2246に定義されているTLSプロトコルの実装を提供します。 Java GSS-APIは、RFC 2853に定義されているGSS-APIフレームワークの実装と、RFC 1964に定義されているKerberosバージョン5メカニズムの実装を提供します。 (Microsoft Windowsプラットフォームでは「SSPI with Kerberos」と呼ばれます。) TLSを使用する必要があるHTTPSなどのサーバーの場合、JSSEの方が適しています。 SASLを使用するLDAPサーバーなどのほかのサーバーでは、Kerberos付きのGSS-APIが必要な場合があります。この場合、Java GSS-APIの方が適しています。