ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド
11g リリース1 (11.1.1)
B62265-02
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

16 Oracle Security Token Serviceの実装シナリオ

この章では、Oracle Security Token Serviceの実装シナリオおよび処理シナリオをいくつか示します。シナリオの詳細に関係なく、構成タスクとトークン処理の両方に多数の類似点があります。この章の内容は次のとおりです。

前提条件

「Oracle Security Token Serviceの概要」

一般的なトークン・エコシステム

ここで取り上げる抽象モデルは、このようなモデルをサポートするためにOracle Security Token Serviceに設定されている要件を示すために役立ちます。

ここでは、セキュリティ・トークン・エコシステムという語句を使用して、セキュリティ・トークンが使用される一般的な環境を表します。このような環境では、環境に必要なセキュリティ・モデルに基づいて、セキュリティ・トークンを使用してブローカ・トラストやシングル・サインオンなどの最終目標を達成できます。ここに示すように、環境およびセキュリティ・トークンのタイプに関係なく、いくつかの側面はすべてのモデルに共通しています。

図16-1に、トークン発行局、トークン・リクエスタ、トークン・コンシューマ、セキュリティ・トークンなどを含む一般的なトークン・エコシステムを示します。

図16-1 一般的なトークン・エコシステム

一般的なトークン・エコシステム
「図16-1 一般的なトークン・エコシステム」の説明

アクターとプロセスの概要: 一般的なトークン・エコシステム

  1. トークン・リクエスタは、トークン発行局にセキュリティ・トークンをリクエストします。

    このセキュリティ・トークンは、サービス・プロバイダ(セキュリティ・トークンを受け入れるトークン・コンシューマ)が提供するサービスと通信し、サービスへのアクセスをリクエストする必要があります。

    • トークン・リクエスタは、トークン発行局のパートナである可能性があります(通常はトークン発行局に登録されます)。

    • トークン・リクエスタは、エンド・ユーザーである可能性があります(通常はトークン発行局には登録されません)。

  2. トークン発行局(OAM、OSTSなど)は、次のようにセキュリティ・トークン・リクエストを受信および処理し、セキュリティ・トークンを返します。

    • 入力資格証明を認証します。

    • 特定のトークン・コンシューマのセキュリティ・トークンのリクエストを認可されているトークン・リクエスタを指定するトークン発行ポリシーに基づいて、セキュリティ・トークン・リクエストを認可します。

  3. トークン・コンシューマ(通常はサービス・プロバイダ)。

    • セキュリティ・トークンをサービス・リクエストの一部として受け入れ、入力セキュリティ・トークンの有効性に基づいてサービスを提供します。

    • トークン発行局を使用して入力セキュリティ・トークンを検証します。


    注意:

    トークン・コンシューマは通常、トークン発行局の登録済パートナです。トークン・コンシューマはリライイング・パーティとも呼ばれます。これは、トークン・リクエスタ認証のためにトークン発行局を信頼し、依存しているためです。トークン・コンシューマ(リライイング・パーティ・パートナ)は、Webアプリケーション(OAMの場合、OSTSがトークン発行局)またはSTSリライイング・パーティWebサービスです。

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

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

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

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

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

ID伝播は、最初のノードで確立されたアイデンティティ・コンテキストを後続のノードに伝播するときに、そのアイデンティティのコンテキストでリクエストをさらに処理できるようにするために、リクエストの分散処理で発生すると言われています。

ID伝播は複数の方法で実行できます。IDプロバイダがIDアサーションのトラスト・ブローカとして機能する、ブローカ・トラスト・モデルに基づく方法があります。ここで説明する内容は、このモデルに関連しています。

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

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

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

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

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


    注意:

    IDアサーション・トークン・リクエスタの例には、OAMで保護されるWebアプリケーションがあります。IDアサーション・トークン・リクエストは、暗黙的な場合もあれば、IDプロバイダのポリシーから導かれる場合もあります。

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

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

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

詳細は、次のトピックを参照してください。

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

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

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

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

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

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

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

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

  1. ユーザーが保護されたリソースにアクセスを試みます。

  2. Webgateはリソースを保護しており、認証および認可のためにOracle Access Managerにリクエストを送信します。

  3. Oracle Access Managerでは、このWebgateアプリケーション・ドメイン用に構成されたポリシーを使用してユーザーが認証されます。レスポンス・タイプ「IDENTITY_ASSERTION」がこのWebgate用に構成されていることを確認し、IDアサーション・トークンも生成します。

  4. Oracle Access ManagerはWebgateに認証およびIDアサーションを送信します。

  5. Webgateでは、レスポンスを処理し、IDアサーション・トークンをヘッダー(WebgateがインストールされているOHS)に設定した後、リソースをホストするWLSにリクエストをリダイレクトします。

  6. IAP (WebLogic Server上のOracle Access Manager Identity Asserter)では、OAM_IDENTITY_ASSERTIONヘッダーが設定されていることを確認し、ヘッダーを処理した後、IDアサーション・トークンをサブジェクトのプライベートな資格証明(OamIdentity)に設定します。

  7. 最終的にリソースにアクセスした時点で、Webサービス・クライアントは現在のユーザーのサブジェクトからIDアサーション・トークンを取得し、そのIDアサーション・トークンを使用してOnBehalfOf (OBO)トークンを生成した後、リクエスト・セキュリティ・トークン(RST)を作成してOSTSに送信します。

  8. Oracle Security Token ServiceではOBOトークン内のIDアサーション・トークンを確認し、Oracle Access Managerライブラリを使用してOracle Access Managerに検証/認証リクエストを送信します。

  9. Oracle Access ManagerではIDアサーション・トークンを検証および認証した後、Oracle Security Token Serviceにレスポンス(ユーザー・アイデンティティ)を送信します。

  10. Oracle Security Token Serviceではこのユーザー・アイデンティティを使用して、ポリシー評価、トークン発行などの処理がさらに行われます。その後、リクエスト・セキュリティ・トークン・レスポンスが生成されます。

  11. Oracle Security Token Serviceでは、クライアントにリクエスト・セキュリティ・トークン・レスポンスが送信されます。クライアントはリクエスト・セキュリティ・トークン・レスポンス(RSTR)内のトークンを使用して、リライイング・パーティがホストするサービスにアクセスするためのWebサービス・リクエストを作成できます。

RST属性とランタイム処理

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

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

  • SOAPヘッダーには、WSリクエスタを参照するユーザー名トークンが含まれています。ユーザー名トークンには、少なくとも1つのユーザー名とパスワードが含まれています。

  • SOAP本体にはWS-Trust RSTメッセージが含まれています。

  • RSTには、LDAP内のユーザーを参照するOnBehalfOfフィールドにOAM ID伝播トークンが含まれています。OnBelahfOf要素に含まれるトークンはBinarySecrityTokenで、テキスト値はOAMセッション伝播トークンのBase 64エンコード・フォーマット、ValueType属性はhttp://xmlns.oracle.com/am/2010/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フィールドが含まれている可能性がありますが、このフィールドはOSTSでは無視されます。

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

  1. クライアントは次の方法でリクエストを準備します。

    1. SOAPメッセージを作成します。

    2. クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。

    3. WS-Trust RSTメッセージを作成します。

    4. ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。

    5. SOAP本体にRSTメッセージを含めます。

  2. クライアントはOSTS、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをOSTS WSS検証テンプレートにマップします。

  3. OSTSでは着信リクエストが処理されます。

  4. OSTSは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。

    1. ユーザー名トークンのフォーマットを検証します。

    2. ユーザー名トークンに含まれる資格証明とOSTSパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。

    3. リクエスタ・パートナを確認した後、OSTSはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。

  5. OSTSでは、OnBehalfOfフィールドに存在するトークンが検証されます。

    1. OnBehalfOfフィールドに存在するトークンのタイプを判断します。

    2. OAMトークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。

    3. OAMトークンのフォーマットおよびOAMトークンを検証し、トークンをユーザーにマップします。

    4. ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。

  6. OSTSではAppliesToフィールドが検査されます。

    • 存在する場合、OSTSはリライイング・パーティ・パートナのWSエンドポイント・マッピングを使用して、リライイング・パーティ・パートナへのAppliesTo URLへのマップを試行します。マッピングに成功した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされ、OSTSはこのパートナからリライイング・パーティ・パートナ・プロファイルを取得します。マッピングに失敗した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされず、OSTSはこのリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

    • 存在しない場合、OSTSはリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

  7. OSTSではTokenTypeフィールドが検査されます。

    • 存在する場合、OSTSはリクエスタ・パートナ・プロファイルを使用してTokenType文字列をローカル・トークン・タイプ値にマップし、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

    • 存在しない場合、OSTSはリライイング・パーティ・パートナ・プロファイルからデフォルト・トークン・タイプを取得し、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

  8. OSTSでは認証評価が行われ、リクエスタ・パートナが、フローで参照されるリライイング・パーティのトークンのリクエストを許可されていることが確認されます(詳細は「認可信頼ポリシー」を参照)。

  9. OSTSではトークンが作成されます。

    • 発行されるトークンがSAMLタイプの場合、発行テンプレートには名前IDの移入方法がリストされ、リライイング・パーティ・パートナ・プロファイルにはトークンで送信する必要がある属性がリストされます。発行テンプレートは、属性の名前および値を変換する必要があるかどうかを示します。発行テンプレートは、トークンの署名/暗号化を実行するかどうかを示します。

    • 発行されるトークンがSAMLタイプの場合、OSTSサーバーはKeyTypeを調べて、アサーションのサブジェクト確認メソッドを判断します。存在しない場合は、発行テンプレートからデフォルトの確認メソッドが使用されます。

  10. OSTSでは、クライアントが処理するレスポンスが作成されます。

    1. WS-Trust RSTRCを作成します。

    2. 返されたトークンを追加します。

    3. 必要に応じて証明鍵を追加します。

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

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

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

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

  • クライアントとして機能するカスタム・アプリケーション・モジュールでは、次の処理が行われます。

    • HTTPリクエストからのOAMセッション伝播トークンの取得

    • Oracle Security Token ServiceサーバーへのWS-Trustリクエストの送信(OAMセッション伝播トークンをOnBehalfOf要素として使用)

  • Webgateで保護され、WS-TrustリクエストをOracle Security Token Serviceに送信するクライアントWebアプリケーションを起動するWebアプリケーション

  • OSTSサーバーのURL: http://yourhost.domain.com:14100/sts/<endpoint>


    注意:

    <endpoint>を「STSエンドポイント」の項で構成したパスに置換します。

  • Webアプリケーションを保護するWebgateを備えたOHS 11g

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

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

    リバース・プロキシの構成: アイデンティティ伝播

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

  • 1つのリクエスタ・パートナ・プロファイル

  • 1つのリライイング・パーティ・パートナ・プロファイル

  • 1つの発行テンプレート

  • 1つのWS-Trust検証テンプレート

  • OSTSエンドポイント

  • ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Oracle Security Token ServiceにはLDAPサーバーが必要です。

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

WebLogic Server Identity Assertion Provider

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

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovider.war

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

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

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

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

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

Oracle Access Manager Identity Asserterの詳細

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

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

図16-7 IAP-OSTSの詳細

IAP-OSTSの詳細
「図16-7 IAP-OSTSの詳細」の説明

LDAP認証プロバイダの詳細

OPTIONAL JAASフラグを使用してLDAPのオーセンティケータを作成します。これは、OAMトークンを提供するOracle Access Managerのデフォルト・システム・ストアを指します。

図16-8では、これを説明しています。

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

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

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

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

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

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

トークン発行ポリシー

図16-10に示すように、IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成します。

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

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

Webgateによるアイデンティティ・アサーションの認証ポリシー

IAM Suiteアプリケーション・ドメイン内の認証ポリシーで「IDアサーション」ボックスが選択されていることを確認します。これにより、図16-10に示すように、Webgateは保護されたリソースのアイデンティティ・アサーションを実行できます。

図16-11 Webgateによるアイデンティティ・アサーションの認証ポリシー

アイデンティティ・アサーション認証ポリシー
「図16-11 Webgateによるアイデンティティ・アサーションの認証ポリシー」の説明

エンドポイントの構成

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

図16-12 アイデンティティ・アサーションの/wssuserエンドポイント

wssuserエンドポイント
「図16-12 アイデンティティ・アサーションの/wssuserエンドポイント」の説明

発行テンプレートの構成

発行テンプレートには、アイデンティティ伝播用の次の構成が必要です。

  • 名前: iap-issuance-template

  • 説明: カスタム発行テンプレート

  • トークン・タイプ: SAML 2.0

  • 署名鍵ID: osts_signing

  • 説明: カスタム発行テンプレート

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

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

  • パートナ名: iap-request-partner

  • リクエスタ・タイプ: STS_REQUESTER

  • パートナ・プロファイル: iap-requestor-profile

  • 説明: カスタム・リクエスタ

  • 信頼

  • ユーザー名トークン認証

    • ユーザー名 <Webサービス・クライアントで使用されるユーザー名を入力>

    • パスワード <Webサービス・クライアントで使用されるパスワードを入力>

    • パスワードの確認 <Webサービス・クライアントで使用されるパスワードを入力>

  • アイデンティティ属性の値:

    • httpbasicusername

    • sslclientcertdn

パートナ・プロファイル: リライイング・パーティ

次のように、アイデンティティ伝播の新しいリライイング・パーティ・プロファイルを作成します。

  • プロファイルID: iap-relyingparty-profile

  • 説明: iap-issuance-template

  • デフォルト・トークン・タイプ: SAML 2.0

  • デフォルト・テンプレート: iap-issuance-template

パートナ・プロファイル: リクエスタ

次のように、アイデンティティ伝播の新しいリクエスタ・プロファイルを作成します。

  • プロファイルID: iap-requestor-profile

  • 説明: iap-requestor-profileパートナ・プロファイル

  • デフォルト・リライイング・パーティ・プロファイル: iap-relyingparty-profile

WS-TRUSTの検証テンプレート

検証テンプレートには、アイデンティティ伝播用の次の構成が必要です。

  • 検証テンプレート名: iap_wstrust_validation_template

  • 説明: iap_wstrust_validation_template

  • トークン・プロトコル: WS-Trust

  • トークン・タイプ: OAM

  • タイムスタンプの存続期間:

これで、OAMトークンのシナリオを使用したアイデンティティ伝播の構成要件は完了です。

実装のテスト

構成の完了後、リソースにアクセスし、実装が正しく動作していることを確認できます。

Webgateでは、認証の成功時にユーザーの既存のセッションがない場合、OAM Serverにリダイレクトする必要があり、ユーザーはSTSサーバーによって送信されるRSTおよびRSTRを表示できることが必要です。

Cookieおよびヘッダー(切捨て)

アイデンティティ伝播のCookieおよびヘッダー

クライアントによって送信されるリクエスト・セキュリティ・トークン(切捨て)

クライアントによって送信されるセキュリティ・トークンの(切り捨てられた)リクエストを次に示します。

クライアントからのアイデンティティ伝播RST

OSTSサーバーによって送信されるリクエスト・セキュリティ・トークン・レスポンス(切捨て)

OSTSサーバーによって送信されるRSTへの(切り捨てられた)レスポンスを次に示します。

OSTSからのアイデンティティ伝播RSTR

シナリオ: On Behalf Ofユーザー名トークンを使用したWebサービス・セキュリティ

ここでは、次の内容について説明します。

ユーザー名トークンを使用したアイデンティティ伝播のコンポーネント相互作用

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

  1. ユーザーが保護されたリソースにアクセスを試みます。

  2. ユーザーが認証されます。

  3. WebLogicコンテナでは、ユーザーのアイデンティティがこのセッションのサブジェクトに設定されます。

  4. 最終的にリソースにアクセスした時点で、Webサービス・クライアントは現在のユーザー・サブジェクトからユーザーのアイデンティティを取得し、そのアイデンティティを使用してOnBehalfOf (OBO)トークンを生成した後、リクエスト・セキュリティ・トークン(RST)を作成してOSTSに送信します。

  5. Oracle Security Token Serviceでは、Webサービス・クライアントをリクエスタ・パートナとして認証します。

  6. Oracle Security Token ServiceではOBOトークン内にユーザー名トークンが表示され、ユーザーのアイデンティティがLDAP内のユーザー・レコードにマップされます。

  7. その後、Oracle Security Token Serviceではリクエスト・セキュリティ・トークン・レスポンスが生成されます。

  8. Oracle Security Token Serviceでは、クライアントにリクエスト・セキュリティ・トークン・レスポンスが送信されます。クライアントはリクエスト・セキュリティ・トークン・レスポンス(RSTR)内のトークンを使用して、リライイング・パーティがホストするサービスにアクセスするためのWebサービス・リクエストを作成できます。

ユーザー名トークンを使用したアイデンティティ伝播のRST属性および処理

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

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

  • SOAPヘッダーには、WSリクエスタを参照するユーザー名トークンが含まれています。ユーザー名トークンには、少なくとも1つのユーザー名とパスワードが含まれています。

  • SOAP本体にはWS-Trust RSTメッセージが含まれています。

  • RSTには、LDAP内のユーザーを参照するOnBehalfOfフィールドにユーザー名トークンが含まれています。

  • RSTには、リライイング・パーティWebサービスのエンドポイントを示すURLを保持するAppliesToフィールドが含まれている可能性があります。

  • RSTには、返す必要があるトークンのタイプを保持するTokenTypeフィールドが含まれている可能性があります。

  • RSTには、SAMLアサーションに対称証明鍵が必要な場合にSecretKeyを作成するときに使用されるランダム・データを保持するEntropyフィールドが含まれている可能性があります。

  • RSTには、SAMLアサーションの非対称証明鍵として使用される証明書または公開鍵を保持するUseKeyフィールドが含まれている可能性がありますが、このフィールドはOracle Security Token Serviceでは無視されます。

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

  1. クライアントは次の方法でリクエストを準備します。

    • SOAPメッセージを作成します。

    • クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。

    • WS-Trust RSTメッセージを作成します。

    • ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むユーザー名トークンを作成します。

    • SOAP本体にRSTメッセージを含めます。

  2. クライアントはOracle Security Token Service、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをOracle Security Token Service WSS検証テンプレートにマップします。

  3. Oracle Security Token Serviceでは着信リクエストが処理されます。

  4. Oracle Security Token Serviceは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。

    • ユーザー名トークンのフォーマットを検証します。

    • ユーザー名トークンに含まれる資格証明とOracle Security Token Serviceパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。

    • リクエスタ・パートナを確認した後、Oracle Security Token Serviceはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。

  5. Oracle Security Token Serviceでは、OnBehalfOfフィールドに存在するトークンが検証されます。

    • OnBehalfOfフィールドに存在するトークンのタイプを判断します。

    • ユーザー名トークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。

    • ユーザー名トークンを検証し、トークンをユーザーにマップします。

  6. Oracle Security Token ServiceではAppliesToフィールドが検査されます。

    • 存在する場合、Oracle Security Token Serviceはリライイング・パーティ・パートナのWSエンドポイント・マッピングを使用して、リライイング・パーティ・パートナへのAppliesTo URLへのマップを試行します。マッピングに成功した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされ、Oracle Security Token Serviceはこのパートナからリライイング・パーティ・パートナ・プロファイルを取得します。マッピングに失敗した場合、AppliesToフィールドはリライイング・パーティ・パートナにマップされず、Oracle Security Token Serviceはこのリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

    • 存在しない場合、Oracle Security Token Serviceはリクエスタ・パートナ・プロファイルからデフォルト・リライイング・パーティ・パートナ・プロファイルを取得します。

  7. Oracle Security Token ServiceではTokenTypeフィールドが検査されます。

    • 存在する場合、Oracle Security Token Serviceはリクエスタ・パートナ・プロファイルを使用してTokenType文字列をローカル・トークン・タイプ値にマップし、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

    • 存在しない場合、Oracle Security Token Serviceはリライイング・パーティ・パートナ・プロファイルからデフォルト・トークン・タイプを取得し、リライイング・パーティ・パートナ・プロファイルを使用して、送信トークンの作成に使用される発行テンプレートを取得します。

  8. Oracle Security Token Serviceでは認証評価が行われ、リクエスタ・パートナが、フローで参照されるリライイング・パーティのトークンのリクエストを許可されていることが確認されます(詳細は「認可信頼ポリシー」を参照)。

  9. Oracle Security Token Serviceではトークンが作成されます。

    • 発行されるトークンがSAMLタイプの場合、発行テンプレートには名前IDの移入方法がリストされ、リライイング・パーティ・パートナ・プロファイルにはトークンで送信する必要がある属性がリストされます。発行テンプレートは、属性の名前および値を変換する必要があるかどうかを示します。発行テンプレートは、トークンの署名/暗号化を実行するかどうかを示します。

    • 発行されるトークンがSAMLタイプの場合、Oracle Security Token ServiceサーバーはKeyTypeを調べて、アサーションのサブジェクト確認メソッドを判断します。存在しない場合は、発行テンプレートからデフォルトの確認メソッドが使用されます。

  10. Oracle Security Token Serviceでは、クライアントが処理するレスポンスが作成されます。

    • WS-Trust RSTRCを作成します。

    • 返されたトークンを追加します。

    • 必要に応じて証明鍵を追加します。

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

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

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

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

  • ユーザーがリクエストするWebアプリケーション。このWebアプリケーションはユーザーを認証した後、リモートWebサービス・プロバイダへのSOAPメッセージの送信を試行します。そのSOAP交換の一部として、WS-SecurityクライアントはWebサービス・プロバイダのWS-Securityポリシーをダウンロードし、Oracle Security Token Serviceに接続してWebサービス・プロバイダがリクエストしたトークンを取得し、Webサービス・プロバイダにSOAPメッセージを含むセキュリティ・トークンを送信します。

  • OSTSサーバーのURL: http://yourhost.domain.com:14100/sts/<endpoint>


    注意:

    <endpoint>を「STSエンドポイント」の項で構成したパスに置換します。

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

  • 1つのリクエスタ・パートナ・プロファイル

  • 1つのリライイング・パーティ・パートナ・プロファイル

  • 1つの発行テンプレート

  • 1つのWS-Trust検証テンプレート

  • Oracle Security Token Serviceのエンドポイント

  • ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Oracle Security Token ServiceにはLDAPサーバーが必要です。

  • 目的のLDAPサーバーが、Oracle Security Token Serviceを備えたOracle Access Managerのデフォルト・アイデンティティ・ストアとして構成されていることを確認します。

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

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

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

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

トークン発行ポリシー

図16-14に示すように、IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成します。

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

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

エンドポイントの構成

図16-15に示すように、/wss11userエンドポイントが必要です。このエンドポイントはデフォルトのWS-Security検証ポリシーで保護されます。これは、RSTをポストするためにWebアプリケーションで使用されるエンドポイントです。

図16-15 アイデンティティ・アサーションの/wss11userエンドポイント

アイデンティティ・アサーションの/wss11userエンドポイント
「図16-15 アイデンティティ・アサーションの/wss11userエンドポイント」の説明

発行テンプレートの構成

発行テンプレートには、アイデンティティ伝播用の次の構成が必要です。

  • 名前: saml-issuance-template

  • 説明: SAML発行テンプレート

  • トークン・タイプ: SAML 2.0

  • 署名鍵ID: osts_signing

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

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

  • パートナ名: requester-partner

  • パートナ・タイプ: リクエスタ

  • パートナ・プロファイル: requester-profile

  • 説明: リクエスタ

  • 信頼

  • ユーザー名トークン認証

    • ユーザー名 <Webサービス・クライアントで使用されるユーザー名を入力>

    • パスワード <Webサービス・クライアントで使用されるパスワードを入力>

    • パスワードの確認 <Webサービス・クライアントで使用されるパスワードを入力>

  • アイデンティティ属性の値:

    • httpbasicusername

    • sslclientcertdn

パートナ・プロファイル: リライイング・パーティ

次のように、アイデンティティ伝播の新しいリライイング・パーティ・プロファイルを作成します。

  • プロファイルID: relying-party-profile

  • 説明: リライイング・パーティ・プロファイル

  • デフォルト・トークン・タイプ: SAML 2.0

  • 発行テンプレート: SAML 2.0のiap-issuance-template

パートナ・プロファイル: リクエスタ

次のように、アイデンティティ伝播の新しいリクエスタ・プロファイルを作成します。

  • プロファイルID: requester-profile

  • 説明: リクエスタ・パートナ・プロファイル

  • デフォルト・リライイング・パーティ・プロファイル: relying-party-profile

WS-TRUSTの検証テンプレート

検証テンプレートには、アイデンティティ伝播用の次の構成が必要です。

  • 検証テンプレート名: username_wstrust_validation_template

  • 説明: ユーザー名WS-Trustテンプレート

  • トークン・プロトコル: WS-Trus

  • トークン・タイプ: ユーザー名

  • タイムスタンプの存続期間: 600

  • 資格証明検証の有効化: 選択解除

  • トークン・マッピング:

    • トークンの宛先ユーザーのマップ: 選択

    • 簡易ユーザー・マッピングの有効化: 選択

    • データストア属性: uid

これで、ユーザー名トークンのシナリオを使用したアイデンティティ伝播の構成要件は完了です。

例16-1 交換のサンプル: クライアントによって送信されるリクエスト・セキュリティ・トークン

これは、クライアントによって送信されるセキュリティ・トークンのリクエストです。

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
<SOAP-ENV:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken><wsse:Username>requester-test</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welcome1</wsse:Password></wsse:UsernameToken></wsse:Security>
<wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action></SOAP-ENV:Header>
<SOAP-ENV:Body><wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"><wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType><wst:OnBehalfOf>
<wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Username>user-alice</wsse:Username>
</wsse:UsernameToken></wst:OnBehalfOf></wst:RequestSecurityToken></SOAP-ENV:Body></SOAP-ENV:Envelope>

例16-2 OSTSサーバーによって送信されるリクエスト・セキュリティ・トークン・レスポンス

これは、OSTSサーバーによって送信されるRSTへのレスポンスです。

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header><Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal</Action>
</env:Header><env:Body><wst:RequestSecurityTokenResponseCollection xmlns:ns6="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wst:RequestSecurityTokenResponse><wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType><wst:RequestedSecurityToken><saml:Assertion AssertionID="id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-" IssueInstant="2011-04-22T18:48:05Z" Issuer="adc2110618.us.oracle.com" MajorVersion="1" MinorVersion="1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saml:Conditions NotBefore="2011-04-22T18:48:05Z" NotOnOrAfter="2011-04-22T19:48:05Z"/><saml:AttributeStatement><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user-alice@oracle.com</saml:NameIdentifier><saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod></saml:SubjectConfirmation>
</saml:Subject><saml:Attribute AttributeName="sn" AttributeNamespace="urn:oracle:security:fed:attrnamespace"><saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">user-alice-last</saml:AttributeValue></saml:Attribute>
</saml:AttributeStatement><dsig:Signature><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><dsig:Reference URI="#id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>1GF2ZT9h+gs8sxyO+/yG/N6jxk8=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo>
<dsig:SignatureValue>InZVb5aRM5+KKI1VqXg9HiIgLjKyGm0VkD6sMJ/8SIbFbbxuNm7Mnky5W35p2P0c5bCPRx02uzLEE4KhLkyM2GsLsVaDNkRztGMphQW/Mcg7DprJIEyR2OYMYDOQSipa/k2K98C4zO/RNivo1KvyJsd6a3h6CBHwoO1RKip039w=</dsig:SignatureValue>
<dsig:KeyInfo><dsig:X509Data><dsig:X509Certificate>MIIB/DCCAWWgAwIBAgIBCjANBgkqhkiG9w0BAQQFADAjMSEwHwYDVQQDExhhZGMyMTEwNjE4LnVzLm9yYWNsZS5jb20wHhcNMTEwNDE5MTUxNTI2WhcNMjEwNDE2MTUxNTI2WjAjMSEwHwYDVQQDExhhZGMyMTEwNjE4LnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJnSxVc86TGcwewieaueIVG33C3Qouve6HuJxHsoM8cRRkJcmv+0auyvDLJfYAEOfHo5OsF4+za11iNPln9ZFaOjUy/Y8JC0kSVxatgU36RveIrpOJvp978Oa6IlMNUtdFf8q3TrsizspE2hnbLY+0SMofgnAPcJEKPxkd6b0b0ZAgMBAAGjQDA+MAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/BAUDAwfYADAdBgNVHQ4EFgQU47ZqWHgTOmZO67uw4YzsbrRMNOswDQYJKoZIhvcNAQEEBQADgYEAH0QIHaLMN/7hD2VP0SLOCtNdEmY5IqLY1CDW+GpUZZ9e+MCgE/rvr34566D9Q8lvET6T9u+sg3h+hSkb3gE4a4wgShH/V7nfHzx8ZntlxccvCZK6ePVDMt0Lfj2iVnE7IJxou4bO0w0m9DrvyKop7ncnSEzaVpxIZgCDo7+8Zdw=</dsig:X509Certificate>
</dsig:X509Data></dsig:KeyInfo></dsig:Signature></saml:Assertion></wst:RequestedSecurityToken><wst:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-</wsse:KeyIdentifier></wsse:SecurityTokenReference></wst:RequestedAttachedReference>
<wst:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-</wsse:KeyIdentifier></wsse:SecurityTokenReference></wst:RequestedUnattachedReference>
<wst:Lifetime><wsu:Created>2011-04-22T18:48:05Z</wsu:Created><wsu:Expires>2011-04-22T19:48:05Z</wsu:Expires></wst:Lifetime></wst:RequestSecurityTokenResponse></wst:RequestSecurityTokenResponseCollection></env:Body></env:Envelope>