ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発
11g リリース 1 (10.3.1)
B55527-01
 

目次
目次

戻る
戻る
 
次へ
次へ

10 監査プロバイダ

監査とは、一連の要求の操作や結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。WebLogic Server では、監査はコンピュータのアクティビティの電子的な記録を提供するものです。

以下の節では、監査プロバイダの概念と機能、およびカスタム監査プロバイダの開発手順について説明します。

監査の概念

監査プロバイダを開発する前に、以下の概念を理解しておく必要があります。

監査チャネル

監査チャネルは監査プロバイダのコンポーネントで、セキュリティ イベントを監査すべきかどうかを決定し、サービス品質 (QoS) ポリシーに基づいて監査情報を実際に記録します。


注意 :

監査チャネルの詳細については、「AuditChannel SSPI の実装」を参照してください。

カスタム セキュリティ プロバイダからのイベントの監査

各タイプのセキュリティ プロバイダは、セキュリティ関連イベントの実行前または実行後に、それらのイベントに関する情報を記録するようコンフィグレーション済みの監査プロバイダに要求できます。たとえば、あるユーザが (アクセス権を持たない) 預金口座アプリケーションの withdraw メソッドにアクセスしようとした場合、認可プロバイダではこの操作を記録するように要求できます。セキュリティ関連イベントは、監査プロバイダのコンフィグレーションで指定されている重大度レベルと一致するか、それを超えた場合にのみ記録されます。

カスタム セキュリティ プロバイダから監査イベントをポストする方法については、「カスタム セキュリティ プロバイダからのイベントの監査」を参照してください。

監査プロセス

図 10-1 に、監査プロバイダが WebLogic Security フレームワークや他のタイプのセキュリティ プロバイダ (ここでは認証プロバイダ) と対話して、選択されたイベントを監査する仕組みを示します。図の後には、詳しい説明が続きます。

図  10-1 監査プロバイダ、WebLogic Security フレームワーク、および他のセキュリティ プロバイダ

図 10-1 の説明は図の下のリンクをクリックしてください。
「図 10-1 監査プロバイダ、WebLogic Security フレームワーク、および他のセキュリティ プロバイダ」の説明

監査プロバイダは、次のように WebLogic Security フレームワークと他のタイプのセキュリティ プロバイダと対話します。


注意 :

図 10-1 と以下の説明文では、「他のタイプのセキュリティ プロバイダ」は WebLogic 認証プロバイダとカスタム認証プロバイダです。ただし、これらは「カスタム セキュリティ プロバイダからのイベントの監査」の説明のように、開発済みのどのようなタイプのセキュリティ プロバイダでも構いません。

  1. リソース コンテナは、ログイン要求の一部としてユーザの認証情報 (ユーザ名とパスワードの組み合わせなど) を WebLogic Security フレームワークに渡します。

  2. WebLogic Security フレームワークは、ログイン要求に関連付けられている情報をコンフィグレーション済みの認証プロバイダに渡します。

  3. 認証サーバが認証サービスを提供するほかに監査イベントをポストする場合、各認証プロバイダは以下のことを行います。

    1. AuditEvent オブジェクトをインスタンス化します。AuditEvent オブジェクトには、少なくとも監査対象のイベント タイプに関する情報と監査の重大度レベルが含まれます。


      注意 :

      AuditEvent クラスを作成するには、カスタム認証プロバイダがすでに実装している必要がある他のセキュリティ サービス プロバイダ インタフェース (SSPI) に加えて、認証プロバイダの実行時クラスに AuditEvent SSPI または AuditEvent コンビニエンス インタフェースを実装します。監査イベントと AuditEvent SSPI/コンビニエンス インタフェースについては、「監査イベントの作成」を参照してください。

    2. 監査サービスに対して信頼性のある呼び出しを行って、AuditEvent オブジェクトを渡します。


      注意 :

      ここで信頼性のある呼び出しとするのは、監査サービスがすでにセキュリティ プロバイダの initialize メソッドに「Provider」SSPI 実装の一部として渡されているからです。詳細については、「「Provider」SSPI の目的について」を参照してください。

  4. 監査サービスは、AuditEvent オブジェクトをコンフィグレーション済みの監査プロバイダの実行時クラス (AuditChannel SSPI 実装) に渡し、監査イベントの記録を有効にします。


    注意 :

    認証プロバイダの AuditEvent コンビニエンス インタフェースの実装によっては、監査要求がイベントに対して 1 回発生するだけでなく、イベントの前後にも発生する場合があります。

  5. 監査プロバイダの実行時クラスは、AuditEvent オブジェクトから取得したイベント タイプ、監査重大度、およびその他の情報 (監査コンテキストなど) を利用して監査レコードの内容を管理します。一般に、コンフィグレーション済みの監査プロバイダの 1 つだけがすべての監査条件を満たします。

  6. 認証プロバイダによって AuditEvent オブジェクト内に指定された監査条件が満たされると、該当する監査プロバイダの実行時クラス (AuditChannel SSPI 実装) はそれらの実装で指定された方法で監査レコードを書き出します。

ContextHandler MBean の実装

ContextHandlerMBean (weblogic.management.security.audit.ContextHandler) は、ContextHandler がサポートする一連の属性を提供します。このインタフェースを使用すると、コンテキスト ハンドラ エントリを標準的な方法でサポートする監査プロバイダを管理できます。

監査プロバイダ MBean は、ContextHandlerMBean の MBean を必要に応じて実装できます。監査プロバイダは、この MBean を使用して、サポートされているアクティブな ContextHandler エントリを判別します。

WebLogic Server Administration Console は、監査プロバイダがこの MBean を実装したことを検出して、これらの属性を使用するためのタブを自動的に提供します。


注意 :

ContextHandlerMBean に関連付けられている ContextHandler エントリは、監査プロバイダに渡される AuditEvent の内容に関連付けられることも、影響を与えることもありません。プロバイダが受信した AuditEvent には、ContextElement が指定された ContextHandler が含まれる場合も含まれない場合もあります。ContextHandler が含まれている場合、監査プロバイダは、ContextHandlerMBean 管理インタフェースを実装したかどうかに関係なく AuditEvent から ContextHandler を取得できます。特に、AuditContext getContext メソッドは、ContextHandlerMBean によって実装されたコンテキスト ハンドラに依存しない weblogic.security.service.ContextHandler インタフェースを返します。

AuditContext getContext メソッドを補完する形で ContextHandlerMBean コンテキスト ハンドラを実装するように選択することもできます (サンプルの SimpleSampleAuditProviderImpl.java では、この方法を取っています)。ただし、これは必須ではありません。


ContextHandlerMBean のメソッド

ContextHandlerMBean インタフェースは、以下のメソッドを実装しています。

  • getActiveContextHandlerEntries

    public String[] getActiveContextHandlerEntries()
    

    現在、監査プロバイダで処理するようにコンフィグレーションされている ContextHandler エントリを返します。

  • getSupportedContextHandlerEntries

    public String[] getSupportedContextHandlerEntries()
    

    監査プロバイダによってサポートされているすべての ContextHandler エントリのリストを返します。

  • setActiveContextHandlerEntries

    public void setActiveContextHandlerEntries(String[] types) throws InvalidAttributeValueException
    

    監査プロバイダで処理する ContextHandler エントリを設定します。指定するエントリは、監査プロバイダの SupportedContextHandlerEntries 属性に列挙されているものである必要があります。

例 : ContextHandlerMBean の実装

コード リスト 10-5 は、サンプル監査プロバイダの実行時クラスである SimpleSampleAuditProviderImpl.java クラスを示しています。このサンプル監査プロバイダは、ContextHandlerMBean を実装するように拡張されています。

MBean 定義ファイル (MDF) は、WebLogic MBeanMaker ユーティリティで、MBean タイプを構成する Java ファイルを生成するために使用される XML ファイルです。すべての MDF では、作成済みのセキュリティ プロバイダのタイプに固有の必須 SSPI MBean を拡張する必要があり、さらに任意 SSPI MBean を実装することができます。

コード リスト 10-1 は、任意 ContexthandlerMBean を実装するサンプル監査プロバイダに関連する MDF 内の主要なセクションを示しています。

コード リスト 10-1 例 : SimpleSampleAuditor.xml

<MBeanType
Name          = "SimpleSampleAuditor"
DisplayName   = "SimpleSampleAuditor"
Package       = "examples.security.providers.audit.simple"
Extends       = "weblogic.management.security.audit.Auditor"
Implements    = "weblogic.management.security.audit.ContextHandler"
PersistPolicy = "OnUpdate"
>
...
<MBeanAttribute
Name          = "SupportedContextHandlerEntries"
Type          = "java.lang.String[]"
Writeable     = "false"
Default       = "new String[] { 
&quot;com.bea.contextelement.servlet.HttpServletRequest&quot; }"
Description   = "List of all ContextHandler entries
supported by the auditor."
/>

weblogic.management.security.audit.ContextHandlerImpl の拡張

ContextHandlerMBean には setActiveContextHandlerEntries という属性があり、現在、監査プロバイダで処理するようにコンフィグレーションされている ContextHandler エントリを setActiveContextHandlerEntries メソッドでこの属性に指定します。指定するエントリは、監査プロバイダの SupportedContextHandlerEntries 属性に列挙されているものである必要があります。ただし実際には、MBean ではこの要件が強制されません。この属性に SupportedContextHandlerEntries 属性にある値のみを設定できるように検証する処理を、別に行う必要があります。

そこで、weblogic.management.security.audit.ContextHandlerImpl を拡張し、MBean をカスタマイズするファイル (MyAuditorImpl.java のように名付ける) も必ず作成するようにします。weblogic.management.security.audit.ContextHandlerImpl を拡張すると、プロバイダから ActiveContextHandlerEntries 属性の検証プロバイダへのアクセスが可能になります。この検証プロバイダによって、このエントリに確実に SupportedContextHandlerEntries にある値のみが含まれるようになります。

ContextHandlerImpl の拡張例は SimpleSampleAuditorImpl で確認できます。コード リスト 10-2 に示します。

コード リスト 10-2 SimpleSampleAuditorImpl

package examples.security.providers.audit.simple;
import javax.management.MBeanException;
import javax.management.modelmbean.RequiredModelMBean;
import weblogic.management.security.audit.ContextHandlerImpl;

/**
* 簡単なサンプル監査プロバイダの MBean 実装。
* <p>
* ContextHandlerMBean の ActiveContextHandlerEntries 属性の検証プロバイダを継承する必要がある
* この検証プロバイダによって ActiveContextHandlerEntries 属性に
* 必ず SupportedContextHandlerEntries の値のみが
* 含まれるようにできる。
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class SimpleSampleAuditorImpl extends ContextHandlerImpl
// 注意 : ActiveContextHandlerEntries 属性の検証プロバイダを継承するために
// AuditorImpl ではなく ContextHandlerImpl を拡張する。
{
/**
* 標準的な MBean 実装のコンストラクタ。
*
* @throws MBeanException
*/
public SimpleSampleAuditorImpl(RequiredModelMBean base) throws MBeanException
{
super(base);
}
}

SimpleSampleAuditorImpl のようなコードを実装したら、ActiveContextHandlerEntries を取得するため、実行時の監査プロバイダにコードを追加します。この作業の一例をコード リスト 10-3 に示します。

コード リスト 10-3 アクティブなコンテキスト ハンドラ エントリの取得

 String [] activeHandlerEntries = myMBean.getActiveContextHandlerEntries();
    if (activeHandlerEntries != null) {
      for (int i=0; i<activeHandlerEntries.length; i++) {
        if ((activeHandlerEntries[i] != null) &&
            (activeHandlerEntries[i].equalsIgnoreCase(HTTP_REQUEST_ELEMENT))) {
          handlerEnabled = true;
          break;
        }
      }
    }

カスタム監査プロバイダを開発する必要があるか

WebLogic Server のデフォルト (つまりアクティブな) セキュリティ レルムには WebLogic 監査プロバイダが含まれています。WebLogic 監査プロバイダは、WebLogic Security フレームワークで内部的に決定された、複数のセキュリティ要求の情報を記録します。また、WebLogic 監査プロバイダはこれらのセキュリティ要求に関連付けられているイベント データと要求の結果も記録します。

WebLogic 監査プロバイダは、その writeEvent メソッドで、コンフィグレーション済みの監査重大度レベルとそのメソッドに渡された AuditEvent オブジェクトに格納されている監査重大度に基づいて監査上の決定を行います。(AuditEvent オブジェクトの詳細については、「監査イベントの作成」を参照)。


注意 :

WebLogic 監査プロバイダのコンフィグレーション済み監査重大度レベルは、WebLogic Server Administration Console で変更できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「WebLogic 監査プロバイダのコンフィグレーション」を参照してください。

一致するものがある場合、WebLogic 監査プロバイダは WL_HOME\yourdomain\ yourserver\logs ディレクトリにある DefaultAuditRecorder.log ファイルに監査情報を書き込みます。コード リスト 10-4 は、DefaultAuditRecorder.log ファイルからの抜粋です。

コード リスト 10-4 DefaultAuditRecorder.log ファイル : 出力例

When Authentication suceeds.[SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS> 
<<<Event Type = Authentication Audit Event><TestUser><AUTHENTICATE>>> Audit 
Record End ####
When Authentication fails.[FAILURE]
#### Audit Record Begin <Feb 23, 2005 11:42:01 AM>  <Severity=FAILURE> 
<<<Event Type = Authentication Audit Event><TestUser><AUTHENTICATE>>> Audit
Record End ####When Operations are invoked.[SUCCESS]
When a user account is unlocked.[SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS> 
<<<Event Type = Authentication Audit Event><TestUser><USERUNLOCKED>>> Audit 
Record End ####
When an Authorization request succeeds.[SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS> 
<<<Event Type = Authorization Audit Event ><Subject: 1
Principal = class weblogic.security.principal.WLSUserImpl("TestUser")
><ONCE><<jndi>><type=<jndi>, application=, path={weblogic}, action=lookup>>>
Audit Record End ####

具体的にいうとコード リスト 10-4 には、ロール マネージャ (セキュリティ ロールを専門に扱う WebLogic Security フレームワーク コンポーネント) による監査イベントの記録が示されています。この記録から、権限のある管理者が証明書サーブレット内の保護されたメソッドにアクセスしたことがわかります。

次の Java 起動オプションを使用すると、コマンドラインで DefaultAuditRecorder.log 用に新しいディレクトリを指定できます。

-Dweblogic.security.audit.auditLogDir=c:\foo 

新しいファイルの場所は、c:\foo\yourserver\DefaultAuditRecorder.log

監査情報を WebLogic Security フレームワークで指定された以外のファイル、または DefaultAuditRecorder.log 以外の出力リポジトリ (異なる名前/場所のシンプル ファイルまたは既存のデータベース) にも書き込む場合、カスタム監査プロバイダを開発する必要があります。

カスタム監査プロバイダの開発方法

WebLogic 監査プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム監査プロバイダを開発することができます。

  1. 適切な SSPI による実行時クラスの作成

  2. WebLogic MBeanMaker による MBean タイプの生成

  3. Administration Console によるカスタム監査プロバイダのコンフィグレーション

適切な SSPI による実行時クラスの作成

実行時クラスを作成する前に、以下の作業が必要です。

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム監査プロバイダの実行時クラスを作成します。

カスタム監査プロバイダの実行時クラスの作成例については、「例 : サンプル監査プロバイダの実行時クラスの作成」を参照してください。

AuditProvider SSPI の実装

AuditProvider SSPI を実装するには、「「Provider」SSPI の目的について」で説明されているメソッドと以下のメソッドの実装を提供する必要があります。

  • getAuditChannel

    public AuditChannel getAuditChannel();
    

    getAuditChannel メソッドは、AuditChannel SSPI の実装を取得します。MyAuditProviderImpl.java という 1 つの実行時クラスの場合、getAuditChannel メソッドの実装は次のようになります。

return this;
If there are two runtime classes, then the implementation of the getAuditChannel method could be:
return new MyAuditChannelImpl;

これは、AuditProvider SSPI を実装する実行時クラスが、AuditChannel SSPI を実装するクラスを取得する場合のファクトリとして使用されるためです。

AuditProvider SSPI と getAuditChannel メソッドの詳細については、「WebLogic Server API リファレンス Javadoc」を参照してください。

AuditChannel SSPI の実装

AuditChannel SSPI を実装する際には、以下のメソッドの実装を提供する必要があります。

  • writeEvent

    public void writeEvent(AuditEvent event)
    

    writeEvent メソッドは、渡された AuditEvent オブジェクト内に指定されている情報に基づいて監査記録を書き込みます。AuditEvent オブジェクトの詳細については、「監査イベントの作成」を参照してください。

AuditChannel SSPI および writeEvent メソッドの詳細については、「WebLogic Server API リファレンス Javadoc」を参照してください。

例 : サンプル監査プロバイダの実行時クラスの作成

コード リスト 10-5 は、サンプル監査プロバイダの実行時クラスである SimpleSampleAuditProviderImpl.java クラスを示しています。実行時クラスには以下の実装が含まれています。

コード リスト 10-5 SimpleSampleAuditProviderImpl.java

package examples.security.providers.audit.simple;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.PrintStream;
import javax.servlet.http.HttpServletRequest;
import weblogic.management.security.ProviderMBean;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AuditChannel;
import weblogic.security.spi.AuditContext;
import weblogic.security.spi.AuditEvent;
import weblogic.security.spi.AuditProvider;
import weblogic.security.spi.SecurityServices;

public final class SimpleSampleAuditProviderImpl implements AuditProvider, AuditChannel
{
   private String      description; // このプロバイダの説明
   private PrintStream log;         // エベントが書き込まれるログ ファイル
   private boolean     handlerEnabled = false;
   private final static String HTTP_REQUEST_ELEMENT =
 "com.bea.contextelement.servlet.HttpServletRequest";
   public void initialize(ProviderMBean mbean, SecurityServices services)
   {
     System.out.println("SimpleSampleAuditProviderImpl.initialize");
     SimpleSampleAuditorMBean myMBean = (SimpleSampleAuditorMBean)mbean;
     description = myMBean.getDescription() + "\n" + myMBean.getVersion();
     String [] activeHandlerEntries = myMBean.getActiveContextHandlerEntries();
     if (activeHandlerEntries != null) {
       for (int i=0; i<activeHandlerEntries.length; i++) {
         if ((activeHandlerEntries[i] != null) &&
             (activeHandlerEntries[i].equalsIgnoreCase(HTTP_REQUEST_ELEMENT))) {
           handlerEnabled = true;
           break;
        }
       }
     }
     File file = new File(myMBean.getLogFileName());
     System.out.println("\tlogging to " + file.getAbsolutePath());
     try {
       log = new PrintStream(new FileOutputStream(file), true);
     } catch (IOException e) {
       throw new RuntimeException(e.toString());
     }
   }

   public String getDescription()
   {
     return description;
   }
   public void shutdown()
   {
     System.out.println("SimpleSampleAuditProviderImpl.shutdown");
     log.close();
   }
   public AuditChannel getAuditChannel() 
   {
     return this;
   }
   public void writeEvent(AuditEvent event) 
   {
     log.println(event);

     if ((!handlerEnabled) || (!(event instanceof AuditContext)))
       return;

     AuditContext auditContext = (AuditContext)event;
     ContextHandler handler = auditContext.getContext();

     if ((handler == null) || (handler.size() == 0))
       return;

     Object requestValue = handler.getValue("com.bea.contextelement.servlet.HttpServletRequest");
     if ((requestValue == null) || (!(requestValue instanceof HttpServletRequest)))
       return;
     HttpServletRequest request = (HttpServletRequest) requestValue;
     log.println("    " + HTTP_REQUEST_ELEMENT + " method: " + request.getMethod());
     log.println("    " + HTTP_REQUEST_ELEMENT + " URL: " + request.getRequestURL());
     log.println("    " + HTTP_REQUEST_ELEMENT + " URI: " + request.getRequestURI());
     return;
   }
}

WebLogic MBeanMaker による MBean タイプの生成

カスタム セキュリティ プロバイダの MBean タイプを生成する前に、以下の作業が必要です。

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム監査プロバイダの MBean タイプを作成します。

  1. MBean 定義ファイル (MDF) の作成

  2. WebLogic MBeanMaker を使用して MBean タイプの生成

  3. WebLogic MBeanMaker を使用して MBean JAR ファイル (MJF) の作成

  4. WebLogic Server 環境に MBean タイプのインストール


    注意 :

    この節で説明する手順はすべて、Windows 環境での作業を想定しています。

MBean 定義ファイル (MDF) の作成

MBean 定義ファイル (MDF) を作成するには、次の手順に従います。

  1. サンプル監査プロバイダの MDF をテキスト ファイルにコピーします。


    注意 :

    サンプル監査プロバイダの MDF は、SampleAuditor.xml という名前です。

  2. MDF で <MBeanType> 要素と <MBeanAttribute> 要素の内容をカスタム監査プロバイダに合わせて修正します。

  3. カスタム属性および操作 (つまり、<MBeanAttribute> および <MBeanOperation> 要素) を MDF に追加します。

  4. ファイルを保存します。


    注意 :

    MDF 要素の構文についての詳細なリファレンスは、「A MBean 定義ファイル (MDF) 要素の構文」に収められています。

WebLogic MBeanMaker を使用して MBean タイプの生成

MDF を作成したら、WebLogic MBeanMaker を使用してそれを実行できます。WebLogic MBeanMaker は現在のところコマンドライン ユーティリティで、入力として MDF を受け取り、MBean インタフェース、MBean 実装、関連する MBean 情報ファイルなどの中間 Java ファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム セキュリティ プロバイダの MBean タイプになります。

MBean タイプの生成手順は、カスタム監査プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

カスタム操作を追加しない場合

カスタム監査プロバイダの MDF にカスタム操作を含めない場合、次の手順に従います。

  1. 新しい DOS シェルを作成します。

  2. 次のコマンドを入力します。

    java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
    

    ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。

    xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。

    -DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。


    注意 :

    バージョン 9.0 以降の WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用して、複数の MDF を格納するディレクトリを指定することができます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり監査プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。

  3. WebLogic MBeanMaker を使用して MBean JAR ファイル (MJF) の作成」に進みます。

カスタム操作を追加する場合

カスタム監査プロバイダの MDF にカスタム操作を含める場合、質問に答えながら手順を進めてください。

MBean タイプを作成するのは初めてですか。初めての場合は、次の手順に従ってください。

  1. 新しい DOS シェルを作成します。

  2. 次のコマンドを入力します。

    java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

    ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。

    xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。

    -DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。


    注意 :

    バージョン 9.0 以降の WebLogic Server では、-DMDFDIR <MDF directory name> オプションを使用して、複数の MDF を格納するディレクトリを指定することができます。旧バージョンの WebLogic Server では、WebLogic MBeanMaker で一度に処理される MDF は 1 つだけです。したがって、MDF (つまり監査プロバイダ) が複数ある場合には、このプロセスを繰り返す必要がありました。

  3. MDF のすべてのカスタム操作に対して、メソッド スタブを使用してメソッドを実装します。

  4. ファイルを保存します。

  5. WebLogic MBeanMaker を使用して MBean JAR ファイル (MJF) の作成」に進みます。

既存の MBean タイプの更新ですか。更新の場合は、次の手順に従ってください。

  1. WebLogic MBeanMaker によって現在のメソッドの実装が上書きされないように、既存の MBean 実装ファイルを一時ディレクトリにコピーします。

  2. 新しい DOS シェルを作成します。

  3. 次のコマンドを入力します。

    java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

    ここで、-DMDF フラグは WebLogic MBeanMaker が MDF をコードに変換すべきであることを示し、xmlFile は MDF (XML MBean の記述ファイル)、filesdir は WebLogic MBeanMaker で作成された MBean タイプの中間ファイルが格納される場所を示します。

    xmlfile が入力されるたびに、新しい出力ファイル群が生成されます。

    -DcreateStubs=true フラグを使用するたびに、既存の MBean 実装ファイルがすべて上書きされます。


    注意 :

    WebLogic MBeanMaker では MDF を一度に 1 つ処理します。したがって、MDF (つまり監査プロバイダ) が複数ある場合には、このプロセスを繰り返す必要があります。

  4. MDF を変更して元の MDF にはないカスタム操作を含めた場合、メソッド スタブを使用してメソッドを実装します。

  5. 完成した、つまりすべてのメソッドを実装した MBean 実装ファイルを保存します。

  6. この MBean 実装ファイルを、WebLogic MBeanMaker が MBean タイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順 3 で filesdir として指定したものです。 (手順 3 の結果として WebLogic MBeanMaker で生成された MBean 実装ファイルがオーバーライドされます)。

  7. WebLogic MBeanMaker を使用して MBean JAR ファイル (MJF) の作成」に進みます。

生成される MBean インタフェース ファイルについて

MBean インタフェース ファイルとは、実行時クラスまたは MBean 実装がコンフィグレーション データを取得するために使用する MBean のクライアントサイド API です。「「Provider」SSPI の目的について」で説明されているように、これは initialize メソッドで使用するのが一般的です。

WebLogic MBeanMaker では、作成済みの MDF から MBean タイプを生成するので、生成される MBean インタフェース ファイルの名前は、その MDF 名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMaker で SampleAuditor MDF を実行すると、SampleAuditorMBean.java という MBean インタフェース ファイルが生成されます。

WebLogic MBeanMaker を使用して MBean JAR ファイル (MJF) の作成

WebLogic MBeanMaker で MDF を実行して中間ファイルを作成し、MBean 実装ファイルを編集して適切なメソッドの実装を記述したら、カスタム監査プロバイダの MBean ファイルと実行時クラスを MBean JAR ファイル (MJF) にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMaker によって自動化されます。

カスタム監査プロバイダの MJF を作成するには、次の手順に従います。

  1. 新しい DOS シェルを作成します。

  2. 次のコマンドを入力します。

    java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
    

    ここで、-DMJF フラグは WebLogic MBeanMaker が新しい MBean タイプを格納する JAR ファイルをビルドする必要があることを示し、jarfile は MJF の名前、<filesdir> は WebLogic MBeanMaker で MJF に JAR 化する対象ファイルが存在する場所です。

    この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfile が指定されていて、エラーが発生しなかった場合には、指定された名前の MJF が作成されます。


    注意 :

    カスタム セキュリティ プロバイダの JAR ファイルを作成する際には、一連の XML バインディング クラスと 1 つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム クラスと Oracle のカスタム クラスとの衝突を防ぐことができます。ネームスペースのデフォルトは vendor です。-targetNameSpace 引数を WebLogicMBeanMaker または関連する WLMBeanMaker ant タスクに渡すことで、このデフォルトを変更できます。

    既存の MJF を更新する場合は、単純に MJF を削除して再生成します。WebLogic MBeanMaker にも -DIncludeSource オプションがあり、それを指定すると、生成される MJF にソース ファイルを含めるかどうかを制御できます。ソース ファイルには、生成されたソースと MDF そのものがあります。デフォルトは false。このオプションは、-DMJF を使用しない場合には無視されます。


生成された MJF は、自らの WebLogic Server 環境にインストールすることも、顧客に配布してそれぞれの WebLogic Server 環境にインストールしてもらうこともできます。

WebLogic Server 環境に MBean タイプのインストール

MBean タイプを WebLogic Server 環境にインストールするには、MJF を WL_HOME\server\lib\mbeantypes ディレクトリにコピーします。ここで、WL_HOME は WebLogic Server の最上位のインストール ディレクトリです。このインストール コマンドによって、カスタム監査プロバイダが「デプロイ」されます。つまり、カスタム監査プロバイダを WebLogic Server Administration Console から管理できるようになります。


注意 :

MBean タイプのインストール用のディレクトリは、デフォルトでは WL_HOME\server\lib\mbeantypes ですが、初めて使用するバージョンが 9.0 の場合、セキュリティ プロバイダは ...\domaindir\lib\mbeantypes からもロードできます。ただし、サーバを起動するときに -Dweblogic.alternateTypesDirectory=<dir> コマンドライン フラグを使用すれば、WebLogic Server が追加ディレクトリで MBean タイプを検索します。<dir> は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Server は常に最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirY の場合、WebLogic Server は最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードしてから、dirX および dirY にある有効なアーカイブをロードします。WebLogic Server に追加ディレクトリで MBean タイプを検索するように指示する際に JAVA セキュリティ マネージャを使用している場合は、weblogic.policy ファイルを更新して、MBean タイプ (その結果としてカスタム セキュリティ プロバイダ) に対する適切なパーミッションを付与することも必要になります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズガイド』の「Java セキュリティを使用しての WebLogic リソースの保護」を参照してください。

カスタム監査プロバイダをコンフィグレーションすることによって (「Configure the Custom Auditing Provider Using the Administration Console」を参照) MBean タイプのインスタンスを作成して、GUI、他の Java コード、または API からそれらの MBean インスタンスを使用することができます。たとえば、WebLogic Server Administration Console を使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他の Java オブジェクトを開発して、そのオブジェクトで MBean をインスタンス化し、それらの MBean から提供される情報に自動的に応答させることもできます。なお、これらの MBean インスタンスをバックアップしておくことをお勧めします。

Administration Console によるカスタム監査プロバイダのコンフィグレーション

カスタム監査プロバイダをコンフィグレーションするということは、監査サービスを必要とするセキュリティ プロバイダがアクセス可能なセキュリティ レルムにカスタム監査プロバイダを追加するということです。

カスタム セキュリティ プロバイダのコンフィグレーションは管理タスクですが、カスタム セキュリティ プロバイダの開発者が行うこともできます。この節では、カスタム監査プロバイダのコンフィグレーション担当者向けの重要な情報を取り上げます。

監査重大度のコンフィグレーション

コンフィグレーション手順では、監査プロバイダの監査重大度を下記の重大度レベルのいずれかに設定する必要があります。

  • INFORMATION

  • WARNING

  • ERROR

  • SUCCESS

  • FAILURE

Security フレームワークの監査イベント

この節では、WebLogic Server の Security フレームワークによってポストされる監査イベントについて説明します。カスタム監査プロバイダを記述する場合、こうした監査イベントを処理できるようにしておく必要があります。この節では、以下の内容について説明します。

付加的な監査情報の渡し

WebLogic セキュリティ プロバイダは適切な AuditEvent インタフェースを実装し、イベントを監査プロバイダにポストします。AuditContext インタフェースも実装する監査イベントでは、ContextHandler を介してより多くの情報を提供できます。

表 10-1 に、weblogic.security.spi サブインタフェースと、どのサブインタフェースが AuditContext インタフェースを実装しているかを示します。

表 10-1 監査イベント

監査イベント名 インタフェース クラス AuditEvent AuditContext

アプリケーション バージョン イベント

weblogic.security.spi.AuditApplicationVersionEvent

認証監査イベント

weblogic.security.spi.AuditAtnEvent

認証監査イベント V2

weblogic.security.spi.AuditAtnEventV2

認可監査イベント

weblogic.security.spi.AuditAtzEvent

証明書パス ビルダ監査イベント

weblogic.security.spi.AuditCertPathBuilderEvent

証明書パス検証監査イベント

weblogic.security.spi.AuditCertPathValidatorEvent

コンフィグレーション監査イベント

weblogic.security.spi.AuditConfigurationEvent

資格マッピング監査イベント

weblogic.security.spi.AuditCredentialMappingEvent

ライフ サイクル イベント

weblogic.security.spi.AuditLifecycleEvent

管理監査イベント

weblogic.security.spi.AuditMgmtEvent

ポリシー監査イベント

weblogic.security.spi.AuditPolicyEvent

ポリシー コンシューマ監査イベント

weblogic.security.service.internal.PolicyConsumerAuditEvent

AuditPolicyEvent

プロバイダ監査記録

com.bea.security.spi.ProviderAuditRecord

ロール コンシューマ監査イベント

weblogic.security.service.internal.RoleConsumerAuditEvent

AuditRoleEvent

ロール デプロイメント監査イベント

weblogic.security.spi.AuditRoleDeploymentEvent

ロール マッピング監査イベント

weblogic.security.spi.AuditRoleEvent


監査イベント インタフェースと監査イベント

WebLogic Security では、weblogic.security.spi パッケージの最上位に 1 つの基本インタフェース (AuditEvent) が定義され、ここから派生したインタフェース群がさまざまなタイプの監査イベントを表します。

以降の節では、Security フレームワークおよびセキュリティ プロバイダが以下の監査イベントをいつポストするかについて説明します。

  • AuditApplicationVersionEvent

  • AuditAtnEventV2

  • AuditAtzEvent

  • AuditCerPathBuilderEvent、AuditCertPathValidatorEvent

  • AuditConfigurationEvent (AuditCreateConfigurationEvent、AuditDeleteConfigurationEvent、AuditInvokeConfigurationEvent、AuditSetAttributeConfigurationEvent)

  • AuditCredentialMappingEvent

  • AuditLifecycleEvent

  • AuditMgmtEvent

  • AuditPolicyEvent (AuditEndPolicyDeployEvent、AuditPolicyDeleteAppEvent、AuditPolicyDeployEvent、AuditPolicyUndeployEvent、AuditResourceProtectedEvent、AuditStartPolicyDeployEvent、PolicyConsumerAuditEvent)

  • AuditRoleDeploymentEvent (AuditStartRoleDeployEvent、AuditEndRoleDeployEvent、AuditRoleUndeployEvent、AuditRoleDeleteAppEvent)

  • AuditRoleEvent (RoleConsumerAuditEvent)

AuditApplicationVersionEvent

アプリケーション バージョンの監査イベントは Security フレームワークによってポストされます。getEventType メソッドを使用すると監査イベントのタイプを取得できます。getEventType から返される実際の監査情報の文字列は String = "Application Version Audit Event" です。

表 10-2 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-2 アプリケーション バージョン イベント

コンポーネント 説明 重大度

Security フレームワーク

このイベントは Security フレームワークにより以下の理由でポストされる。

  • 認可マネージャのアプリケーション バージョンの作成が成功または失敗した。

  • 認可マネージャのアプリケーション バージョンの削除が成功または失敗した。

  • 認可マネージャのバージョン管理されていないアプリケーションの削除が成功または失敗した。

  • ロール マネージャのアプリケーション バージョンの作成が成功または失敗した。

  • ロール マネージャのアプリケーション バージョンの削除が成功または失敗した。

  • ロール マネージャのバージョン管理されていないアプリケーションの削除が成功または失敗した。

  • 資格マネージャのアプリケーション バージョンの作成が成功または失敗した。

  • 資格マネージャのアプリケーション バージョンの削除が成功または失敗した。

  • 資格マネージャのバージョン管理されていないアプリケーションの削除が成功または失敗した。

SUCCESS または FAILURE


AuditAtnEventV2

認証監査イベントは Security フレームワークによってポストされます。getEventType メソッドを使用すると監査イベントのタイプを取得できます。getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = Authentication Audit Event" です。

表 10-3 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-3 認証監査イベント

コンポーネント 説明 重大度

Security フレームワーク

ユーザの認証が成功した後にポストされる。

SUCCESS

Security フレームワーク

認証が失敗した後にポストされる (JAAS ログイン メソッドから LoginException が送出される)。この LoginException は JAAS フレームワークによって送出される場合と、WebLogic Server 認証プロバイダの JAAS LoginModule によって送出される場合がある。

FAILURE

Security フレームワーク

匿名ユーザに対する ID アサーションの後にポストされる。

SUCCESS

Security フレームワーク

ID アサーションが失敗した後にポストされる (ID アサーション メソッドから IdentityAssertionException が送出される)。

FAILURE

Security フレームワーク

ID アサーションが失敗した後にポストされる (コールバックからのユーザ名の取得時に ID アサーション コールバック ハンドラによって IOException が送出される)。

FAILURE

Security フレームワーク

ID アサーションが失敗した後にポストされる (コールバックからのユーザ名の取得時に ID アサーション コールバック ハンドラによって UnsupportedCallbackException が送出される)。

FAILURE

Security フレームワーク

ID アサーションが失敗した後にポストされる (ID アサーション コールバック ハンドラから返されたユーザ名が null または長さゼロである場合)。

FAILURE

Security フレームワーク

ID アサーションが成功した後にポストされる。

SUCCESS

Security フレームワーク

ID アサーションが失敗した後にポストされる。

FAILURE

Security フレームワーク

なりすまし ID (匿名 ID) が成功した後にポストされる。

SUCCESS

Security フレームワーク

なりすまし ID が成功した後にポストされる。

SUCCESS

Security フレームワーク

なりすまし ID が失敗した後にポストされる。

FAILURE

Security フレームワーク

プリンシパル検証が失敗した後にポストされる。

FAILURE


AuditAtzEvent

認可監査イベントは Security フレームワークによってポストされます。getEventType メソッドを使用すると監査イベントのタイプを取得できます。getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = Authorization Audit Event V2 " です。

表 10-4 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-4 認可監査イベント

コンポーネント 説明 重大度

Security フレームワーク

リソースへのアクセスが許可されない場合にポストされる (認可プロバイダから例外が送出される)。

FAILURE

Security フレームワーク

リソースへのアクセスが許可される場合にポストされる。

SUCCESS

Security フレームワーク

リソースへのアクセスが許可されない場合にポストされる。

FAILURE


AuditCerPathBuilderEvent、AuditCertPathValidatorEvent

証明書パス ビルダおよび証明書パス検証の監査イベントは Security フレームワークによってポストされます。getEventType メソッドを使用すると監査イベントのタイプを取得できます。getEventType から返される実際の監査情報の文字列は以下のとおりです。

  • String eventType = "Event Type = CertPathBuilder Audit Event "

  • String eventType = "Event Type = CertPathValidator Audit Event "

表 10-5 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-5 証明書パス ビルダおよび証明書パス検証のイベント

コンポーネント 説明 重大度

Security フレームワーク

証明書パスが正常にビルドされた場合にポストされる。

SUCCESS

Security フレームワーク

証明書パスが正常にビルドされない場合にポストされる。

FAILURE

Security フレームワーク

証明書パスが正常に検証された場合にポストされる。

SUCCESS

Security フレームワーク

証明書パスが正常に検証されない場合にポストされる。

FAILURE


AuditConfigurationEvent

コンフィグレーション監査イベントは Security フレームワークによってポストされます。以下のイベントがポストされます。

  • AuditConfigurationEvent

  • AuditCreateConfigurationEvent (getEventType から返される実際の監査情報の文字列は String CREATE_EVENT = "Create Configuration Audit Event")

  • AuditDeleteConfigurationEvent (getEventType から返される実際の監査情報の文字列は String DELETE_EVENT = "Delete Configuration Audit Event")

  • AuditInvokeConfigurationEvent (getEventType から返される実際の監査情報の文字列は String INVOKE_EVENT = "Invoke Configuration Audit Event")

  • AuditSetAttributeConfigurationEvent (getEventType から返される実際の監査情報の文字列は String SETATTRIBUTE_EVENT = "SetAttribute Configuration Audit Event")

表 10-6 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-6 コンフィグレーション監査イベント

コンポーネント 説明 重大度

WebLogic 管理インフラストラクチャ

WebLogic 管理インフラストラクチャがこのインタフェースを実装し、以下のコンフィグレーション変更イベントについてコンフィグレーション監査イベントをポストできる。

  • 新しいコンフィグレーション アーティファクトを作成する要求が許可されたか、許可されなかった。

  • 既存のコンフィグレーション アーティファクトを削除する要求が許可されたか、許可されなかった。

  • 既存のコンフィグレーション アーティファクトを変更する要求が許可されたか、許可されなかった。

  • 既存のコンフィグレーション アーティファクトに対する操作の呼び出しが許可されたか、許可されなかった。

SUCCESS または FAILURE


AuditCredentialMappingEvent

資格マッピング監査イベントは Security フレームワークによってポストされます。getEventType メソッドを使用すると監査イベントのタイプを取得できます。getEventType から返される実際の監査情報の文字列は String EVENT_TYPE = "Event Type = Credential apping Audit Event" です。

表 10-7 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-7 資格マッピング監査イベント

コンポーネント 説明 重大度

Security フレームワーク

WebLogic Security フレームワークがこのインタフェースを実装し、以下のセキュリティ イベントについて監査イベントをポストできる。

WLS ユーザの資格が要求された。

サブジェクトの資格が要求された。

SUCCESS


AuditLifecycleEvent

AuditLifecycleEvent インタフェースは監査のライフサイクルのイベントをポストするために使用されます。WebLogic Security フレームワークがこのインタフェースを実装し、以下のセキュリティ イベントについて監査イベントをポストできます。

  • フレームワークの監査サービスの起動後。

  • フレームワークの監査サービスの停止前。

getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = AuditLifecycle Audit Event" です。

AuditLifecycleEventType クラスに、サポートされる監査サービス ライフサイクル イベントのタイプが記述されます。有効な値は START_AUDIT および STOP_AUDIT です。

監査プロバイダではこのインタフェースを使用して、監査のライフサイクルのイベントに関する付加的な情報を取得できます。AuditSeverity および AuditLifecycleEventType 属性を使用すると、上記のどちらの監査イベントがポストされたかを判断できます。

AuditMgmtEvent

管理監査イベントは、現在、Security フレームワークおよび提供されているプロバイダのいずれでもポストされません。ただしカスタム セキュリティ プロバイダでは、このインタフェースを実装して、自身が実行するさまざまな管理操作に対し種々の監査イベントをポストできます。

監査プロバイダではこのインタフェースを使用して、管理監査イベントに関する付加的な情報を取得できます。AuditSeverity 属性を使用すると、管理操作が成功したか、失敗したかを判断できます。

AuditPolicyEvent

AuditPolicyEvent は、security フレームワークおよび WebLogic 認可プロバイダによってポストされます。Security フレームワークでは、ポリシーが認可プロバイダに対してデプロイまたはアンデプロイされたときにポリシー監査イベントをポストします。WebLogic Server 認可プロバイダでは、ポリシーを作成、削除、または更新したときにポリシー監査イベントをポストします。getEventType メソッドを使用すると監査イベントのタイプを取得できます。この監査イベント群と、getEventType から返される実際の監査情報の文字列は以下のとおりです。

  • AuditStartPolicyDeployEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = Authorization Start Policy Deploy Audit Event ")。

  • AuditPolicyUndeployEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = Authorization Policy Undeploy Audit Event ")。

  • AuditPolicyDeployEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = Authorization Policy Deploy Audit Event ")。

  • AuditPolicyDeleteAppEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = Authorization Delete Application Policies Audit Event ")。

  • AuditEndPolicyDeployEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = Authorization End Policy Deploy Audit Event ")。

AuditPolicyEvent を実装する PolicyConsumerAuditEvent の場合、getEventType から返される実際の監査情報の文字列は以下のとおりです。

  • String eventType = "Event Type = Policy Consumer Get Handler"

  • String eventType = "Event Type = Policy Consumer Set Policy"

  • String eventType = "Event Type = Policy Consumer Set Unchecked Policy"

  • String eventType = "Event Type = Policy Consumer Done"

表 10-8 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-8 ポリシー監査イベント

コンポーネント 説明 重大度

WebLogic 認可プロバイダ

  • WebLogic 認可プロバイダがこのインタフェースを実装し、以下のセキュリティ イベントについて監査イベントをポストする。

  • セキュリティ ポリシーの作成が成功した。

  • セキュリティ ポリシーの作成が失敗した。

  • セキュリティ ポリシーの削除が成功した。

  • セキュリティ ポリシーの削除が失敗した。

  • セキュリティ ポリシーの更新が成功した。

  • セキュリティ ポリシーの更新が失敗した。

  • アプリケーションのセキュリティ ポリシーの削除が成功した。

  • アプリケーションのセキュリティ ポリシーの削除が失敗した。

SUCCESS または FAILURE


AuditRoleDeploymentEvent

Security フレームワークでは、ロールがロール マッピング プロバイダに対してデプロイまたはアンデプロイされたときにロール デプロイメント監査イベントをポストします。getEventType メソッドを使用すると監査イベントのタイプを取得できます。以下のイベントがポストされます。

  • AuditRoleDeployEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = RoleManager Deploy Audit Event ")。

  • AuditStartRoleDeployEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = RoleManager Start Deploy Role Audit Event ")。

  • AuditEndRoleDeployEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = RoleManager End Deploy Role Audit Event ")。

  • AuditRoleUndeployEvent (getEventType から返される実際の監査情報の文字列は String eventType = "Event Type = RoleManager Undeploy Audit Event ")。

表 10-9 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-9 ロール デプロイメント監査イベント

コンポーネント 説明 重大度

Security フレームワーク

WebLogic Security フレームワークがこのインタフェースを実装し、以下のセキュリティ イベントについて監査イベントをポストできる。

  • ロール マッピング プロバイダに対するセキュリティ ロール デプロイメントが成功した。

  • ロール マッピング プロバイダに対するセキュリティ ロール デプロイメントが失敗した。

  • ロール マッピング プロバイダに対するセキュリティ ロール アンデプロイメントが成功した。

  • ロール マッピング プロバイダに対するセキュリティ ロール アンデプロイメントが失敗した。

  • ロール マッピング プロバイダに対するアプリケーションのセキュリティ ロールの削除が成功した。

  • ロール マッピング プロバイダに対するアプリケーションのセキュリティ ロールの削除が失敗した。

SUCCESS または FAILURE


AuditRoleEvent

WebLogic 認可プロバイダでは、ロールが作成、削除、または更新されたときにロール監査イベントをポストします。getEventType メソッドを使用すると監査イベントのタイプを取得できます。getEventType から返される実際の監査情報の文字列は以下のとおりです。

  • String eventType = "Event Type = RoleManager Audit Event "

  • String eventType = "Event Type = RoleManager Delete Application Roles Audit Event "

AuditRoleEvent を実装する RoleConsumerAuditEvent の場合、getEventType から返される実際の監査情報の文字列は以下のとおりです。

  • String eventType = "Event Type = Role Consumer Get Handler"

  • String eventType = "Event Type = Role Consumer Set Role"

  • String eventType = "Event Type = Role Consumer Done"

表 10-10 で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表 10-10 ロール監査イベント

コンポーネント 説明 重大度

WebLogic 認可プロバイダ

WebLogic 認可プロバイダがこのインタフェースを実装し、以下のセキュリティ イベントについて監査イベントをポストする。

  • セキュリティ ロールの作成が成功した。

  • セキュリティ ロールの作成が失敗した。

  • セキュリティ ロールの削除が成功した。

  • セキュリティ ロールの削除が失敗した。

  • セキュリティ ロールの更新が成功した。

  • セキュリティ ロールの更新が失敗した。

SUCCESS