プライマリ・コンテンツに移動
Oracle® Fusion Middleware WebLogicセキュリティ・サービスによるアプリケーションの開発
12c (12.2.1.3.0)
E90346-03
目次へ移動
目次

前
次

11 WebアプリケーションでのJASPICの使用

WebLogic Serverでは、Java Authentication Service Provider Interface for Containers (JASPIC)の使用をサポートして、Webアプリケーションの認証構成プロバイダを構成し、そのWebアプリケーション用のデフォルトのWLS認証メカニズムのかわりにそれを使用します。デプロイされたWebアプリケーションでJASPICを構成する方法を学習します。

ここでは、Oracle WebLogic Serverセキュリティの理解のJASPICセキュリティに示されているJASPICの基本的な概要を把握していることを前提とします。

Java Authentication Service Provider Interface for Containers (JASPIC)の概要

JASPIC認証構成プロバイダは、Webアプリケーションに対するユーザー資格証明を認証してサブジェクトを返します。これは、受信するWebアプリケーション・メッセージを認証し、そのメッセージ認証の結果確立されたID(予測されるサブジェクト)をWebLogic Serverに返します。

JASPICプログラミング・モデルについては、Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196)で説明されています。これにより、メッセージ認証メカニズムを実装する認証プロバイダをサーバーのWebアプリケーション・メッセージ処理コンテナまたはランタイムに統合できる、サービス・プロバイダ・インタフェース(SPI)が定義されます。

WebLogic Serverでは、JASPICを使用して、Webアプリケーションに対する認証を構成済認証構成プロバイダに委任できます。JASPICを使用するようにWebアプリケーションのコードを変更する必要はありません。かわりに、WebLogic Server管理コンソールまたはWLSTを使用して、Webアプリケーションのデプロイ後の操作用にJASPICを有効化します。

ドメイン内のデプロイされるWebアプリケーションごとに、JASPICを無効にするか(デフォルト)、ユーザー資格証明を認証して有効なサブジェクトを返すように構成された認証構成プロバイダを1つ選択するかを決定します。Webアプリケーションの認証構成プロバイダを構成すると、そのWebアプリケーションでは、これがWLS認証メカニズムのかわりに使用されます。したがって、認証構成プロバイダを指定する際は、これが独自のセキュリティ認証のニーズを満たすように注意する必要があります。

認証構成プロバイダを実装する必要があるか

デフォルトのWebLogic認可プロバイダが対応していない特別な要件がある場合には、独自の認証構成プロバイダを実装できます。

デフォルトのWebLogic Server認証構成プロバイダを使用するか、独自の認証構成プロバイダを実装できます。デフォルトのWebLogic Server認証構成プロバイダを使用して構成するには、「JASPICセキュリティの保護」で説明している手順を参照してください。

Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196)で説明されているように、認証構成プロバイダ(仕様内では「認証コンテキスト構成プロバイダ」)は、javax.security.auth.message.config.AuthConfigProviderインタフェースの実装です。

認証構成プロバイダには構成メカニズムがあり、このメカニズムを使用して、登録済のサーバー認証モジュール(SAM)と、未認証アクセスまたは許可されたアクセスからの保護が必要なアプリケーションとのバインディングが定義されます。

プリンシパル検証プロバイダを実装する必要があるか

認証プロバイダは、プリンシパル検証プロバイダを利用して、サブジェクトに格納されるプリンシパル(ユーザーとグループ)に署名し、信頼性を検証します。したがって、プリンシパル検証プロバイダは、サブジェクトに格納されたプリンシパルが悪意のある個人によって改ざんされるのを防止することです。

プリンシパルが、指定されたプリンシパル検証プロバイダに渡されます。プリンシパル検証プロバイダは、そのプリンシパルに署名して、それらをWebLogic Serverを通じてクライアント・アプリケーションに返します。他のセキュリティ操作のためにサブジェクト内のプリンシパルが必要になった場合、同じプリンシパル検証プロバイダが、そのプリンシパルが署名時から変更されていないかどうかを検証します。

こうした検証によって、信頼度は向上し、悪意のあるプリンシパルによる改ざんの可能性を低くすることができます。サブジェクトのプリンシパルの信頼性も、認可判定の際に検証されます。

このため、プリンシパル検証プロバイダをプリンシパル検証プロバイダの説明に従って使用する必要があります。

既存のWebLogicプリンシパル検証プロバイダを使用するか、カスタム・プリンシパル検証プロバイダを実装するかは、使用するプリンシパルのタイプによって決まります。

  • WebLogic Serverプリンシパル - WebLogicプリンシパル検証プロバイダには、WLSUserImplおよびWLSGroupImplという名前のWLSUserインタフェースおよびWLSGroupインタフェースの実装が含まれています。これらは、weblogic.security.principalパッケージに定義されています。

    また、PrincipalValidatorImplという名前のPrincipalValidator SSPIの実装も含まれています。これはcom.bea.common.security.providerパッケージに定義されています。このクラスを使用するには、PrincipalValidatorImplクラスをプリンシパル検証プロバイダのランタイム・クラスにします。使用方法は、PrincipalValidator SSPIを参照してください。

  • カスタム・プリンシパル - 独自の検証スキームがあり、WebLogicプリンシパル検証プロバイダを使用しない場合や、WebLogic Serverプリンシパル以外のプリンシパルを検証する場合は、カスタム・プリンシパル検証プロバイダを開発する必要があります。

    注意:

    カスタム・プリンシパルを追加する場合は、プリンシパル検証プロバイダを追加する必要があります。そうしないと認可が失敗します。WebLogic Serverセキュリティ・フレームワークはプリンシパル検証を認可の一部として実行します。(認可でJACCを使用する場合のみ例外です。また、JACCのケースでも、WebアプリケーションまたはEJBがその他のサーバー・リソース(たとえば、JDBC)にアクセスする場合、WebLogic Serverの認可およびプリンシパル検証が使用されます。)

    このケースでは、認証プロバイダも開発する必要があります。AuthenticationProviderV2 SSPIにはgetPrincipalValidatorというメソッドが含まれ、ここにプリンシパル検証プロバイダのランタイム・クラスを指定します。WebLogic Serverはこのメソッドを使用して、プリンシパル検証プロバイダを取得します。(この使用方法では、これ以外のメソッドはnullを返します。)

これらの方法の詳細は、Oracle WebLogic Serverセキュリティ・プロバイダの開発のプリンシパル検証プロバイダを参照してください。

SAMの実装

互換性のあるサーバー側のメッセージ処理ランタイムに対して認証メカニズムを追加するための重要な手順は、必要な認証メカニズムを実装するサーバー認証モジュール(SAM)を取得することです。

デフォルトのWebLogic Server認証構成プロバイダと独自の認証構成プロバイダで機能する独自のSAMを実装する必要があります。

SAMは、JASPICに準拠したサーバー側認証プロバイダの実装になります。Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196)で説明されているように、SAMはjavax.security.auth.message.module.ServerAuthModuleインタフェースを実装し、メッセージ処理モデルのあらかじめ決められた時点でWebLogic Serverから起動されます。

注意:

SAM実装のサンプルについては、「GlassFishサーブレット・コンテナへの認証メカニズムの追加」を参照してください。GlassFishサーバーの観点で記載されていますが、SAMを作成するためのヒントやSAM用のサンプルは役立ちます。

デプロイされたWebアプリケーションでのJASPICの構成

デプロイされたWebアプリケーションに対してJASPICを構成するには、コマンド・ラインを使用してSAMのjarをシステム・クラスパスに追加して、WebLogic Server管理コンソールを使用してドメイン内でJASPICを有効にし、目的の認証構成プロバイダを構成してSAMのクラス名を指定します。

次の手順を実行して、Webアプリケーションに対してJASPICを構成します。

  1. WebLogic Serverインスタンスの起動に使用する起動スクリプトまたはコマンド・ラインで、SAMのjarをシステム・クラスパスに追加します。

    カスタムの認証構成プロバイダを構成した場合、WebLogic Serverインスタンスの起動に使用する起動スクリプトまたはコマンド・ラインから、カスタムの認証構成プロバイダのjarをシステム・クラスパスに追加する必要があります。

  2. 「JASPICセキュリティの構成」の説明に従って、ドメインでJASPICを有効化します。

  3. 「JASPICセキュリティの構成」の説明に従って、WebLogic Server認証構成プロバイダまたはカスタム認証構成プロバイダを構成して、SAMのクラス名を指定します。

  4. コンソールの左のペインで「デプロイメント」を選択します。

    現在WebLogic Serverにインストールされているデプロイメントをリストする表が右のペインに表示されます。「タイプ」列は、デプロイメントがエンタープライズ・アプリケーションか、Webアプリケーションか、EJBモジュールかを指定します。

  5. 右のペインで、構成するWebアプリケーションの名前をクリックします。

  6. 「セキュリティ」→JASPICを選択し、JASPICプロパティを表示して変更します。

    デフォルトでは、JASPICはWebアプリケーションに対して無効です。このWebアプリケーションに対してJASPICを有効にするには、ドロップダウン・リストから適切な認証構成プロバイダを選択します。

  7. 保存」をクリックして変更を保存します。

  8. 求められたら変更をデプロイメント・プランに保存します。

  9. JASPICを有効にするWebアプリケーションがあれば、手順5から7を繰り返します。

  10. Webアプリケーションを再デプロイします。

  11. WebLogic Serverを再起動します。