プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11g リリース2 (11.1.2.3) for All Platforms
E61950-08
目次へ移動
目次

前
次

15.11 リモート登録およびリソース保護の検証

エージェント・タイプに関係なく、エージェントの登録を検証できます。

Oracle Access Managementコンソールを使用してタスクを実行するには、帯域内の管理者である必要があります。帯域外の管理者は、リモートの認証およびアクセスをテストする必要があります。

15.11.1 Oracle Access Managementコンソールを使用したエージェント登録の検証

帯域内の管理者のみがエージェント登録を検証できます。

  1. Oracle Access Managementコンソールで、エージェントの登録を検証します

    1. Oracle Access Managementコンソールの「アプリケーション・セキュリティ」で「エージェント」の詳細を確認します。

    2. 更新したエージェント構成ファイルが、適切な場所に配置されていることを確認します(「OAMエージェントのリモート登録の実行」を参照)。

  2. 共有コンポーネントのホスト識別子を検証しますOracle Access Managementコンソールでホスト識別子が定義されていることを確認します。

  3. アプリケーション・ドメインを検証します。「ポリシー構成」タブで、登録されたエージェントに基づいて名付けられた新しいアプリケーション・ドメインがあることを確認します。アプリケーション・ドメインのリソースには、ホスト識別子を関連付ける必要があります。

  4. 「リモート登録後の認証およびアクセスの検証」に進みます。

15.11.2 リモート登録後の認証およびアクセスの検証

登録後は、AdminServerまたはOAMサーバーを再起動しなくても、適切な認証によって、保護されたリソースにアクセスできる必要があります。

帯域内および帯域外のどちらの管理者も、次の手順を使用して、登録およびポリシーが適切であることを検証できます。

ここでの手順は、登録、認証および認可が適切に構成および動作していることを確認するいくつかの方法を示しています。手順は、すべてのエージェント・タイプでほぼ同じです。

  1. 登録されたOAMエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します(認証リダイレクトURLが適切に指定されたことが証明されます)。次に例を示します。
    http://exampleWebserverHost.sample.com:8100/resource1.html
    
  2. ログイン・ページで、求められた場合に有効なユーザー名およびパスワードを入力し、「ログイン」をクリックします。
  3. OAM固有のCookieがブラウザ・セッションに作成されていることを確認します。次に例を示します。

    ObSSOCookie:

    Set-Cookie: 
    ObSSOCookie=GGVEuvjmrMe%2FhbItbjT24CBmJo1eCIfDIwQ1atdGdnY4mt6kmdSekSFeAAFvFrZZZ
    xDfvpkfS3ZLZFbaZU2rAn0YYUM3JUWVYkYFwB%2BBK7V4x%2FeuYHj%2B8gwOyxhNYFna3iSx1MSZBE
    y51KTBfsDYOiw6R%2BCxUhOO8uZDTYHI3s0c7AQSyrEiQTuUV3nv1omaFZlk1GuZa4J7ycaGbIUyqwX
    rM0cKuBJNd6sX1LiRj9HofYQsvUV7ToqeAOpDS7z9qs5LhqU5Vq60bBn12DTX6zNX6Lcc0L5tVwvh7%
    2BnOAkz2%2BoDkLs%2BBTkeGcB3ppgC9;httponly; path=/; domain=.example.com;
    

    OAM_ID Cookie:

    Set-Cookie: 
    OAM_ID=v1.0~0~E1EBBC9846E09857060A68E79AEEB608~AA79FC43C695162B6CDE3738F40E94DA
    6408D58B879AC3B467EBBD4800743C899843672B3511141FFABCF58B2CDCB700C83CC734A913625
    7C4ABDA6913C9EF5A4E05C5D03D3514F2FECACD02F1C1B9314D76B4A68CB7A8BE42AEB09AFB98B8
    EB; path=/; HttpOnly
    
  4. 次に進みます。
    • 成功: 正しく認証され、リソースへのアクセスが付与された場合、構成が正常に動作します。詳細な検証については、ステップ5から12に進みます。

    • 失敗: ログイン中にエラーを受け取った場合またはリソースへのアクセスが拒否された場合、次の項目を確認します。

      • ログイン・エラー: 有効なユーザーIDおよびパスワードが入力されていることを確認します。

      • 使用不能なリソース: リソースが使用できることを確認します。

      • 不正なリダイレクトURL: Oracle Access ManagementコンソールのリダイレクトURLを確認します。

  5. ユーザー・バリエーション: ユーザー・バリエーションでステップ1から4を再実行して、適切な動作(認可ユーザーの場合は成功または未認可ユーザーの場合は失敗)を確認します。
  6. リクエストの取消し: 部分的なログインを実行し、「取消」をクリックしてリソースにアクセスしていないことを確認します。
  7. 変更された認証URL: ステップ1から5を実行して適切なレスポンスを確認する場合、ほとんど同じ認証URLを入力します。たとえば、1文字をURL文字列に追加します。
  8. 更新されたリソース: 次のステップを実行して、リソースにアクセスできることを確認します。次に例を示します。

    元のリソース: /abc/test.html

    更新されたリソース: /abc/xyz/test.html

    Oracle WebLogic Serverを再起動しない場合

    • 更新されたリソースにアクセスし、ユーザーが認証を求められ、リソースにアクセスできることを確認します。

    • 元のリソースにアクセスし、リソースにアクセス可能で、ユーザーが認証を求められていないことを確認します。

  9. 様々なURLパターン: ステップ1から5を実行する際に、様々なURLパターンの認証を確認します。
  10. 新しい認証スキーム: 次のステップを実行して、WebLogic Serverを再起動しないで認証操作を確認します。
    • 異なる認証スキームを使用する新しい認証ポリシーを追加します。

    • 新しいポリシーを使用して、リソースを保護します。

    • Oracle WebLogic Serverを再起動しないで、ステップ1から4を実行します。

  11. CGIリソース・ヘッダー変数およびCookie: 次のステップを実行して、WebLogic Serverを再起動しないで認証操作を確認します。
    • 新しい認証ポリシーを追加してCommon Gateway Interface (CGI)リソースを保護し、「認証に成功しました」のレスポンスを設定します。

    • 新しいポリシーを使用して、リソースを保護します。

    • CGIリソースにアクセスします。

    • CGIデータ・ダンプでレスポンスに対して構成されたヘッダー値を確認します。

  12. エージェントの無効化: WebGateがObAccessClient.xmlで無効な場合、次のステップを実行して、アクセス可能性および認証を検証します(WebGateは、oam-config.xmlから有効な値を選択する必要があります)。
    • エージェント状態を無効化します。WebサーバーおよびOAMサーバーを起動します。エージェントによって保護されているアプリケーションにアクセスして、認証を要求されることを確認します。