ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management開発者ガイド
11gリリース2 (11.1.2)
B69537-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

6 偽装を管理するアプリケーションの開発

Access Manager偽装サポートにより、ユーザーは制限時間枠内において自分のかわりを務める他のユーザーを指定できます。偽装権限付与はAccess Managerでネイティブにサポートされていますが、偽装権限付与を管理するにはカスタム・ユーザー・インタフェースを開発するか、既存のインタフェースを変更する必要があります。この章では、偽装の有効化とカスタム・ユーザー・インタフェースの開発について説明します。内容は次のとおりです。


参照:

"『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle ADFアプリケーションとOracle Access Manager 11g SSOの統合に関する項を参照してください。

6.1 偽装について

Access Managerのユーザー偽装機能を使用すると、あるユーザーが別のユーザーのかわりに操作を実行したり、リソースにアクセスしたりできます。あるユーザーが別のユーザーを偽装するには、ユーザー識別子と開始および終了時間を指定した偽装権限付与が必要です。

次の内容について説明します。

6.1.1 偽装の概念と用語

表6-1に、Access Managerにおける偽装の一般的な概念と用語を示します。

表6-1 偽装の用語

用語 定義

インパーソネータ

別のユーザーのかわりを務めるユーザー。

被偽装者

別のユーザーによって偽装されるユーザー。

偽装権限付与

被偽装者によって作成されるセキュリティ・メタデータで、指定時間枠の間、自分のかわりを務める特定のインパーソネータを指定するためのもの。

偽装トリガー

インパーソネータが別のユーザーのかわりに偽装セッションを開始する行為。

Access Manager偽装セッション

対象アプリケーションによる通常のユーザー・セッションとは異なるタイプのAccess Managerセッション。

偽装同意

Access Manager偽装セッションが有効であることを承認するためのインパーソネータによる同意。

Access Managerユーザー偽装サポートにより、エンド・ユーザー(被偽装者)は制限時間枠の間、自分のかわりを務める他のユーザー(インパーソネータ)を1人以上指定できます。開発するカスタム・ユーザー・インタフェースを使用してこの情報が収集され、偽装権限付与のセットとしてユーザー・ディレクトリに永続化されます。

インパーソネータは、認証済セッションを保持してカスタム・ユーザー・インタフェースと対話している間に、別の名前付きユーザーのかわりに偽装セッションを開始できます。Access Managerは必要な認可チェックを行い、インパーソネータが被偽装者を偽装することを許可されているかどうかを確認します。許可されていれば、偽装セッションが作成されます。

Access Managerで保護されたアプリケーションは、偽装されたユーザーがアクセスしているかのように動作します。アプリケーションでは、ユーザーがインパーソネータか被偽装者かを識別できます。

インパーソネータがアプリケーション・ユーザー・インタフェースから偽装セッションを終了させると、偽装セッションは終了します。インパーソネータは通常のユーザー・セッションに復帰し、再び自分自身としてアプリケーションにアクセスできます。インパーソネータが偽装セッション中に偽装されたユーザーを切り替えることはできません(つまり、偽装のネストや再帰は許可されていません)。

Access Managerでは前述の偽装セマンティックを実行時に強制できますが、ユーザー・インタフェースの外観や関連メタデータ(偽装権限付与)のライフサイクルはすべてカスタム・インタフェースによって提供する必要があります。Access Managerとカスタム・ユーザー・インタフェースの統合は、次の3つのインタフェース(接触点)によって分類できます。

  • 偽装権限付与の構文、永続性およびライフサイクル

  • 偽装トリガーの呼出し

  • Access Manager偽装セッション中のインパーソネータ・アイデンティティの伝達

6.1.2 偽装権限付与の構文

次の2つの偽装権限付与は、orclIDXPersonオブジェクト・クラスの一部です。

  • orclImpersonationGrantee: ユーザーに対する権限付与がこの属性に含まれている場合、そのユーザーは現ユーザーを偽装できます。この属性は、偽装リクエスト時にOAMサーバーによってチェックされます。

  • orclImpersonationGranter: ユーザーに対する権限付与がこの属性に含まれている場合、そのユーザーを現ユーザーが偽装することができます。この属性は偽装を強制するときには使用されず、アプリケーションから偽装セッションを開始するときに使用されます。

被偽装者の偽装権限付与は、LDAPディレクトリ内のユーザーのレコードに複数値属性として永続化されます。ぞれぞれの値は、指定のインパーソネータに対する特定の権限付与および指定した時間枠を表します。複数値属性の各値は複合文字列であり、それぞれのフィールドが区切り文字で仕切られています。このリリースでは、偽装機能の使用時にOracle Identity Directoryがサポートされます。

各ユーザーが自分のユーザー・プロファイル内で偽装権限付与を作成、表示、更新または削除できるカスタム・ユーザー・インタフェースを作成または変更できます。このユーザー・インタフェースは、偽装権限付与を指定のLDAPディレクトリ内のorclImpersonationGranteeという複数値属性に永続化するよう構築する必要があります。各値の書式は<Impersonator orclGUID> | <begin LDAP timestamp> | <end LDAP timestamp>です。次に例を示します。

orclImpersonationGrantee: xyz123abcd|20100604224517Z|20100604234517Z; 
klmn980nopr|20100604224517Z|20100604234517Z

次の例では、次のように想定してします。

  • インパーソネータ: jdoe

  • 被偽装者: lsmith

jdoeがlsmithを偽装しようとしています。次のコマンドを使用してインパーソネータ(jdoe)のOrclGuidを取得できます。

ldapsearch -h <hostname> -w <password>  -p <port> -D"cn=orcladmin" -b"dc=us,dc=mycompany,dc=com"  "cn=jdoe" orclguid

たとえば、orclguidをLDAP検索するコマンドは次のとおりです。

ldapsearch -h myhost1.us.mycompany.com -w welcome1 -p 16890 -b"dc=us,dc=mycompany,dc=com" -D"cn=orcladmin"  "cn=jdoe" orclguid
version: 1

説明:

  • dn: cn=jdoe,cn=Users,dc=us,dc=mycompany,dc=com

  • orclguid: A14BEB42E822D605E040E50AB29327E7

たとえば、orclImpersonationGranteeをLDAP検索するコマンドは次のとおりです。

ldapsearch -h host1.us.mycompany.com -w welcome1 -p 16890 -b"dc=us,dc=mycompany,dc=com" -D"cn=orcladmin"  "cn=lsmith" orclImpersonationGrantee
version: 1

説明:

  • dn: cn=lsmith,cn=Users,dc=us,dc=mycompany,dc=com

  • orclImpersonationGrantee: A14BEB42E822D605E040E50AB29327E7|20100324163000Z|20120524172000Z

次のようにOIDで、この値を偽装されたユーザーのorclImpersonationGranteeエントリに追加します。

A14BEB42E822D605E040E50AB29327E7|20100324163000Z|20120524172000Z

注意:

値のリスト内で空白は使用できません。

オブジェクト・クラスおよびこの属性の属性定義がLDAPサーバーのスキーマでブートストラップされている必要があります。OID 11.1.1.3以降には、必要なオブジェクト・クラスが含まれています。

インパーソネータが偽装セッションを作成しようとすると、Access Managerは指定された被偽装者の偽装権限付与を取得します。ただし、そのインパーソネータに対する権限付与が存在しないか、現在の時刻が権限付与の時間枠内にない場合、偽装セッションの作成は失敗します。それ以外の場合、Access Managerはユーザー・プロファイル内の権限付与の読取りや変更を行いません。

その後、偽装セッションを認可した偽装権限付与を(たとえば、orclImpersonationGrantee属性の変更などによって)取り消しても、実行中の偽装セッションには影響しません。

6.1.3 SSOサービスを使用した偽装トリガーの呼出し

認証されたユーザーは別のユーザーを偽装できます。どのユーザーを偽装するかを選択するためのユーザー・インタフェースがアプリケーションから提供されます。情報の収集が完了すると、アプリケーションは偽装トリガーを呼び出します。それには、例6-1に示すようにSSOサービスのメソッドの1つを呼び出すか、ユーザーのブラウザをAccess ManagerトリガーURLにリダイレクトして直接呼び出します。

SSOサービスの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のアイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成に関する項を参照してください。

SSOサービスを使用してトリガー・メカニズムの詳細を抽象化するために必要なメソッドを例6-1に示します(推奨)。

例6-1 SsoService APIを使用してトリガー・メカニズムを抽象化するために必要なメソッド

void beginImpersonation(HttpServletRequest request, HttpServletResponse response, 
Map<String, ?> props) throws SsoServiceException
void endImpersonation(HttpServletRequest request, HttpServletResponse response, 
Map<String, ?> props) throws SsoServiceException

この例では、SSOServiceのログイン/ログアウト/自動ログインAPIと同様に、propsに被偽装者のIMP_USER_ID、SUCCESS_URL、FAILURE_URLおよびTARGET_URLが格納されています。簡略化した例を例6-2に示します。

例6-2 SsoService APIトリガーの簡略例

import oracle.security.jps.JpsException;
import oracle.security.jps.service.JpsServiceLocator;
import oracle.security.jps.service.ServiceLocator;
import oracle.security.jps.service.sso.SsoService;

public void doGet (HttpServletRequest req, HttpServletResponse res)
 throws ServletException, IOException

{

  try {
   ServiceLocator serviceLocator = JpsServiceLocator.getServiceLocator();
   SsoService sso = (SsoService)serviceLocator.lookup(SsoService.class);

   Map m = new HashMap();

   m.put(SsoService.SUCCESS_URL, "https://login01.mycompany.com:7777/appl2.html"); 
   m.put(SsoService.FAILURE_URL, "https://login01.mycompany.com:7777/fail.html");
   m.put(SsoService.IMP_USER_ID, "mcooper");

    sso.beginImpersonation(req, res, m);


    [....]

   m.put(SsoService.TARGET_URL, "https://login02.mycompany.com:8080/ 
   normalSession.html");    
   sso.endImpersonation(req, res, m);

  } catch(JpsException jpse) {
    jpse.printStackTrace();
  }
}

例6-3はjps-config.xmlの抜粋で、必要な構成の変更を示しています(imp.begin.urlおよびimp.end.urlプロパティ)。

例6-3 imp.begin.urとimp.end.urlの変更を伴うjps-config.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1
1.xsd">
    <property value="off" name="oracle.security.jps.jaas.mode"/>
    <propertySets>
        <propertySet name="saml.trusted.issuers.1">
            <property value="www.oracle.com" name="name"/>
        </propertySet>

[...]

        <propertySet name="props.auth.uri.0">
            <property value="/oamsso/logout.html" name="logout.url"/>
            <property value="https://login01.mycompany.com:7777/oam/server/impersonate/end
              name="imp.end.url"/>
            <property value="https://login01.mycompany.com:7777/oam/server/impersonate/start
              name="imp.begin.url"/>
            <property value="/${app.context}/adfAuthentication" name="login.url
             .BASIC"/>
            <property value="/${app.context}/adfAuthentication" name="login.
             url.ANONYMOUS"/>
            <property value="/${app.context}/adfAuthentication" name="login.
             url.FORM"/>
        </propertySet>
        <propertySet name="props.auth.level.0">
            <property value="0" name="type-level:ANONYMOUS"/>
            <property value="1" name="type-level:BASIC"/>
            <property value="2" name="type-level:FORM"/>
        </propertySet>
    </propertySets>

[...]

6.1.4 API抽象化を使用しない偽装のトリガー方法

API抽象化を使用せずにAccess Manager偽装トリガーを直接呼び出すには、Access Managerで設定されているトリガー・エンド・ポイントへのリダイレクションに、問合せパラメータuserid、success_urlおよびfailure_urlの指定を含める必要があります。useridフィールドは被偽装者のユーザーIDを保持します。success_url/failure_urlは、偽装セッションの作成が成功または失敗した後にインパーソネータのブラウザがそれぞれポイントする先です。例6-4に示すように、指定するURLには、プロトコルおよびホスト:ポートの情報を含める必要があります。

例6-4 API抽象化を使用しない偽装のトリガー方法

https://login.mycompany.com/oam/server/impersonate/start?userid=impersonatee userid&success_url=SuccessRedirect URL&failure_url=FailureRedirect URL

例6-5に示すように、偽装セッションを終了して元のインパーソネータのAccess Managerセッションに戻るには、ユーザー・インタフェースで、Access Managerで設定されているエンド・ポイントにブラウザを強制的にリダイレクトさせるとともに、インパーソネータが復帰するターゲットURLを指定する必要があります。failure_urlの使用は任意です。

例6-5 元のインパーソネータ・セッションへの復帰

https://login.mycompany.com/oam/server/impersonate/end?end_url=TargetRedirect URL&failure_url=FailureRedirect URL

6.1.5 偽装セッション中のインパーソネータ・アイデンティティの伝達

表6-2に、インパーソネータのアイデンティティを下位アプリケーションに通知するためのヘッダー名を示します。WebGateでは、リクエストに挿入された追加のHTTPヘッダー使用します。下位アプリケーションでは、インバウンド・リクエストのHTTPヘッダーを検査することで、Access Manager偽装セッションが実行中であるかどうかを検出できます。

表6-2 アイデンティティ情報のためのヘッダー

ヘッダー名 説明

OAM_IMPERSONATOR_USER

インパーソネータのユーザーIDを保持するヘッダー名。

OAM_REMOTE_USER

エンド・ユーザーIDを保持するヘッダー。標準のAccess Managerユーザー・セッションと同じものです。

6.2 偽装サポートの構成

偽装機能はデフォルトでは有効になっていません。偽装機能を有効にするには、oam-config.xmlを構成するか、idmConfigToolコマンドを使用します。

この項には次のトピックが含まれます。

6.2.1 oam-config.xmlによる偽装の構成

OAMサーバーの偽装機能を有効にするには、例6-6に示すようにoam-config.xmlファイルを構成します。

この例では、ファイルの該当部分と設定可能なパラメータを示します。偽装を有効化にするには、EnableImpersonationをtrueに設定する必要があります。デフォルト設定はfalseです。

例6-6 oam-config.xmlでの偽装機能の有効化

<Setting Name="ImpersonationConfig" Type="htf:map">
<Setting Name="EnableImpersonation" Type="xsd:boolean">true</Setting>
    <Setting Name="UserAttributeName"
    Type="xsd:string">orclImpersonationGrantee</Setting>
    <Setting Name="ErrorPage" Type="xsd:string">/pages/servererror.jsp</Setting>
</Setting>

6.2.2 idmConfigToolによる偽装の構成

idmConfigToolコマンドの詳細は、Oracle Fusion Middleware Oracle Identity Management Suite統合ガイドのidmConfigToolコマンドの使用方法に関する項を参照してください。

idmConfigToolを使用して偽装機能を構成する手順は次のとおりです。

  1. idmConfigToolを-prepareStoreIDコマンドとともに使用して、Access Managerで必要なユーザーをアイデンティティ・ストアにシードします。コマンドの構文は./idmConfigTool.sh -prepareIDStore mode=OAM input_file=input_parametersです。

  2. idmConfigToolでconfigOAMコマンドとパラメータOAM11G_IMPERSONATION_FLAG:trueを指定して偽装機能を構成します。コマンドの構文は./idmConfigTool.sh -configOAM input_file=input_parametersです。

  3. 偽装セッションの期間を示すセッション・タイムスタンプを指定して、偽装権限付与を定義します。各値の書式は<Impersonator orclGUID> | <begin LDAP timestamp> | <end LDAP timestamp>です。空白は使用できません。

    たとえば、OIDで次のようなタイムスタンプ値をorclImpersonationGranteeエントリに追加します。

    83295E092B2F9FD4E040E50AEBB91998|20100604224517Z|20110604224517Z;90FE8C8083CEBC1FE040E50AEBB9176A|20100704224517Z|20110604224517Z

    説明:

    • 最初のブロックはインパーソネータのGUIDです。ここでは、83295E092B2F9FD4E040E50AEBB91998がインパーソネータのGUIDです。

    • 2番目のブロックは開始日のタイムスタンプです。

    • 3番目のブロックは終了日のタイムスタンプです。

  4. データをLDAPサーバーに送信します。

6.2.3 認証スキームの構成

偽装をサポートするには、保護されたアプリケーションの認証スキームをLDAPSchemeに設定する必要があります。これは偽装セッションの開始前に行う必要があります。LDAPSchemeの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の認証スキームの管理に関する項を参照してください。

認証スキームをLDAPSchemeに設定する手順は次のとおりです。

  1. Oracle Access Management管理コンソールで、「ポリシー構成」タブ→アプリケーション・ドメイン→「認証ポリシー」→保護リソース・ポリシーに移動します。

  2. 「認証スキーム」リストから「LDAPScheme」を選択します。

6.3 SSOログインおよび偽装のテスト

偽装の設定をテストする手順は、使用している環境およびカスタム・ユーザー・インタフェースによって異なります。手順の例として、次に一般的なアドバイスを示します。必要に応じて、使用している環境に合せて調整してください。

SSOログインおよび偽装をテストする手順は次のとおりです。

  1. 自分のユーザーIDと資格証明を使用してOracle Access Managementにログインします。

  2. 自分が認可されているリソースにアクセスして、Access Managerが適切に自分の資格証明で動作していることを確認します。

  3. 偽装セッションを開始します。

  4. 表示される偽装の確認フォームで自分(インパーソネータ)のパスワードを入力し、「送信」をクリックして偽装に同意します。

  5. 同じブラウザで、偽装されたユーザーが認可されているリソースにアクセスします。

  6. Access Managerの「セッション管理」ページの「偽装」列に「True」が表示されることを確認します。

    詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の「セッション管理」ページについての項を参照してください。

  7. ヘッダー変数を出力するスクリプトまたはPerlプログラムを使用して、偽装セッションで設定されているHTTPヘッダー変数(OAM_REMOTE_USERとOAM_IMPERSONATOR_USER)を確認します。

    詳細は、第6.1.5項「偽装セッション中のインパーソネータ・アイデンティティの伝達」を参照してください。

  8. 偽装セッションを終了します。

  9. ヘッダー変数を出力するスクリプトまたはPerlプログラムを使用して、OAM_REMOTE_USERが偽装トリガー前のユーザーに設定されていること、OAM_IMPERSONATOR_USER HTTPヘッダー変数が空であることを確認します。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次