パッケージorg.ietf.jgss
GSS-APIは、RFC 2743で定義されている、言語に依存しないAPIです。 Java言語バインディングはRFC 2853で定義されています。
アプリケーションでは、最初にGSSManagerのインスタンスを作成します。このインスタンスは、セキュリティ・コンテキストのファクトリとして機能します。 特定の主体名や資格もGSSManagerを使用して作成し、アプリケーションで使用できます。コンテキストをインスタンス化するときは、システムのデフォルトを使用することもできます。 次に、コンテキスト確立ループを実行します。 ピアとのコンテキストが確立されると、認証が完了します。 整合性や機密性などのデータ保護は、このコンテキストから取得できます。
GSS-APIでは、ピアとの通信は行いません。 アプリケーションから相手方のピアに転送するトークンを作成するだけです。
クレデンシャルの取得
GSS-API自体は、ベースとなるメカニズムが認証に必要な資格証明を取得する方法を指定しません。 GSS-APIを呼び出す前に、これらの資格証明が取得され、メカニズム・プロバイダが認識しているロケーションに格納されます。 ただし、Javaプラットフォームのデフォルト・モデルは、メカニズム・プロバイダが、現行のアクセス制御コンテキストでSubjectに関連付けられているプライベート資格証明セットまたはパブリック資格証明セットからのみ資格証明を取得する必要があることです。 Kerberos v5メカニズムでは、プライベート資格証明セットで必要なINITIATEおよびACCEPT資格証明(KerberosTicketとKerberosKey)が検索されますが、他のメカニズムではパブリック・セット内またはその両方がされる場合があります。 目的の資格証明が現在のサブジェクトの適切なセットに存在しない場合、GSS-APIコールは失敗する必要があります。 このモデルには、アプリケーションの観点から資格管理が単純で予測可能であるという利点があります。 適切なアクセス権を付与されたアプリケーションは、サブジェクト内のクレデンシャルを取り除いたり、標準Java APIを使用してクレデンシャルを更新したりできます。 資格をパージすると、JGSSメカニズムは失敗します。時間ベースの資格を更新すると、JGSSメカニズムは成功します。
このモデルでは、JAAS loginを実行してSubjectを認証し、必要な情報を設定し、JGSSメカニズムが後で使用できるようにしておく必要があります。 ただし、アプリケーションでは、システム・プロパティを使用してこの制限を緩和できます: javax.security.auth.useSubjectCredsOnly。 デフォルトではこのシステム・プロパティはtrueと見なされ(未設定の場合でも)、プロバイダは現在のSubjectに入っている資格しか使用できません。 しかし、アプリケーションがこのプロパティを明示的にfalseに設定した場合、プロバイダは任意の資格キャッシュを選択して使用できます。 たとえば、ディスク・キャッシュ、メモリー内キャッシュ、現在のSubject自体などから選択できます。
関連項目
Java GSS-APIの使い方に関するオンライン・チュートリアルは、「JAASおよびJava GSS-APIのチュートリアルの紹介」を参照してください。- 導入されたバージョン:
- 1.4
-
クラス説明このクラスは、呼出し側から提供されるチャネル・バインディング情報の概念をカプセル化します。このインタフェースは、GSS-APIのセキュリティ・コンテキストをカプセル化し、そのコンテキストで利用できるセキュリティ・サービスを提供します。このインタフェースでは、エンティティのGSS-API資格をカプセル化します。この例外は、GSS-APIメカニズム固有のエラーを含むGSS-APIエラーが発生したときにスローされます。このクラスは、ほかの重要なGSS-APIクラスのファクトリとして機能し、サポートされているメカニズムに関する情報も提供します。このインタフェースは、単一のGSS-API主体エンティティをカプセル化します。このユーティリティ・クラスは、メッセージごとのGSSContextメソッド内で使用して、メッセージごとのプロパティを設定します。このクラスは、OID (Universal Object Identifier)とそれに関連付けられた操作を表します。