10 Webアプリケーションに対するJakarta Authenticationの使用

Oracle WebLogic Serverでは、Jakarta Authenticationを使用してWebアプリケーションの認証構成プロバイダを構成し、そのWebアプリケーションに対してデフォルトのWebLogic Server認証メカニズムのかわりにこれを使用することがサポートされます。デプロイされたWebアプリケーションに対してJakarta Authenticationを構成する方法を学習します。

Jakarta Authenticationは、以前はJava Authentication Service Provider Interface for Containers (JASPIC)と呼ばれていました。

この項では、『Oracle WebLogic Serverセキュリティの理解』のJakarta Authenticationのセキュリティに関する項で説明されているように、Jakarta Authenticationの基本的な概要を理解していることを前提としています。

Jakarta Authenticationの概要

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

Jakarta Authenticationプログラミング・モデルについては、Jakarta Authentication仕様(https://jakarta.ee/specifications/authentication/)を参照してください。これにより、メッセージ認証メカニズムを実装する認証プロバイダをサーバーのWebアプリケーション・メッセージ処理コンテナまたはランタイムに統合できる、サービス・プロバイダ・インタフェース(SPI)が定義されます。

WebLogic Serverでは、Jakarta Authenticationを使用して、Webアプリケーションに対する認証を構成済認証構成プロバイダに委任できます。Jakarta Authenticationを使用するためにWebアプリケーション・コードを変更する必要はありません。かわりに、WebLogicリモート・コンソールまたはWLSTを使用して、デプロイ後にWebアプリケーションに対してJakarta Authenticationを有効にします。

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

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

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

デフォルトのWebLogic Server認証構成プロバイダを使用するか、独自の認証構成プロバイダを実装できます。デフォルトのWebLogic Server認証構成プロバイダを使用および構成するには、『Oracle WebLogic Serverセキュリティの管理』のJakarta Authenticationセキュリティの構成に関する項で説明されているステップを参照してください。

Jakarta Authentication仕様(https://jakarta.ee/specifications/authentication/)で説明されているように、認証構成プロバイダ(仕様では「認証コンテキスト構成プロバイダ」と呼ばれます)は、jakarta.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セキュリティ・フレームワークはプリンシパル検証を認可の一部として実行します。(唯一の例外は、認可にJakarta Authorizationを使用している場合です。Jakarta Authorizationの場合でも、WebアプリケーションまたはEJBがその他のサーバー・リソース(たとえば、JDBC)にアクセスする場合、WebLogic Serverの認可およびプリンシパル検証が使用されます。)

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

どちらのオプションも、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のプリンシパル検証プロバイダに関する項に記載されています。

SAMの実装

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

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

SAMは、Jakarta Authenticationに準拠するサーバー側認証プロバイダの実装を表します。Jakarta Authentication仕様(https://jakarta.ee/specifications/authentication/)で説明されているように、SAMはjakarta.security.auth.message.module.ServerAuthModuleインタフェースを実装し、メッセージ処理モデルの所定のポイントでWebLogic Serverによって起動されます。

ノート:

SAMの実装サンプルについては、『GlassFish Server Open Source Editionアプリケーション開発ガイド』のサーブレット・コンテナへの認証メカニズムの追加に関する項で説明しています。GlassFishサーバーの観点で記載されていますが、SAMを作成するためのヒントやSAM用のサンプルは役立ちます。

デプロイされたWebアプリケーションに対するJakarta Authenticationの構成

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

WebアプリケーションのJakarta Authenticationを構成するには、次のステップを実行します:

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

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

  2. 『Oracle WebLogic Serverセキュリティの管理』のJakarta Authenticationセキュリティの構成に関する項の説明に従って、ドメインでJakarta Authenticationを有効にします。

  3. 『Oracle WebLogic Serverセキュリティの管理』のJakarta Authenticationセキュリティの構成に関する項の説明に従って、WebLogic Server認証構成プロバイダまたはカスタム認証構成プロバイダを構成して、SAMのクラス名を指定します。

  4. Oracle WebLogicリモート・コンソール・オンライン・ヘルプのWebアプリケーションのJASPICの構成に関する項の説明に従って、アプリケーションにJakarta Authenticationを構成します。