ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2)
B69533-02
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

44 JBossとAccess Managerの統合

Oracleは、Access ManagerとJBossのスムーズな統合を実現するために、J2EEタイプのJBossエージェントおよびJBossログイン・モジュールを提供します。この章では、この統合の役に立つ次の情報を提供します。

44.1 JBossとAccess Managerの概要

JBossアプリケーション・サーバーは、IBM WebSphereアプリケーション・サーバーおよびSAP NetWeaverアプリケーション・サーバーのオープン・ソースの代替手段です。JBossアプリケーション・サーバーおよび関連サービスは、エンタープライズJavaアプリケーション、Webアプリケーション・サービスおよびポータルの開発とデプロイに使用されるJ2EEプラットフォームです。J2EEは、標準化されたモジュラ・コンポーネントの使用を許可し、Javaプラットフォームによるプログラミングの多くの側面の処理を自動的に可能にします。

JBossとの統合のために、Oracleは次のものを用意しています。


注意:

Access Manager内でのJBossエージェントによる(またはAccess ManagerによるJBossエージェントへの)特別な処理はありません。


JBossとAccess Managerを統合すると次のことが可能になります。

クライアント・インタフェースはありません。詳細は、次の各項を参照してください。

44.1.1 Access Manager JBossエージェントによる構成および処理について

Access Manager JBossエージェントは、JBossサーバー上で動作する完全対応エージェントです。

このJBossエージェントは、Webgateを使用した(またはWebgateを使用しない)Access Manager Webシングル・サインオン・フローをサポートします。認証と認可は、Access Managerポリシー内で定義されたリソースURLに基づいています。JBossエージェントは、OAMサーバーへのすべての着信リクエストを捕捉し、リクエストされたリソースのアクセス権があるかどうかを確認します。リソースがOAMポリシーによって保護されている場合、JBossエージェントは、リソースにアクセスしようとしているユーザーの認証と認可を開始します。

非認証ユーザーが保護されている任意のリソースへのアクセスをリクエストした場合には、JBossエージェントは必ずユーザーを資格証明コレクタにリダイレクトして、ユーザー名とパスワードを求めます。入力されるユーザー名とパスワードは、OAMサーバーによって認証されます。次に、JBossエージェントは、ユーザーのログイン・モジュールを使用して、JBossコンテナにユーザー・セッションを確立します。ログイン・モジュールは、LDAPディレクトリに問合せ、認証されたユーザー・プリンシパルをフェッチしてサブジェクトを設定します。

JBossエージェントは、OAMサーバーとのアクセスおよび通信に関して、Pure Java ASDKクラスおよびAPIに依存します。JBossエージェントは、javax.servlet.Filterインタフェースを実装します。詳細は、 Oracle Fusion Middleware Oracle Access Management Access Manager Access SDK Java APIリファレンスを参照してください。

JBossエージェントは、OAMサーバーの通信詳細、証明書ストアなどを要求します。これらは、次のように構成できます。

  • すべての構成詳細を含むプロパティ・ファイル(このファイルへのパスはフィルタ・パラメータとして設定できます)

  • web.xmlのフィルタ構成内に追加されるプロパティ・ファイルの絶対パス


注意:

Oracle Access Management管理者によって定義されるカスタム・ヘッダーは、これらのメソッドを使用してのみ定義できます。


アプリケーション・フィルタは、異なるロギング・レベル(FATAL、ERROR、WARNING、DEBUG、TRACE)でメッセージをログする必要があります。各レベルは、ログされる情報の重大度を降順で示しています。フィルタは、着信メッセージの詳細トレースを1セットとしてログできる必要があります。JBossエージェントおよびログイン・モジュールは、両方とも様々なログ・レベルのメッセージを備えています。同じログ・ファイル(server.log)のロギングの場合、次のようになります。

<category name="<<Component_code_package>>">
 <priority value="FINEST" class="org.jboss.logging.log4j.JDKLevel"/>
</category>

たとえば、ASDKの場合、前のタグのカテゴリ名は、次に示すようにoracle.security.am.asdkです。

<category name="<<oracle.security.am.asdk>>">
 <priority value="FINEST" class="org.jboss.logging.log4j.JDKLevel"/>
</category>

次の概要では、Access Manager JBossエージェントの機能の処理を説明します。

処理の概要: Access Manager JBossエージェントの機能

  1. OAMサーバーを問合せ、リクエストされたリソースが保護されているかどうかを確認します。

  2. OAMサーバーを呼び出し、認証スキームを取得します。

  3. 保護されているリソースの認証スキームを分析し、リクエストを資格証明コレクタにリダイレクトします。

  4. ユーザー資格証明を認証します。

  5. 認証成功: OAMサーバーから生成される認証トークンをCookieに設定します。

  6. 認証トークン: リクエストを処理する前にトークンの整合性を検証します。保護されているリソースにアクセスすることをユーザーが認可されていることを確認するようにOAMサーバーにリクエストし、それに応じてOAMサーバーからのレスポンスを処理します。

  7. ユーザー・リクエストとOAMサーバーのレスポンスに応じて、JBossエージェントは、ユーザー・リクエストのリダイレクト先を識別し、保護されているリソースへのアクセスを許可または拒否します。

44.1.2 Access Managerログイン・モジュールによる構成および処理について

JAAS準拠のOAMログイン・モジュールは、Access Manager javax.security.*パッケージによって提供される、JAAS APIを使用するプラガブルな認証モジュールです。JAAS準拠のAccess Managerログイン・モジュール・インタフェースを使用すると、クライアントは、認証データをサーバーに渡すことができます。ログイン・モジュールは、JBossサーバーおよびアプリケーションによって構成され、モジュールとJBossアプリケーション・サーバーを統合します。

JAAS準拠のAccess Managerログイン・モジュール実装クラスは次のとおりです。

   public class OAMLoginModule implements LoginModule

このクラスで必要な標準JAASパッケージはjavax.security.*です。ログイン・モジュール・クラスは、JARファイル($JBOSS_HOME/server/default/lib)に格納されます。

ログイン・モジュールは次の2つのモードで動作します。

  • usernamePassword: セキュリティ・アイデンティティと資格証明のペアを形成するユーザー名とパスワードの組合せまたはユーザーと証明書の組合せに基づいてユーザーを認証します。ログイン・モジュールは直接LDAPに問合せしません。かわりに、ログイン・モジュールは、OAM Java ASDKを使用して、OAMサーバーでユーザー資格証明と通信してこれを認証します。ユーザーおよびグループの情報はレスポンスとして取得されます。

  • tokenBased: SSOトークンを検証してサブジェクトを設定します。

JAAS準拠のAccess Managerログイン・モジュールは、ユーザー名、パスワードまたはAccess Managerトークンを使用します。このモジュールは、OAMサーバーで(Access Manager Java ASDK APIを使用して)資格証明またはトークンを認証および検証し、OAMサーバーから取得したユーザーおよびグループの情報をJAASサブジェクトに移入します。

JAAS準拠のAccess Managerログイン・モジュール構成

login-config.xmlファイルは、デフォルトのJBossログイン・モジュール構成ファイルです。このログイン・モジュールは、JAASセキュリティ・ドメイン名(OAMLoginModuleなど)を必要とします。情報は、login-config.xmlに名前付きセキュリティ・ドメインのリストとして格納され、それぞれがそのドメイン内での認証に使用する複数のJAASログイン・モジュールを指定します。たとえば、これを手動で追加してから、JBossサーバーを再起動します。

 <application-policy name="OAMLoginModule">
    <authentication>
      <login-module code="oracle.security.am.agent.common.jaas.login.OAMLoginModule"
        flag="required">
      <module-option name="loginType">tokenBased</module-option>
      <module-option name="configPath">D:/agentconfig</module-option>
      <module-option name="publicAuthnResourceName">/Authen/Basic</module-option>
      <module-option name="rolesParam">OAM_GROUPS</module-option>
      <module-option name="publicAuthzResourceName">/Authen/SSOToken</module-option>
      </login-module>
    </authentication>
</application-policy>

セキュリティ・ドメインおよびデプロイメント記述子

アプリケーションがセキュリティを必要とするときには必ず、ドメイン名を指定して、アプリケーションのJBoss固有のデプロイメント記述子(一方または両方)で使用する必要があります。

  • jboss.xml: アプリケーション用のJBoss固有構成を定義します。

  • jboss-web.xml: Webアプリケーション用のJBossを定義します。このファイルは、セキュリティ・ドメインを宣言し、WEB-INFフォルダに配置する必要があります。

JAAS準拠のOAMログイン・モジュールは、次の概要で説明するように動作します。

プロセスの概要: usernamePasswordモードのJAAS準拠のOAMログイン・モジュール

  1. ログイン情報をフェッチします。

  2. JBossエージェントによって収集された資格証明に基づいて、Access Managerでユーザーを認証します。

  3. サーバー上のクライアントに対してコンテナ・セッションを作成します。

  4. ユーザーIDおよびロールを使用してJAASサブジェクトを設定します。

  5. ログアウト時、セッションでサブジェクトのプリンシパル設定をクリアし、サブジェクトのロールに関連付けられている権限の設定を削除します。

トークン・ベース・モードで発生したログイン・モジュール処理がusernamePasswordモードと似ていても、その違いについて次の概要で説明します。

プロセスの概要: tokenBasedモードのJAASの準拠のOAMログイン・モジュール

  1. ログイン情報をフェッチします。

  2. OAMサーバーから生成されるSSO認証トークンをCookieで検証します。

  3. サーバー上のクライアントに対してコンテナ・セッションを作成します。

  4. 既存のSSOセッション・トークンを使用してフェッチしたユーザーIDおよびロールを使用してJAASサブジェクトを設定します。

  5. ログアウト時、セッションでサブジェクトのプリンシパル設定をクリアし、サブジェクトのロールに関連付けられている権限の設定を削除します。

44.2 統合トポロジ

この項の内容は次のとおりです。

44.2.1 Access Manager JBossエージェントの機能

JBossエージェントは、表44-1に記載したコンポーネントから構成されます。各コンポーネントは、Access ASDKを使用してOAMサーバーと通信します。

表44-1 JBossエージェントの構成

コンポーネント 説明

認証バルブ

すべての着信リクエストに対するJBoss認証フェーズの間に呼び出されます。リソースがアプリケーションのWeb記述子のセキュリティ制約によって保護されるとマークを付けられている場合、認証バルブはHTTPセッションにユーザー・プリンシパルがあるかどうかを確認します。

  • 有効なユーザーが存在する場合: 認証バルブによって、ユーザー・プリンシパルがアプリケーションのWeb記述子のセキュリティ制約を満たしているかどうか評価されます。制約が満たされている場合、リクエストは処理されます。満たされていない場合は、認可失敗メッセージが表示されます。

  • 有効なシングル・サインオンCookie(ObSSOCookie)がある場合(有効なユーザーなし): 認証バルブによって、Access Managerログイン・モジュールを使用してCookieの妥当性が確認されます(さらに、セッションでユーザー・プリンシパルが設定されます)。

  • 有効なシングル・サインオンCookie(ObSSOCookie)がない/有効なユーザーがない場合: リソースがAccess Managerポリシーを使用して保護されているとマークを付けられている場合、バルブによってOAMログイン・ページにリダイレクトされます。

認証フィルタ

JBoss認証フェーズに続く各着信リクエストに対して呼び出されます。各着信リクエストに対して、フィルタはトークンがあるかどうか確認します。

  • トークンがある場合: フィルタはASDKを使用してトークンを検証します。

  • 無効なトークン: フィルタはAccess Managerログイン・ページにリダイレクトします。

Access Managerログイン・モジュール

JBossエージェントによって内部的に使用され、SSOトークンに基づいてユーザーを認証します。

任意のクライアント(スタンドアロンまたはJBossコンテナ内にデプロイされる)は、ログイン・モジュールを使用して、ユーザー名とパスワードまたは有効なトークンに基づいて着信ユーザーを認証できます。


44.2.2 トポロジ: Access ManagerとJBossエージェント

図44-1は、JBossアプリケーション・サーバーにデプロイされた任意のJ2EEアプリケーションに安全にアクセスできる様々なクライアント(ブラウザ、EJBまたはWebサービス)を示しています。JBossエージェントは、このアクセスに対して構成され、JBossアプリケーション・サーバー内にデプロイされます。

図44-1 JBossアプリケーション・サーバーにデプロイされた様々なクライアント

図44-1については周囲のテキストで説明しています。

44.2.3 トポロジ: Webgateを使用して構成されたWebサーバーの背後のJBossエージェント

単独での動作に加えて、JBossエージェントは、図44-2に示すように、WebGateを使用して構成されたOracle HTTP Server(プロキシ)と連携しても動作できます。

図44-2 Oracle HTTP Server Webgateを使用してデプロイされたJBossエージェント

図44-2については周囲のテキストで説明しています。

アプリケーションは、JBossエージェントによって保護されているJBossアプリケーション・サーバーにデプロイされます。また、リクエストは、WebGateを使用して構成されたOracle HTTP Serverインスタンスを介して着信されます。WebGateとJBossエージェントの両方とも、同じAccess Managerデプロイメントに対して構成されます。ここで、JBossエージェントは、Webgateによって転送されるトークンが有効であることを単純に確認し、WebGateによって確立されるアイデンティティを使用するアイデンティティ・アサータの役割を果たします。

44.2.4 サンプル統合トポロジ

図44-3は、Access ManagerとJBossの統合のためにこの章で使用されているトポロジを説明しています。

図44-3 サンプル統合トポロジ

図44-3については周囲のテキストで説明しています。

このデプロイメントの詳細は、「JBoss統合のための環境の準備」で説明します。

ユースケース

図44-3のトポロジは次のことをサポートします。

  • Webアプリケーションの保護

    このユースケースは、アプリケーション固有かつJBoss固有です。これは、JBossエージェントを備えたAccess Manager SSOおよびJBoss上のWebアプリケーションにアクセスするブラウザの認可ポリシーを使用します(ローカルEJB呼び出しがある場合、これを使用)。

    • Access Manager(Host 1)

    • JBossアプリケーション・サーバーにホストされたアプリケーション(Host 2)

  • リッチJavaクライアントを使用した保護されているEJBの起動

    クライアントは、次のようにクライアント・アーキテクチャに応じて様々な方法でEJBにアクセスできます。

    1. JBossコンテナのJAAS準拠のAccess Managerログイン・モジュールを構成して、EJBへのアクセスを保護します。クライアントは、JBoss固有のメカニズムを利用して、Access Manager SSOトークンをJBossコンテナに伝播できます。

      クライアントは、すでに取得したAccess Manager SSOトークンまたはJAAS準拠のAccess Managerログイン・モジュールのいずれかを使用して、ユーザーの資格証明に基づいてSSOトークンを取得できます。

    2. または、リッチJavaクライアントに対して公開されているカスタムHTTP Webサーバー・ベースのAccess Manager認証サービスを使用してAccess Manager SSOトークンを取得できます。

  • Webサービス・プロバイダ(WSP)としてのEJB呼び出し

    JAAS準拠のAccess Managerログイン・モジュールは、Webサービス・プロバイダ側で構成して、ユーザー名とパスワードまたはSSOトークンを検証できます。

    代替手段: Webサービス消費(WSC)でユーザー名しか利用できない場合、SAMLトークンを要求するWSPが必要であり、そのトークンをユーザー名をアサートするセキュリティ・トークン・サービスによって発行します。続いて、ユーザー名のみの拡張アサーション機能によってJAAS準拠のAccess Managerログイン・モジュールを呼び出します。

    • JAAS準拠のAccess Managerログイン・モジュールを使用したEJBアクセスの保護(Host 2)

    • JBossサーバーへのEJBアプリケーションのホスト(Host 2)

    • Access Manager(Host 1)

この章の後半では、この統合を完了する方法を説明します。

44.3 JBoss統合のための環境の準備

次の手順では、JBossアプリケーション・サーバーとAccess Managerを統合するための環境の準備方法を説明します。これには次のものが含まれます。

JBossアプリケーション・サーバーとAccess Managerの統合を準備するには:

  1. 次のサイトで最新のサポート情報を確認します。

    http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
    
  2. Host 1:

    1. 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、Access Managerをインストールします。

  3. Host 2:

    1. JBossインストレーション・ガイドの説明に従って、JBoss 5.1.0アプリケーション・サーバーをインストールします。

    2. JBossのserver.xmlを編集して、<Engine name="jboss.web" defaultHost="localhost">を<Engine name="jboss.web" defaultHost="0.0.0.0">に変更します。次に例を示します。

      JBoss_install_directory\server\default\deploy\jbossweb.sar\server.xml

      次から

      <Engine name="jboss.web" defaultHost="localhost">

      次へ

      <Engine name="jboss.web" defaultHost="0.0.0.0">
       
      
  4. Host 2: 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』の説明に従って、Access Manager Access SDKをインストールします。

  5. Host 2: OAM JBossエージェントをインストールします。次に例を示します。

    1. oam-j2eeagent.zipを抽出します。

      次から

      /agentconfig/oam_config.propertiesファイル

    2. oam-authenticatorvalve.jarj2eeagent.jarをコピーします。

      次へ

      JBoss_install_directory\server\default\lib
      
  6. 「JBoss固有のリソースの保護」に進みます。

44.4 JBoss固有のリソースの保護

このタスクは、JBoss固有で、すべてのJBoss統合ユースケース(アプリケーション、WebサーバーまたはEJBの保護)で必要です。

この項では、エージェント登録の作成方法およびリソースを追加して認可ポリシーを構成し、Access Manager JBossエージェントで使用する方法を説明します。詳細は、次の章または項を参照してください。

44.4.1 自動ポリシー作成を使用したJBossエージェントの登録

このタスクでは、ここで説明するOracle Access Managementコンソールまたは『Oracle Fusion Middleware Oracle Access Management管理者ガイド』で説明されているリモート登録のいずれかを使用できます。

Access ManagerとJBoss Agentの通信には、オープン、簡易または証明書のセキュリティ・モードを使用できます。簡易モードまたは証明書モードを使用するようにJBossエージェントを構成すると、Java ASDKは同じモードで動作します。登録中、新しいファイル・システム・ディレクトリがOracle Access Managementコンソール・ホスト(AdminServer)のエージェント用に作成されます。登録後、アーティファクトを次のエージェントのディレクトリ・パスにコピーします。

  • ObAccessClient.xml

  • password.xml(簡易モードまたは証明書モードのみ)

  • oamclient-keystore.jks(手順を使用して作成。『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照)

次の手順で、変数を使用している環境の値に置き換えます。この例では、証明書モードを使用します。使用しているデプロイメントとは異なる場合があります。


関連項目:

第22章


10g OAMエージェントの新規登録を作成するには:

  1. Oracle Access Managementコンソール(host 1)に移動し、管理者の資格証明を使用してログインします。次に例を示します。

    https://host1:port/oamconsole 
    User: adminuserID
    Password ********
    
  2. 「ようこそ」ページのSSOエージェントパネルから、「新規OAM 10gエージェント」をクリックして新規ページを開きます。

  3. 「OAMエージェントの作成」ページで、次の項目(および必要な詳細)を入力し、このOAMエージェントを登録します。次に例を示します。

    • 名前: JBoss

    • セキュリティ: 証明書

    • ユーザー定義パラメータ

        logoutRedirectUrl=http://OAM_Server.domain.com:14100/oam/server/logout    
    
  4. 「保護されているリソース・リスト」: この表で「追加」(+)ボタンをクリックして、デフォルトの認証ポリシーおよび認可ポリシーで保護するリソースを入力します。

    /Authen/Basic
    /Authen/SSOToken
    
  5. 「ポリシーの自動作成」: 新規ポリシーおよびアプリケーション・ドメインの作成を確認します。

  6. 「適用」をクリックして、登録を送信します。

  7. 「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。

  8. ナビゲーション・ツリーで、エージェント名がリストされていることを確認します。

  9. ObAccessClient.xmlをAdminServerからJBossエージェント・インストール・ディレクトリ・パスにコピーします。

    コピー元: WLS_HOME/middleware/user_projects/domains/base_domain/output/AGENTNAME

    コピー先: D:\agentconfig

  10. 「JBossリソース保護のためのカスタム・ポリシーの作成」に進みます。

44.4.2 JBossリソース保護のためのカスタム・ポリシーの作成

このタスクでは、カスタム認可ポリシーを作成し、ユーザー・グループをヘッダー変数として返すというレスポンスを追加します。たとえば、レスポンスにOAM_GROUPS(値$user.groupsを含む)という名前を付けます。


注意:

このカスタム認可ポリシーでは、このポリシーの単一の目的が認可ユーザーにレスポンスを提供することであるため、成功と失敗のリダイレクトURLは不要です。リダイレクトURLが提供されても、JBossエージェントまたはログイン・モジュールのロジックの処理ではリダイレクトは発生しません。



関連項目:

第17章


JBossアプリケーション・ドメインがコンソールで開いている場合にはステップ1をスキップします。

JBossエージェント固有のリソースを保護するためのカスタム認可ポリシーを作成するには:

  1. Oracle Access Managementコンソールの「ポリシー構成」タブから、JBossの「アプリケーション・ドメイン」を開きます。


    「アプリケーション・ドメイン」
    JBoss
  2. 認可ポリシー:

    1. 「認可ポリシー」ノードをクリックし、「作成」(+)ボタンをクリックします。

    2. 「サマリー」タブの「名前」フィールドに一意の名前を入力します。次に例を示します。

      カスタム認可ポリシー

  3. リソースの追加: JBossエージェント固有のリソースは、エージェント登録中に定義されました。

    1. 「認可ポリシー」ページの「リソース」タブをクリックします。

    2. 「追加」(+)ボタンをクリックします。

    3. 「検索」ボタンをクリックします。

    4. リストからURLを選択し、「選択済の追加」をクリックします。

      /Authen/Basic
      
    5. ステップaからdを繰り返して次の項目を追加します。

      /Authen/SSOToken
      
    6. 適用」をクリックします。

  4. レスポンスの追加: 「レスポンス」タブをクリックし、「追加」(+)ボタンをクリックし、次の手順を実行します。

    • 「名前」フィールドに、このレスポンスの一意の名前(OAM_GROUPS)を入力します。

    • 「タイプ」リストから、レスポンス・タイプ(「ヘッダー」)を選択します。

    • 「値」フィールドに、このレスポンスの値を入力します。例: $user.groups

  5. 「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。

  6. 使用中のデプロイメントに適切なトピックに進みます。

44.5 JBossエージェントによるWebアプリケーションの保護

この項では、JBossエージェントでWebアプリケーションを保護するために必要な次のタスクを説明します。

前提条件

通常どおりにアプリケーションをデプロイします。

44.5.1 JBossエージェントの構成プロパティの作成

このタスクでは、Jbossエージェント登録アーティファクトをAdminServerからJBossホストにコピーし、後で参照するフィルタ構成プロパティ・ファイルを作成します。


注意:

JBossエージェントは、登録したJBossエージェントと同じモードで動作する11g Java ASDKに依存します。


JBossエージェントには、多くの重要なプロパティを定義する構成ファイル(oam_config.properties)が必要です。これらには、エージェントの登録アーティファクトへのファイル・システム・パス(ObAccessClient.xml)、JBossサーバーのログイン構成ファイルで定義されるセキュリティ・ドメイン、認証中にJBossエージェントに返されるパラメータと値およびリクエストにauthTokenがあるかどうかを確認するオプションの属性が含まれます。

JBossエージェントの構成プロパティを作成するには:

  1. ガイドとして次のサンプルを使用して、oam_config.propertiesという名前のJBossエージェント構成ファイルを作成します。

    ##Path of the folder containing the ObAccessClient.xml
    configPath=D:\\agentconfig
    
    ##Name of the security domain as configured in JBoss's login-config.xml
    realmName=oamrealm
    
    ##Optional. If not specified then defaults to /Authen/Basic
    ##publicAuthnResourceName=/Authen/Basic 
    
    ##Optional. If not specified then defaults to http
    ##publicAuthnResourceType=http
    
    ##Optional. If not specified then defaults to GET
    ##publicAuthnResourceOperation=GET
    
    ##Optional. If not specified then defaults to /Authen/SSOToken
    ##publicAuthzResourceName=/Authen/SSOToken
    
    ##Optional. If not specified then defaults to http
    ##publicAuthzResourceType=http
    
    ##Optional. If not specified then defaults to GET
    ##publicAuthzResourceOperation=GET
    
    rolesParam=OAM_GROUPS
    
    ##Optional. This attribute is responsible to check whether the credential in  
    ##the subject / callback handler is an authn token. Defaults to authnToken.
    authToken=authToken
    
    ####################################
    ##### OAM logout related properties #####
    ####################################
    ##Host name of the OAM 11g Server
    
    ##Managed server port number of the OAM 11g Server
    
  2. oam_config.propertiesをJBossホストに保存します。

    /agentconfig/oam_config.properties
    
  3. 「認証バルブの構成」に進みます。

44.5.2 認証バルブの構成

この手順を実行して、認証バルブを構成する必要があります。このタスクの実行には2つの方法があります。使用中の環境に最適な方法を選択します。

認証バルブをcontext.xmlに追加するには:

  1. JBossエージェントを編集するために、次の場所にあるcontext.xmlファイルを探して開きます。

    JBoss_install_dir\server\default\deploy\jbossweb.sar\context.xml
    
  2. 次のバルブ・エントリを追加してファイルを保存します。

    <Valve className="oracle.security.am.agent.common.authenticator.OAMAuthenticatorValve" configFile="<full_path_to_oamagent_config_properties_file> " />
    
  3. 「アプリケーションのweb.xmlファイルへのフィルタのマッピング」.

グローバル・ユースのために認証バルブをcontext.xmlに追加するのではなく、かわりに次のタスクを実行してcontext.xmlをアプリケーションのデプロイメントの一部として追加できます。

バルブをアプリケーションのデプロイメントに追加するには:

  1. 新規のcontext.xmlファイルを作成して、これをweb.xmlを含むWEB-INFに格納します。

    JBoss_install_dir\server\default\deploy\jbossweb.sar\context.xml
    
  2. 次のバルブ・エントリを追加します。

    <?xml version="1.0" encoding="UTF-8"?>
     
    <Context privileged="true">
       <Valve className="oracle.security.am.agent.common.authenticator.OAMAuthenticatorValve" configFile="<full_path_to_oamagent_config_properties_file> " />
    
    </Context>
    
  3. アプリケーションを再デプロイします。

  4. 「アプリケーションのweb.xmlファイルへのフィルタのマッピング」.

44.5.3 アプリケーションのweb.xmlファイルへのフィルタのマッピング

この手順では、この統合のフィルタ・マッピングをアプリケーションのweb.xmlに追加します。フィルタの構成プロパティ・ファイルの名前も追加します。

フィルタ・マッピングをweb.xmlに追加するには:

  1. アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。

    my_app/WEB-INF/web.xml  
    
  2. 次のフィルタ・マッピングをアプリケーションのweb.xmlに追加します。次に例を示します。

    <filter>
      <filter-name>OAMFilterAgent</filter-name> 
      <filter-class>
        oracle.security.am.agent.common.filter.OAMAuthenticationFilter
      </filter-class>
      <init-param>
        <param-name>configFile</param-name>
        <param-value>D:/oam_config.properties</param-value>
      </init-param>
    </filter>
    <filter-mapping>
      <filter-name>OAMFilterAgent</filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>
    
  3. ファイルを保存します。

  4. Access Managerポリシーを使用するためのJBossログイン・モジュールの構成に進みます。

44.5.4 Access Managerポリシーを使用するためのJBossログイン・モジュールの構成

この手順では、Access Managerポリシーを使用するためにJBossに必要なログイン・モジュール・エントリを説明します。

フィルタ・マッピングをweb.xmlに追加した後、アプリケーションを再デプロイし、JBossサーバーを起動します。


注意:

-b 0.0.0.0を使用してJBossサーバーを起動すると、ユーザーは、localhost / 127.0.0.1ではなくホスト名を使用してサーバーにアクセスできます。このパラメータを使用しないと、localhost / 127.0.0.1またはホスト名を使用してJBossサーバーにアクセスできます。


JBossでOAMポリシーを使用できるようにするログイン・モジュールを構成するには:

  1. login-config.xmlファイルを探して開きます。

    JBoss_install_dir\server\default\conf\login-config.xml   
    
  2. 次のように、ログイン・モジュールの新しいエントリを追加します。

    <application-policy name="oamrealm">
      <authentication>
        <login-module code="oracle.security.am.agent.common.jaas.login.OAMLoginModule"       flag="required">
          <module-option name="loginType">tokenBased</module-option>
          <module-option name="configPath">D:/agentconfig</module-option>
          <module-option>       
          <module-option name="publicAuthnResourceName">/Authen/Basic</module-option>
          <module-option name="rolesParam">OAM_GROUPS</module-option>
          <module-option name="publicAuthzResourceName">/Authen/SSOToken</module-option>
        </login-module>
      </authentication>
    </application-policy>
    
  3. アプリケーションをデプロイします。

  4. 次のコマンドを使用して、次のようにJBossを起動します。

    JBoss_install_dir\bin\run –b 0.0.0.0 
    

    「localhostではなくホスト名にアクセスするためのJBossサーバーの構成」を参照してください。

44.6 localhostではなくホスト名にアクセスするためのJBossサーバーの構成

この手順はオプションです。localhost/127.0.0.1ではなくホスト名を使用してJBossサーバーにアクセスする場合のみこれを実行します。


注意:

-b 0.0.0.0を使用してJBossサーバーを起動すると、ユーザーは、localhost / 127.0.0.1ではなくホスト名を使用してサーバーにアクセスできます。このようにしないと、localhost / 127.0.0.1またはホスト名を使用してJBossサーバーにアクセスできます。


ホスト名を使用してJBossサーバーにアクセスするには:

  1. JBossサービス・ホスト上で、次のパスにあるserver.xmlファイルを探します。

    JBoss_install_dir\server\default\deploy\jbossweb.sar\server.xml 
    
  2. server.xmlを編集して、デフォルトのホストを次のように変更します。

    変更前:

    <Engine name="jboss.web" defaultHost="localhost">
    

    変更後:

    <Engine name="jboss.web" defaultHost="defaultHost="0.0.0.0">
    
  3. server.xmlを保存します。

44.7 EJBを保護するためのログイン・モジュールの構成

このタスクは、次のトピックで説明するように、サーバー側とクライアント側の両方の構成と関連します。

44.7.1 EJBを保護するためのサーバーの構成

サーバー側では、セキュリティ・ドメイン注釈をEJBに追加し、記述子をjboss.xmlに追加する必要があります。新規エントリもログイン・モジュールのJBossサーバー構成ファイルに追加します。

ロールに基づいてEJB、WebアプリケーションまたはWebサービスを保護するには、次のようにlogin-config.xmlに追加の構成を行う必要があります。

<module-option name="rolesParam">OAM_GROUPS</module-option>

ここで、OAM_GROUPSは、「JBossリソース保護のためのカスタム・ポリシーの作成」で構成したレスポンスです。

前のステップで構成したエージェントをまたは新規エージェントのいずれかを使用できます。


注意:

新規エージェントを使用するには、ObAccessClient.xmlをJBossホスト上の/agentディレクトリから別のディレクトリにコピーする必要があります。


EJBを保護するためにサーバーを構成するには:

  1. ObAccessClient.xmlを次のようにコピーします(どちらか)。

    • コピー元: WLS_HOME/middleware/user_projects/domains/base_domain/output/agent_name.

    • コピー先: JBossホスト上のディレクトリ

  2. @SecurityDomain("oamrealm")注釈をEJBに追加します。たとえば、EJBクラスがDemoEJBの場合、次の注釈をコード・レベルで追加する必要があります。

    import org.jboss.security.annotation.SecurityDomain;
    
    @SecurityDomain("oamrealm")
    public class DemoEJB{ ... }
    
  3. オプション: 次の記述子をjboss.xmlファイルに追加してセキュリティ・ドメインを定義します。

    META-INF/jboss.xml
    
    <jboss>
        <security-domain>java:/jaas/myother</security-domain>
    </jboss> 
    

    注意:

    セキュリティ・ドメイン注釈に関連付けられた名前は、ステップ4の説明に従って、使用するログイン・モジュールで指定する必要があります。関連項目: Access Managerポリシーを使用するためのJBossログイン・モジュールの構成


  4. JBossサーバーのログイン構成: ログイン・モジュール・クラス名のエントリを追加します。これは、ログイン・メカニズムの一部である必要があります。

    JBoss_install_dir\server\default\conf\login-config.xml

    <application-policy name="EJBRealm"> 
      <authentication>
        <login-module code="oracle.security.am.agent.common.jaas.login.OAMLoginModule"
          flag="required">
          <module-option name="loginType">tokenBased</module-option>
          <module-option name="configPath">D:/agentconfig</module-option>
          <module-option name="rolesParam">OAM_GROUPS</module-option>
          <module-option name="publicAuthnResourceName">/Authen/Basic</module-option>
          <module-option name="publicAuthzResourceName">/Authen/SSOToken</module-option>
        </login-module>
      </authentication>
    </application-policy>
    
  5. アプリケーションをデプロイします。

  6. 次のコマンドを使用してJBossを起動します。

    JBoss_install_dir\bin\run –b 0.0.0.0 
    

    「localhostではなくホスト名にアクセスするためのJBossサーバーの構成」を参照してください。

  7. tに進みます。

44.7.2 EJBを保護するためのクライアント側の構成

この手順では、クライアント・ログイン構成ファイルの作成方法を説明します。

EJBを保護するためにログイン・モジュールのクライアント側を構成するには:

  1. ObAccessClient.xmlを次のようにコピーします(どちらか)。

    • 新規エージェント: MW_HOME/middleware/user_projects/domains/base_domain/output/agent_nameからエージェント・ホスト上のフォルダ。

    • 既存のエージェント: JBossホスト上の場所からエージェント・ホスト上の別のディレクトリ。

  2. クライアント・ホスト上で、次のようにクライアント・ログイン構成テキスト・ファイルを作成します。

    oamauth {
       oracle.security.am.agent.common.jaas.login.OAMLoginModule required
       loginType="usernamePassword   "
       configPath="D:/agentconfig"
       publicAuthzResourceName="/Authen/Basic"
       publicAuthzResourceName="/Authen/SSOToken";
    };
    
  3. 次のコードをエントリに追加し、ログイン・モジュールを構成してアイデンティティをEJBコンテナに伝播します。

    propagate {
       org.jboss.security.ClientLoginModule required
       restore-login-identity="true";
    };
    
  4. ファイルを保存します。


    注意:

    リッチ・クライアントからEJBを起動している間にステップ5を実行し、Access Managerによって認証が実行され(Pure Java ASDKを使用)、資格証明をEJBアプリケーション・サーバーに伝播します。


  5. リッチ・クライアント: EJBをクライアント側から起動する前に次のコードをクライアント・コードに追加します。

    System.setProperty("java.security.auth.login.config", authFile);
    MyCallbackHandler handler = new MyCallbackHandler(<USERNAME>,<PASSWORD>);
    LoginContext lc = new LoginContext("oamauth", handler);
    lc.login();
    //Fetch the private credentials of type String.class
    Set<String> set = lc.getSubject().getPrivateCredentials(String.class);
    
    //Set the SSO Token in callback handler along with the username
    handler = new MyCallbackHandler(<USERNAME>, set.iterator().next());
    LoginContext lc2 = new LoginContext("propagate", handler);
    lc2.login();
    

44.8 Webサービスへのアクセスを保護するためのログイン・モジュールの構成

Webサービス・プロバイダは、Webサービスの呼び出しにセキュリティを適用するために、着信WebサービスSOAPメッセージを捕捉して処理する様々なメカニズムの1つを提供する場合があります。

このタスクは、次のトピックで説明するように、サーバー側とクライアント側の両方の構成と関連します。

44.8.1 Webサービスへのアクセスを保護するためのサーバーの構成

Webサービスへのアクセスを保護するためのサーバーの構成には、エージェント登録アーティファクトをコピーし、Webサービス・セキュリティのためのAccess Manager JAAS準拠のログイン・モジュールをJBossサーバーのログイン構成ファイルに追加することが含まれます。

前のステップで構成したエージェントをまたは新規エージェントのいずれかを使用できます。新規エージェントを使用するには、ObAccessClient.xmlをJBossホスト上の/agentディレクトリからこのホスト上の別のディレクトリにコピーする必要があります。

Webサービスの作成には複数のフレームワークの任意のものを使用できるため、Webサービスを構成またはデプロイする特定の詳細を示すことはしません。JBossコンテナ上にデプロイされるWebサービスのプロバイダは、次の一般的なガイドラインに従う必要があります。

  • OAM SSOトークンを取得するためにクライアントによって挿入された特定のヘッダーを探す機能を組み込む。

  • OAM SSOトークンを検証するためにOAM JAASログイン・モジュールを使用する。

  • 任意のEJBセッションBeanがWebサービスとして公開されている場合、JBoss固有のJAASログイン・モジュールClientLoginModuleを使用して、OAMトークンをEJBコンテナに伝播する必要がある。

Webサービスへのアクセスを保護するためにサーバーを構成するには:

  1. ObAccessClient.xmlを次のようにコピーします(どちらか)。

    • 既存のエージェント: JBossホスト上の場所からエージェント・ホスト上の別のディレクトリ。

    • 新規エージェント: MW_HOME/middleware/user_projects/domains/base_domain/output/agent_nameからエージェント・ホスト上の別のディレクトリ。

  2. Webサービス(理想的には.wsddファイル)を使用してSOAPハンドラを登録します。

    WSスタブが作成されアプリケーションのWEB-INFフォルダ内に配置されるときに、.wsddファイルが生成されます。

  3. JBossサーバーのログイン構成ファイルを編集して、次のようにWebサービス・セキュリティのためにAccess Manager JAAS準拠のログイン・モジュールのエントリを追加します。

    JBoss_install_dir\server\default\conf\login-config.xml

    <application-policy name="WSRealm">
      <authentication>
        <login-module code="oracle.security.am.agent.common.jaas.login.OAMLoginModule"
          flag="required">
          <module-option name="loginType">tokenBased</module-option>
          <module-option name="configPath">D:/agentconfig</module-option>
          <module-option name="rolesParam">OAM_GROUPS</module-option>
          <module-option name="publicAuthnResourceName">/Authen/Basic</module-option>
          <module-option name="publicAuthzResourceName">/Authen/SSOToken</module-option>
        </login-module>
      </authentication>
    </application-policy>
    
  4. JBossサーバーのログイン構成ファイルを保存します。

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

  6. 次のコマンドを使用してJBossを起動します。

    JBoss_install_dir\bin\run –b 0.0.0.0 
    

    「localhostではなくホスト名にアクセスするためのJBossサーバーの構成」を参照してください。

  7. 「Webサービスへのアクセスを保護するためのクライアントの構成」に進みます。

44.8.2 Webサービスへのアクセスを保護するためのクライアントの構成

このタスクでは、OAMサーバーとのユーザー認証を構成し、SOAPメッセージに対して、SSOトークンを含むセキュリティ・ヘッダー・エレメントを作成します。


注意:

理想的には、このステップは、Webサービス・メソッドを呼び出す前に実行します。つまり、このコードは、Webサービスの呼び出し中にクライアント・コードに追加する必要があります。


Webサービスへのアクセスを保護するためにクライアントを構成するには:

  1. WSクライアント上: OAMサーバーとのユーザー認証を実行し、SOAPメッセージに対して、SSOトークンを含むセキュリティ・ヘッダー・エレメントを作成します。

  2. 通常どおりにWebサービスを呼び出します。

  3. 「JBossエージェントおよびログイン・モジュールのためのロギングの構成」に進みます。

44.9 JBossエージェントおよびログイン・モジュールのためのロギングの構成

JBossエージェントおよびログイン・モジュールは、両方とも様々なログ・レベルでログイン・メッセージを備えています。これらのメッセージをログするには、この手順の説明に従ってjboss-log4j.xmlファイルを編集する必要があります。

JBossエージェントおよびログイン・モジュールのためにロギングを構成するには:

  1. 次のパスで、jobss-log4j.xmlファイルを探します。

    $JBOSS_HOME/server/default/conf/jboss-log4j.xml
    
  2. エディタでファイルを開き、次の情報を追加します。

      <appender name="J2EEAGENT" class="org.jboss.logging.appender.DailyRollingFileAppender">
         <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
         <param name="File" value="${jboss.server.log.dir}/j2eeagent.log"/>
         <param name="Append" value="true"/>
         <param name="DatePattern" value="'.'yyyy-MM-dd"/>
         <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d %-5p [%c] (%t) %m%n"/>
          </layout>
       </appender>
    
      <category name="oracle.security.am.agent.common">
        <appender-ref ref="J2EEAGENT"/>
      </category>
    
       <root>
         ...
          <appender-ref ref="J2EEAGENT"/>
       </root>
    
  3. ファイルを保存します。

44.10 構成の検証

構成を検証する特定のメカニズムはありません。ただし、構成が正しく機能しているかどうかを手動で判定できます。

構成を検証するには:

  1. 認可ユーザー: Webサービスの呼び出しを認可されたユーザーに対して生成されたSSOトークンを提供してWebサービスを手動で呼び出します。

    • 成功: 認可ユーザーはアクセスを付与されます。

    • 失敗: 認可ユーザーはアクセスを拒否されます。

    • エラー: 構成は正しくありません。OAMサーバー・ログでログイン・モジュールによって生成されたエントリを確認します。

  2. 未認可ユーザー: Webサービスを手動で呼び出し、未認可ユーザー用のSSOトークンを提供します。

    • 成功: 未認可ユーザーはアクセスを拒否されます。

    • 失敗: 未認可ユーザーはアクセスを付与されます。

    • エラー: エラーが発生した場合、構成は正しくありません。OAMサーバー・ログでログイン・モジュールによって生成されたエントリを確認します。