パッケージ 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)を検索します。 現在のSubjectの適切なセットに希望の資格証明が存在しない場合、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クラスのファクトリとして機能し、サポートされているメカニズムに関する情報も提供します。このユーティリティ・クラスは、メッセージごとのGSSContextメソッド内で使用して、メッセージごとのプロパティを設定します。このクラスは、OID (Universal Object Identifier)とそれに関連付けられた操作を表します。
-
例外のサマリー