42.2 シナリオ: Access Managerトークンを使用したアイデンティティ伝播

セキュリティ層固有のセキュリティ要件またはドメイン固有のセキュリティ要件がサポートされる一方で、ユーザーのアイデンティティ情報は表示できるようになり、様々な層またはドメイン間で伝播されます。セキュリティ・トークン・サービスをAccess Managerとともに使用してアイデンティティの伝播を実現するには、ブローカ・トラスト・モデルを使用できます。

これは、ユーザーのアイデンティティ情報をWebアプリケーションからWebサービス・プロバイダに伝播する必要があるデプロイメントです。Webサービス・プロバイダは、Webアプリケーションと同じセキュリティ・ドメインに存在することも、別のセキュリティ・ドメインに存在することもできます。

図42-2 OAMトークンを使用したアイデンティティ伝播

「図42-2 OAMトークンを使用したアイデンティティ伝播」の説明

アイデンティティ伝播とは、元のユーザー・コンテキストを元のセキュリティ層またはドメイン境界の外側で表示できるようになることです。ユーザー・セキュリティ・コンテキストは、ステップアップ認証、認可、監査/内部アプリケーション固有のビジネス・ロジックなど、層またはドメイン固有のセキュリティ・ニーズをサポートするために、異なるセキュリティ層またはドメインに伝播されます。

ID伝播は、最初のノードで確立されたアイデンティティ・コンテキストを後続のノードに伝播するときに、そのアイデンティティのコンテキストでリクエストをさらに処理できるようにするために、リクエストの分散処理で発生すると言われています。ID伝播は複数の方法で実行できます。IDプロバイダがIDアサーションのトラスト・ブローカとして機能する、ブローカ・トラスト・モデルに基づく方法があります。ここで説明する内容は、このモデルに関連しています。

図42-3に、ブローカ・トラスト・モデルのID伝播シナリオを示します。このシナリオでは、ユーザー向けアプリケーションがエンド・ユーザーのコンテキストでバックエンド・サービス・アプリケーションによる処理を要求する必要があります。ID伝播の主な側面を明らかにするために、エンド・ユーザー、アプリケーションおよびバックエンド・サービス・アプリケーション間の他のすべての相互作用および関係の詳細は無視されます。

図42-3 アイデンティティ伝播中のプロセス・フロー

「図42-3 アイデンティティ伝播中のプロセス・フロー」の説明

42.2.1 アクターとプロセスの概要: アイデンティティ伝播

アイデンティティ伝播を処理する一般的なプロセスには、IDアサーション・トークン・リクエスタ、IDプロバイダおよびIDアサーション・トークン・コンシューマが含まれます。

次の概要を一読すると、アイデンティティ伝播を処理するアクターおよびプロセスをよく理解できます。

IDアサーション・トークン・リクエスタ(エンド・ユーザー向けアプリケーション)は、エンド・ユーザーへのアクセス時に、アイデンティティ・プロバイダの認証およびIDアサーション・トークンをリクエストします。

ノート:
IDアサーション・トークン・リクエスタの例には、OAMで保護されるWebアプリケーションがあります。IDアサーション・トークン・リクエストは、暗黙的な場合もあれば、IDプロバイダのポリシーから導かれる場合もあります。
IDプロバイダ(Security Token Service)はリクエストを処理し、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。
IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。
IDアサーション・トークン・コンシューマ(Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。

「コンポーネント処理: OAMトークンを使用したアイデンティティ伝播について」を参照してください。

「リクエスト・セキュリティ・トークンの属性と実行時の処理」を参照してください。

「構成要件: OAMトークンを使用したアイデンティティ伝播」を参照してください。

42.2.2 コンポーネント処理: OAMトークンを使用したアイデンティティ伝播について

セキュリティ・トークン・サービスをAccess Managerとともに使用して、アイデンティティ伝播をデプロイおよび処理できます。

図42-4に、Security Token ServiceとAccess Managerを使用したアイデンティティ伝播の一般的なデプロイメント・トポロジを示します。

図42-4 アイデンティティ伝播のデプロイメント

「図42-4 アイデンティティ伝播のデプロイメント」の説明

図42-5に、Security Token ServiceとAccess Managerを使用したアイデンティティ伝播の処理を示します。詳細は、図の後に説明します。

図42-5 アイデンティティ伝播処理

「図42-5 アイデンティティ伝播処理」の説明

42.2.2.1 プロセスの概要: アイデンティティ伝播のコンポーネント相互作用

アイデンティティ伝播のプロセスでは、ユーザーが保護されたリソースにアクセスしようとすると、コンポーネント間で相互作用が確立されます。コンポーネントとして、Webゲート、Access Manager、WebLogic Server、WebLogic Server上のAccess Manager Identity Asserter、Webサービス・クライアントおよびセキュリティ・トークン・サービスがあります。

次のステップに、アイデンティティ伝播でのコンポーネント相互作用の概要を示します。

ユーザーが保護されたリソースにアクセスを試みます。
Webゲートはリソースを保護しており、認証および認可のためにAccess Managerにリクエストを送信します。
Access Managerは、このWebゲート・アプリケーション・ドメイン用に構成されたポリシーを使用してユーザーを認証します。レスポンス・タイプ「IDENTITY_ASSERTION」がこのWebgate用に構成されていることを確認し、IDアサーション・トークンも生成します。
Access Managerは、Webゲートに認証およびIDアサーションを送信します。
Webゲートは、レスポンスを処理し、IDアサーション・トークンをヘッダー(WebゲートがインストールされているOHS)に設定した後、リソースをホストするWLSにリクエストをリダイレクトします。
IAP (WebLogic Server上のAccess Manager Identity Asserter)では、OAM_IDENTITY_ASSERTIONヘッダーが設定されていることを確認し、ヘッダーを処理した後、IDアサーション・トークンをサブジェクトのプライベートな資格証明(OamIdentity)に設定します。
最終的にリソースにアクセスした時点で、Webサービス・クライアントは現在のユーザーのサブジェクトからIDアサーション・トークンを取得し、そのIDアサーション・トークンを使用してOnBehalfOf (OBO)トークンを生成した後、リクエスト・セキュリティ・トークン(RST)を作成してSecurity Token Serviceに送信します。
Security Token ServiceではOBOトークン内のIDアサーション・トークンを確認し、Access Managerライブラリを使用してAccess Managerに検証/認証リクエストを送信します。
Access ManagerではIDアサーション・トークンを検証および認証した後、Security Token Serviceにレスポンス(ユーザー・アイデンティティ)を送信します。
Security Token Serviceではこのユーザー・アイデンティティを使用して、ポリシー評価、トークン発行などの処理がさらに行われます。その後、リクエスト・セキュリティ・トークン・レスポンスが生成されます。
Security Token Serviceでは、クライアントにリクエスト・セキュリティ・トークン・レスポンスが送信されます。クライアントはリクエスト・セキュリティ・トークン・レスポンス(RSTR)内のトークンを使用して、リライイング・パーティがホストするサービスにアクセスするためのWebサービス・リクエストを作成できます。

42.2.3 リクエスト・セキュリティ・トークンの属性と実行時の処理

次の属性を持つ着信リクエスト・セキュリティ・トークン(RST)の場合、リクエストを処理し、トークンを発行するようにセキュリティ・トークン・サービスを構成する必要があります。

42.2.3.1 OAMトークンを使用したアイデンティティ伝播のRST属性

セキュリティ・トークン・サービスをAccess Managerとともに使用して、ID伝播のRST属性を適用できます。

ID伝播の属性を次に示します。

SOAPヘッダーには、WSリクエスタを参照するユーザー名トークンが含まれています。ユーザー名トークンには、少なくとも1つのユーザー名とパスワードが含まれています。
SOAP本体にはWS-Trust RSTメッセージが含まれています。
RSTには、LDAP内のユーザーを参照するOnBehalfOfフィールドにOAM ID伝播トークンが含まれています。OnBehalfOf要素に含まれるトークンはBinarySecrityTokenで、テキスト値はOAMセッション伝播トークンのBase 64エンコード・フォーマット、ValueType属性はhttp://something.example.com/am/2012/11/token/session-propagation、EncodingType属性はhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soapmessage-security-1.0#Base64Binaryです。
RSTには、リライイング・パーティWebサービスのエンドポイントを示すURLを保持するAppliesToフィールドが含まれている可能性があります。
RSTには、返す必要があるトークンのタイプを保持するTokenTypeフィールドが含まれている可能性があります。
RSTには、SAMLアサーションに対称証明キーが必要な場合にSecretKeyを作成するときに使用されるランダム・データを保持するEntropyフィールドが含まれている可能性があります。
RSTには、SAMLアサーションの非対称証明キーとして使用される証明書または公開キーを保持するUseKeyフィールドが含まれている可能性がありますが、このフィールドはSecurity Token Serviceでは無視されます。

42.2.3.2 プロセスの概要: OAMトークンを使用したアイデンティティ伝播

クライアントでは、セキュリティ・トークン・サービスへのリクエストを準備して送信します。クライアントへのレスポンスを作成する前に、セキュリティ・トークン・サービスでは、トークンを検証し、必要に応じてトークンを作成します。

次のステップでは、OAMトークンを使用したアイデンティティ伝播の適用方法について説明します。

クライアントは次の方法でリクエストを準備します。
1. SOAPメッセージを作成します。
2. クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。
3. WS-Trust RSTメッセージを作成します。
4. ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。
5. SOAP本体にRSTメッセージを含めます。
クライアントはSecurity Token Service、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをSecurity Token Service WSS検証テンプレートにマップします。
Security Token Serviceでは着信リクエストが処理されます。
Security Token Serviceは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。
1. ユーザー名トークンのフォーマットを検証します。
2. ユーザー名トークンに含まれる資格証明とSecurity Token Serviceパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。
3. リクエスタ・パートナを確認した後、Security Token Serviceはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。
Security Token Serviceでは、OnBehalfOfフィールドに存在するトークンが検証されます。
1. OnBehalfOfフィールドに存在するトークンのタイプを判断します。
2. OAMトークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。
3. OAMトークンのフォーマットおよびOAMトークンを検証し、トークンをユーザーにマップします。
4. ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。
Security Token ServiceではAppliesToフィールドが検査されます。
- 存在する場合、Security Token Serviceはリライイング・パーティ・パートナのWSエンドポイント・マッピングを使用して、リライイング・パーティ・パートナへのAppliesTo URLへのマップを試行します。マッピングに成功した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされ、Security Token Serviceはこのパートナからリライイング・パーティ・パートナ・プロファイルを取得します。マッピングに失敗した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされず、Security Token Serviceはこのリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。
- 存在しない場合、Security Token Serviceはリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。
Security Token ServiceではTokenTypeフィールドが検査されます。
- 存在する場合、Security Token Serviceはリクエスタ・パートナ・プロファイルを使用してTokenType文字列をローカル・トークン・タイプ値にマップし、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。
- 存在しない場合、Security Token Serviceはリライイング・パーティ・パートナ・プロファイルからデフォルト・トークン・タイプを取得し、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。
Security Token Serviceでは認証評価が行われ、リクエスタ・パートナが、フローで参照されるリライイング・パーティのトークンのリクエストを許可されていることが確認されます(詳細は「認可信頼ポリシー」を参照)。
Security Token Serviceではトークンが作成されます。
- 発行されるトークンがSAMLタイプの場合、発行テンプレートには名前IDの移入方法がリストされ、リライイング・パーティ・パートナ・プロファイルにはトークンで送信する必要がある属性がリストされます。発行テンプレートは、属性の名前および値を変換する必要があるかどうかを示します。発行テンプレートは、トークンの署名/暗号化を実行するかどうかを示します。
- 発行されるトークンがSAMLタイプの場合、Security Token ServiceサーバーはKeyTypeを調べて、アサーションのサブジェクト確認メソッドを判断します。存在しない場合は、発行テンプレートからデフォルトの確認メソッドが使用されます。
Security Token Serviceでは、クライアントが処理するレスポンスが作成されます。
1. WS-Trust RSTRCを作成します。
2. 返されたトークンを追加します。
3. 必要に応じて証明キーを追加します。

42.2.4 構成要件: OAMトークンを使用したアイデンティティ伝播

次の各トピックでは、アイデンティティ伝播シナリオの構成要件を示します。

42.2.4.1 構成の概要: OAMトークンを使用したアイデンティティ伝播

セキュリティ・トークン・サービスをAccess Managerとともに使用して、アイデンティティ伝播の環境を構成できます。

アイデンティティ伝播の環境と実装タスクの概要を次に示します。

クライアントとして機能するカスタム・アプリケーション・モジュールでは、次の処理が行われます。
- HTTPリクエストからのOAMセッション伝播トークンの取得
- Security Token ServiceサーバーへのWS-Trustリクエストの送信(Access Managerセッション伝播トークンをOnBehalfOf要素として使用)
Webgateで保護され、WS-TrustリクエストをSecurity Token Serviceに送信するクライアントWebアプリケーションを起動するWebアプリケーション
セキュリティ・トークン・サービスURL: http://myhost.domain.com:14100/sts/<endpoint>

ノート:
<endpoint>を「STSエンドポイント」の項で構成したパスに置換します。
Webアプリケーションを保護するWebgateを備えたOHS 11g

WebLogic Serverにデプロイされたアプリケーションを保護するために、Webgate (11gまたは10g)をプロビジョニング(登録)します。

OAMSuiteアプリケーション・ドメインは事前に送信され、Access Manager 11gとともに配布されます。このアプリケーション・ドメイン(または別の既存のアプリケーション・ドメイン)を使用するためにOAMエージェントをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。

OHSサーバーmod_wl_ohs.conf内のWebgateのリバース・プロキシ・マッピングを次に示します。

図GUID-7928CE60-5349-401D-970D-A1EF6AA7D8C7-default.gifの説明

アイデンティティ伝播のトークン処理を実装するには、次のSecurity Token Service構成が必要です。

1つのリクエスタ・パートナ・プロファイル
1つのリライイング・パーティ・パートナ・プロファイル
1つの発行テンプレート
1つのWS-Trust検証テンプレート
Security Token Serviceのエンドポイント
ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Security Token ServiceにはLDAPサーバーが必要です。

目的のLDAPサーバーが、デフォルト・アイデンティティ・ストアとして構成されていることを確認します。

42.2.4.2 WebLogic Server Identity Assertion Provider

IDアサーション・プロバイダwarをデプロイします。Access Manager Identity Asserterは、Oracle Fusion Middlewareがインストールされている次のパスで使用できます。

$ORACLE_HOME/modules/oracle.oamprovider_11.1.1/oamauthenticationprovider.war

oamauthenticationprovider.warを次の場所にコピーします:

$BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
provider.war

図42-6 必要なv1.0 WebLogic Server Identity Assertion Provider

「図42-6 必要なv1.0 WebLogic Server Identity Assertion Provider」の説明

図42-6に、このシナリオに必要なWebLogic Server Identity Assertion Providerを示します。

42.2.4.3 Access Manager Identity Asserterの詳細

REQUIRED制御フラグを使用して、Identity Asserterを設定できます。

IAP-Security Token Serviceアイデンティティ・アサータを最初に設定してから、REQUIRED Controlフラグを使用して設定する必要があります。OAM_REMOTE_USER1のSSOヘッダー名を使用して、「Active Types」をObSSOCookieおよびOAM_REMOTE_USERとして設定する必要があります。

図42-7に構成を示します。

図42-7 IAP-Security Token Serviceの詳細

「図42-7 IAP-Security Token Serviceの詳細」の説明

42.2.4.4 LDAP認証プロバイダの詳細

OPTIONAL JAASフラグを使用してLDAPのオーセンティケータを作成する必要があります。

このフラグは、Access Managerトークンを提供するOracle Access Managementのデフォルト・システム・ストアを指します。

図42-8は、このプロセスを示しています。

図42-8 LDAPプロバイダ: IAP-DSEE

「図42-8 LDAPプロバイダ: IAP-DSEE」の説明

42.2.4.5 デフォルト・アイデンティティ・ストアの構成

図42-9 Access Managerに定義されているデフォルト・アイデンティティ・ストア

「図42-9 Access Managerに定義されているデフォルト・アイデンティティ・ストア」の説明

図42-9に、Oracle Access Managementコンソール内のデフォルト・アイデンティティ・ストアの構成を示します。

42.2.4.6 トークン発行ポリシー

IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成する必要があります。

図42-10に、「トークン発行ポリシー」ページを示します。

図42-10 アイデンティティ伝播のトークン発行ポリシー

「図42-10 アイデンティティ伝播のトークン発行ポリシー」の説明

42.2.4.7 WebgateによるIDアサーションの認証ポリシー・レスポンス

認証に成功すると、WebゲートからIDアサーション・トークンがポリシー・レスポンスとして返されます。

IDアサーションは、エンド・ユーザー(およびそのOAMセッション)を表すAccess Managerから発行されたトークンのID伝播で必要です。IDアサーション・トークンは、正常に認証された後に生成され、ポリシー・レスポンス(名前が「OAM_IDENTITY_ASSERTION」で値がSAMLトークンというHTTPヘッダー)として返されます。

IDプロバイダ(Access Manager)はリクエストを処理して、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。

Access Managerによって保護されているWebアプリケーションであるSecurity Token Serviceクライアントが、リライイング・パーティ(ID伝播ユースケース)へのプロキシ・アクセスを取得するためにトークンをリクエストすると、エンド・ユーザーを表すOAM IDアサーション・トークンを渡すように要求されます。

IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。

IDアサーション・トークン・コンシューマ(Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。

「SSOのポリシー・レスポンスの概要」を参照してください。

IAM Suiteアプリケーション・ドメイン内の認証ポリシー・レスポンスの一部として「IDアサーション」ボックスが選択されていることを確認します。これにより、保護されているリソースに対してWebgateでIDアサーションを実行できるようになります。

「SSOのポリシー・レスポンスの追加および管理」を参照してください。

各レスポンスを追加すると、次のように通知される場合があります: Identity Assertion has not been enabled for this policy. Enable Identity Assertion in order to collect Assertion Attribute type responses (when this policy is executed)

42.2.4.8 エンドポイントの構成

/wss10userエンドポイントが必要です。

これは、RSTをポストするためにWebアプリケーションで使用できるエンドポイントです。

図42-11に、/wss10userエンドポイントを示します。このエンドポイントは、RSTをポストするためにWebアプリケーションで使用されるデフォルトのWS-Security検証テンプレートで保護されます。

図42-11 IDアサーションの/wssuserエンドポイント

「図42-11 IDアサーションの/wssuserエンドポイント」の説明

42.2.4.9 発行テンプレートの構成

発行テンプレートには、トークン・タイプや署名キーIDなどのアイデンティティ伝播用の構成パラメータが必要です。

発行テンプレートには、次の構成が必要です。

名前: iap-issuance-template
説明: カスタム発行テンプレート
トークン・タイプ: SAML 2.0
署名キーID: osts_signing
説明: カスタム発行テンプレート

42.2.4.10 パートナ構成: リクエスタ

次のように、OAMトークンを使用してアイデンティティ伝播用の新しいリクエスタ・パートナ構成を作成します。

パートナ名: iap-request-partner
リクエスタ・タイプ: STS_REQUESTER
パートナ・プロファイル: iap-requestor-profile
説明: カスタム・リクエスタ
信頼
ユーザー名トークン認証
- ユーザー名 <Webサービス・クライアントで使用されるユーザー名を入力>
- パスワード <Webサービス・クライアントで使用されるパスワードを入力>
- パスワードの確認 <Webサービス・クライアントで使用されるパスワードを入力>
アイデンティティ属性の値:
- httpbasicusername
- sslclientcertdn