6 偽装を管理するアプリケーションの開発
注意:
6.1 Access Managerの偽装機能について
Access Managerのユーザー偽装機能を使用すると、あるユーザーが別のユーザーのかわりに操作を実行したり、リソースにアクセスしたりできます。あるユーザーが別のユーザーを偽装するには、ユーザー識別子と開始および終了時間を指定した偽装権限付与が必要です。
次の内容について説明します。
6.1.1 偽装の用語について
表6-1に、Access Managerにおける偽装の一般的な概念と用語を示します。
表6-1 偽装の用語
用語 | 定義 |
---|---|
インパーソネータ |
別のユーザーのかわりを務めるユーザー。 |
被偽装者 |
別のユーザーによって偽装されるユーザー。 |
偽装権限付与 |
被偽装者によって作成されるセキュリティ・メタデータで、指定時間枠の間、自分のかわりを務める特定のインパーソネータを指定するためのもの。 |
偽装トリガー |
インパーソネータが別のユーザーのかわりに偽装セッションを開始する行為。 |
Access Manager偽装セッション |
対象アプリケーションによる通常のユーザー・セッションとは異なるタイプのAccess Managerセッション。 |
偽装同意 |
Access Manager偽装セッションが有効であることを承認するためのインパーソネータによる同意。 |
6.1.2 偽装の概念の理解
Access Managerユーザー偽装サポートにより、エンド・ユーザー(被偽装者)は制限時間枠の間、自分のかわりを務めるユーザー(インパーソネータ)を1人以上指定できます。開発するカスタム・ユーザー・インタフェースを使用してこの情報が収集され、偽装権限付与のセットとしてユーザー・ディレクトリに永続化されます。
インパーソネータは、認証済セッションを保持してカスタム・ユーザー・インタフェースと対話している間に、別の名前付きユーザーのかわりに偽装セッションを開始できます。Access Managerは必要な認可チェックを行い、インパーソネータが被偽装者を偽装することを許可されているかどうかを確認します。許可されていれば、偽装セッションが作成されます。
Access Managerで保護されたアプリケーションは、偽装されたユーザーがアクセスしているかのように動作します。アプリケーションでは、ユーザーがインパーソネータか被偽装者かを識別できます。
インパーソネータがアプリケーション・ユーザー・インタフェースから偽装セッションを終了させると、偽装セッションは終了します。インパーソネータは通常のユーザー・セッションに復帰し、再び自分自身としてアプリケーションにアクセスできます。インパーソネータが偽装セッション中に偽装されたユーザーを切り替えることはできません(つまり、偽装のネストや再帰は許可されていません)。
Access Managerでは前述の偽装セマンティックを実行時に強制できますが、ユーザー・インタフェースの外観や関連メタデータ(偽装権限付与)のライフサイクルはすべてカスタム・インタフェースによって提供する必要があります。Access Managerとカスタム・ユーザー・インタフェースの統合は、次の3つのインタフェース(接触点)によって分類できます。
-
偽装権限付与の構文、永続性およびライフサイクル
-
偽装トリガーの呼出し
-
Access Manager偽装セッション中のインパーソネータ・アイデンティティの伝達
6.1.3 偽装権限付与の構文について
次の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.4 SSOサービスを使用した偽装トリガーの呼出しの理解
認証されたユーザーは別のユーザーを偽装できます。どのユーザーを偽装するかを選択するためのユーザー・インタフェースがアプリケーションから提供されます。情報の収集が完了すると、アプリケーションは偽装トリガーを呼び出します。
それには、例6-1に示すようにSSOサービスのメソッドの1つを呼び出すか、ユーザーのブラウザをAccess ManagerトリガーURLにリダイレクトして直接呼び出します。
SSOサービスの詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのアイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成に関する項を参照してください。
SSOサービスを使用してトリガー・メカニズムの詳細を抽象化するために必要なメソッドを例6-1に示します(推奨)。
この例では、SSOServiceのログイン/ログアウト/自動ログインAPIと同様に、props
に被偽装者のIMP_USER_ID
、SUCCESS_URL
、FAILURE_URL
およびTARGET_URL
が格納されています。簡略化した例を例6-2に示します。
例6-3はjps-config.xmlの抜粋で、必要な構成の変更を示しています(imp.begin.url
およびimp.end.url
プロパティ)。
例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
例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 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> [...]
6.1.5 API抽象化を使用しない偽装のトリガー方法
API抽象化を使用せずにAccess Manager偽装トリガーを直接呼び出すには、Access Managerで設定されているトリガー・エンド・ポイントへのリダイレクションに、問合せパラメータuserid
、success_url
およびfailure_url
の指定を含める必要があります。
userid
フィールドは被偽装者のユーザーIDを保持します。success_url/failure_urlは、偽装セッションの作成が成功または失敗した後にインパーソネータのブラウザがそれぞれポイントする先です。例6-4に示すように、指定するURLには、プロトコルおよびホスト:ポートの情報を含める必要があります。
例6-5に示すように、偽装セッションを終了して元のインパーソネータのAccess Managerセッションに戻るには、ユーザー・インタフェースで、Access Managerで設定されているエンド・ポイントにブラウザを強制的にリダイレクトさせるとともに、インパーソネータが復帰するターゲットURLを指定する必要があります。failure_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 元のインパーソネータ・セッションへの復帰
https://login.example.com/oam/server/impersonate/end?end_url=TargetRedirect URL&failure_url=FailureRedirect URL
6.1.6 偽装セッション中のインパーソネータ・アイデンティティの伝達
インパーソネータのアイデンティティを下位アプリケーションに通知するための、示されているヘッダー名を使用します。
表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サーバーの偽装機能を有効にするには、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 Identity and Access ManagementのためのWebLogic Scripting Toolコマンド・リファレンス』のconfigRequestCacheTypeに関する項を参照してください。
6.2.2 idmConfigToolによる偽装の構成
偽装機能を構成する手順を使用します。
idmConfigTool
を使用して偽装機能を構成するには、この手順に従ってください。idmConfigTool
コマンドと入力パラメータの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のidmConfigToolコマンドの使用方法に関する項を参照してください。
6.2.3 認証スキームの構成
これらの手順を使用して、認証スキームをLDAPSchemeに設定します。
偽装をサポートするには、保護されたアプリケーションの認証スキームをLDAPSchemeに設定する必要があります。これは偽装セッションの開始前に行う必要があります。認証スキームをLDAPSchemeに設定する手順は次のとおりです。
- Oracle Access Management管理コンソールで、「ポリシー構成」タブ→アプリケーション・ドメイン→「認証ポリシー」→保護リソース・ポリシーに移動します。
- 「認証スキーム」リストから「LDAPScheme」を選択します。
LDAPSchemeの詳細は、認証スキームの管理に関する項を参照してください。