Oracle® Fusion Middleware Oracle Access Management開発者ガイド 11gリリース2 (11.1.2.3.0) for All Platforms E67354-04 |
|
前 |
次 |
Access Manager偽装サポートにより、ユーザーは制限時間枠内において自分のかわりを務める他のユーザーを指定できます。偽装権限付与はAccess Managerでネイティブにサポートされていますが、偽装権限付与を管理するにはカスタム・ユーザー・インタフェースを開発するか、既存のインタフェースを変更する必要があります。この章では、偽装の有効化とカスタム・ユーザー・インタフェースの開発について説明します。内容は次のとおりです。
参照: "『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のOracle ADFアプリケーションとOracle Access Manager 11g SSOの統合に関する項を参照してください。 |
Access Managerのユーザー偽装機能を使用すると、あるユーザーが別のユーザーのかわりに操作を実行したり、リソースにアクセスしたりできます。あるユーザーが別のユーザーを偽装するには、ユーザー識別子と開始および終了時間を指定した偽装権限付与が必要です。
内容は次のとおりです。
表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偽装セッション中のインパーソネータ・アイデンティティの伝達
次の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=example,dc=com" "cn=jdoe" orclguid
たとえば、orclguid
をLDAP検索するコマンドは次のとおりです。
ldapsearch -h myhost1.us.example.com -w welcome1 -p 16890 -b"dc=us,dc=example,dc=com" -D"cn=orcladmin" "cn=jdoe" orclguid version: 1
説明:
dn: cn=jdoe,cn=Users,dc=us,dc=example,dc=com
orclguid: A14BEB42E822D605E040E50AB29327E7
たとえば、orclImpersonationGrantee
をLDAP検索するコマンドは次のとおりです。
ldapsearch -h host1.us.example.com -w welcome1 -p 16890 -b"dc=us,dc=example,dc=com" -D"cn=orcladmin" "cn=lsmith" orclImpersonationGrantee version: 1
説明:
dn: cn=lsmith,cn=Users,dc=us,dc=example,dc=com
orclImpersonationGrantee: A14BEB42E822D605E040E50AB29327E7|20100324163000Z|20120524172000Z
次のようにOIDで、この値を偽装されたユーザーのorclImpersonationGrantee
エントリに追加します。
A14BEB42E822D605E040E50AB29327E7|20100324163000Z|20120524172000Z
注意: 値のリスト内で空白は使用できません。 |
オブジェクト・クラスおよびこの属性の属性定義がLDAPサーバーのスキーマでブートストラップされている必要があります。OID 11.1.1.3以降には、必要なオブジェクト・クラスが含まれています。
インパーソネータが偽装セッションを作成しようとすると、Access Managerは指定された被偽装者の偽装権限付与を取得します。ただし、そのインパーソネータに対する権限付与が存在しないか、現在の時刻が権限付与の時間枠内にない場合、偽装セッションの作成は失敗します。それ以外の場合、Access Managerはユーザー・プロファイル内の権限付与の読取りや変更を行いません。
その後、偽装セッションを認可した偽装権限付与を(たとえば、orclImpersonationGrantee
属性の変更などによって)取り消しても、実行中の偽装セッションには影響しません。
認証されたユーザーは別のユーザーを偽装できます。どのユーザーを偽装するかを選択するためのユーザー・インタフェースがアプリケーションから提供されます。情報の収集が完了すると、アプリケーションは偽装トリガーを呼び出します。それには、例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.example.com:7777/appl2.html"); m.put(SsoService.FAILURE_URL, "https://login01.example.com:7777/fail.html"); m.put(SsoService.IMP_USER_ID, "mcooper"); sso.beginImpersonation(req, res, m); [....] m.put(SsoService.TARGET_URL, "https://login02.example.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.urlとimp.end.urlの変更を伴うjps-config.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <jpsConfig xmlns="http://xmlns.example.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.example.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.example.com" name="name"/> </propertySet> [...] <propertySet name="props.auth.uri.0"> <property value="/oamsso/logout.html" name="logout.url"/> <property value="https://login01.example.com:7777/oam/server/impersonate/end name="imp.end.url"/> <property value="https://login01.example.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> [...]
API抽象化を使用せずにAccess Manager偽装トリガーを直接呼び出すには、Access Managerで設定されているトリガー・エンド・ポイントへのリダイレクションに、問合せパラメータuserid
、success_url
およびfailure_url
の指定を含める必要があります。userid
フィールドは被偽装者のユーザーIDを保持します。success_url/failure_urlは、偽装セッションの作成が成功または失敗した後にインパーソネータのブラウザがそれぞれポイントする先です。例6-4に示すように、指定するURLには、プロトコルおよびホスト:ポートの情報を含める必要があります。
例6-4 API抽象化を使用しない偽装のトリガー方法
https://login.example.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-2に、インパーソネータのアイデンティティを下位アプリケーションに通知するためのヘッダー名を示します。WebGateでは、リクエストに挿入された追加のHTTPヘッダー使用します。下位アプリケーションでは、インバウンド・リクエストのHTTPヘッダーを検査することで、Access Manager偽装セッションが実行中であるかどうかを検出できます。
偽装機能はデフォルトでは有効になっていません。偽装機能を有効にするには、oam-config.xml
を構成するか、idmConfigTool
コマンドを使用します。次の各項では、詳細を説明します。
OAMサーバーの偽装機能を有効にするには、oam-config.xml
ファイルを構成します。例6-6では、ファイルの該当部分と設定可能なパラメータを示します。偽装を有効化にするには、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>
偽装には、ログイン・リクエスト・コンテキストがCOOKIEまたはBASICのserverRequestCacheType
設定に保存されていることが必要です。デフォルト設定はCOOKIEです。このOAM Serverパラメータは、oam-config.xml
ファイルに設定するか、configRequestCacheType
WLSTコマンドを使用して設定することができます。configRequestCacheType
コマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool Identity and Access Managementコマンド・リファレンス』を参照してください。
idmConfigTool
を使用して偽装機能を構成するには、この手順に従ってください。idmConfigTool
コマンドと入力パラメータの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のidmConfigToolコマンドの使用に関する項を参照してください。
idmConfigTool
を-prepareIDStore
コマンドとともに使用して、Access Managerで必要なユーザーをアイデンティティ・ストアにシードします。
コマンドの構文は./idmConfigTool.sh -prepareIDStore mode=OAM input_file=
input_parameters
です。
idmConfigTool
でconfigOAM
コマンドとパラメータOAM11G_IMPERSONATION_FLAG:true
を指定して偽装機能を構成します。
コマンドの構文は./idmConfigTool.sh -configOAM input_file=
input_parameters
です。
偽装セッションの期間を示すセッション・タイムスタンプを指定して、偽装権限付与を定義します。
各値の書式は<Impersonator orclGUID> | <begin LDAP timestamp> | <end LDAP timestamp>
です。空白は使用できません。たとえば、OIDで次のようなタイムスタンプ値をorclImpersonationGrantee
エントリに追加します。
83295E092B2F9FD4E040E50AEBB91998|20100604224517Z|20110604224517Z;90FE8C8083CEBC1FE040E50AEBB9176A|20100704224517Z|20110604224517Z
説明:
最初のブロックはインパーソネータのGUIDです。ここでは、83295E092B2F9FD4E040E50AEBB91998
がインパーソネータのGUIDです。
2番目のブロックは開始日のタイムスタンプです。
3番目のブロックは終了日のタイムスタンプです。
データをLDAPサーバーに送信します。
偽装をサポートするには、保護されたアプリケーションの認証スキームをLDAPSchemeに設定する必要があります。これは偽装セッションの開始前に行う必要があります。認証スキームをLDAPSchemeに設定する手順は次のとおりです。
Oracle Access Management管理コンソールで、「ポリシー構成」タブ→アプリケーション・ドメイン→「認証ポリシー」→保護リソース・ポリシーに移動します。
「認証スキーム」リストから「LDAPScheme」を選択します。
LDAPSchemeの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の認証スキームの管理に関する項を参照してください。
偽装の設定をテストする手順は、使用している環境およびカスタム・ユーザー・インタフェースによって異なります。次の一般的な助言は、実行する手順の一例として提供します。ご使用の環境に合せて、手順を調整してください。
自分のユーザーIDと資格証明を使用してOracle Access Managementにログインします。
自分が認可されているリソースにアクセスして、Access Managerが適切に自分の資格証明で動作していることを確認します。
偽装セッションを開始します。
表示される偽装の確認フォームで自分(インパーソネータ)のパスワードを入力し、「送信」をクリックして偽装に同意します。
同じブラウザで、偽装されたユーザーが認可されているリソースにアクセスします。
Access Managerの「セッション管理」ページの「偽装」列に「True」が表示されることを確認します。
詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の「セッション管理」ページについての項を参照してください。
ヘッダー変数を出力するスクリプトまたはPerlプログラムを使用して、偽装セッションで設定されているHTTPヘッダー変数(OAM_REMOTE_USERとOAM_IMPERSONATOR_USER)を確認します。
詳細は、第6.1.5項「偽装セッション中のインパーソネータ・アイデンティティの伝達」を参照してください。
偽装セッションを終了します。
ヘッダー変数を出力するスクリプトまたはPerlプログラムを使用して、OAM_REMOTE_USERが偽装トリガー前のユーザーに設定されていること、OAM_IMPERSONATOR_USER HTTPヘッダー変数が空であることを確認します。