この章では、セキュリティ・トークン・サービスの実装シナリオおよび処理シナリオをいくつか示します。シナリオの詳細に関係なく、構成タスクとトークン処理の両方に多数の類似点があります。この章の内容は次のとおりです。
ここで取り上げる抽象モデルは、このようなモデルをサポートするためにSecurity Token Serviceに設定されている要件を示すために役立ちます。
ここでは、セキュリティ・トークン・エコシステムという語句を使用して、セキュリティ・トークンが使用される一般的な環境を表します。このような環境では、環境に必要なセキュリティ・モデルに基づいて、セキュリティ・トークンを使用してブローカ・トラストやシングル・サインオンなどの最終目標を達成できます。ここに示すように、環境およびセキュリティ・トークンのタイプに関係なく、いくつかの側面はすべてのモデルに共通しています。
図31-1に、トークン発行局、トークン・リクエスタ、トークン・コンシューマ、セキュリティ・トークンなどを含む一般的なトークン・エコシステムを示します。
アクターとプロセスの概要: 一般的なトークン・エコシステム
トークン・リクエスタは、トークン発行局にセキュリティ・トークンをリクエストします。
このセキュリティ・トークンは、サービス・プロバイダ(セキュリティ・トークンを受け入れるトークン・コンシューマ)が提供するサービスと通信し、サービスへのアクセスをリクエストする必要があります。
トークン・リクエスタは、トークン発行局のパートナである可能性があります(通常はトークン発行局に登録されます)。
トークン・リクエスタは、エンド・ユーザーである可能性があります(通常はトークン発行局には登録されません)。
トークン発行局(Access Manager、Security Token Serviceなど)は、次のようにセキュリティ・トークン・リクエストを受信および処理し、セキュリティ・トークンを返します。
入力資格証明を認証します。
特定のトークン・コンシューマのセキュリティ・トークンのリクエストを認可されているトークン・リクエスタを指定するトークン発行ポリシーに基づいて、セキュリティ・トークン・リクエストを認可します。
トークン・コンシューマ(通常はサービス・プロバイダ)。
セキュリティ・トークンをサービス・リクエストの一部として受け入れ、入力セキュリティ・トークンの有効性に基づいてサービスを提供します。
トークン発行局を使用して入力セキュリティ・トークンを検証します。
注意: トークン・コンシューマは通常、トークン発行局の登録済パートナです。トークン・コンシューマはリライイング・パーティとも呼ばれます。これは、トークン・リクエスタ認証のためにトークン発行局を信頼し、依存しているためです。トークン・コンシューマ(リライイング・パーティ・パートナ)は、Webアプリケーション(Access Managerの場合、Security Token Serviceがトークン発行局)またはSTSリライイング・パーティWebサービスです。 |
これは、ユーザーのアイデンティティ情報をWebアプリケーションからWebサービス・プロバイダに伝播する必要があるデプロイメントです。Webサービス・プロバイダは、Webアプリケーションと同じセキュリティ・ドメインに存在することも、別のセキュリティ・ドメインに存在することもできます。
アイデンティティ伝播とは、元のユーザー・コンテキストを元のセキュリティ層またはドメイン境界の外側で表示できるようになることです。ユーザー・セキュリティ・コンテキストは、ステップアップ認証、認可、監査/内部アプリケーション固有のビジネス・ロジックなど、層またはドメイン固有のセキュリティ・ニーズをサポートするために、異なるセキュリティ層またはドメインに伝播されます。
ID伝播は、最初のノードで確立されたアイデンティティ・コンテキストを後続のノードに伝播するときに、そのアイデンティティのコンテキストでリクエストをさらに処理できるようにするために、リクエストの分散処理で発生すると言われています。
ID伝播は複数の方法で実行できます。IDプロバイダがIDアサーションのトラスト・ブローカとして機能する、ブローカ・トラスト・モデルに基づく方法があります。ここで説明する内容は、このモデルに関連しています。
図31-3に、ブローカ・トラスト・モデルのID伝播シナリオを示します。このシナリオでは、ユーザー向けアプリケーションがエンド・ユーザーのコンテキストでバックエンド・サービス・アプリケーションによる処理を要求する必要があります。ID伝播の主な側面を明らかにするために、エンド・ユーザー、アプリケーションおよびバックエンド・サービス・アプリケーション間の他のすべての相互作用および関係の詳細は無視されます。
アクターとプロセスの概要: アイデンティティ伝播
IDアサーション・トークン・リクエスタ(エンド・ユーザー向けアプリケーション)は、エンド・ユーザーへのアクセス時に、アイデンティティ・プロバイダの認証およびIDアサーション・トークンをリクエストします。
注意: IDアサーション・トークン・リクエスタの例には、OAMで保護されるWebアプリケーションがあります。IDアサーション・トークン・リクエストは、暗黙的な場合もあれば、IDプロバイダのポリシーから導かれる場合もあります。 |
IDプロバイダ(Security Token Service)はリクエストを処理し、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。
IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。
IDアサーション・トークン・コンシューマ(Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。
詳細は、次のトピックを参照してください。
図31-4に、Security Token ServiceとAccess Managerを使用したアイデンティティ伝播の一般的なデプロイメント・トポロジを示します。
図31-5に、Security Token ServiceとAccess Managerを使用したアイデンティティ伝播の処理を示します。詳細は、図の後に説明します。
プロセスの概要: アイデンティティ伝播のコンポーネント相互作用
ユーザーが保護されたリソースにアクセスを試みます。
Webgateはリソースを保護しており、認証および認可のためにAccess Managerにリクエストを送信します。
Access Managerでは、このWebgateアプリケーション・ドメイン用に構成されたポリシーを使用してユーザーが認証されます。レスポンス・タイプ「IDENTITY_ASSERTION」がこのWebgate用に構成されていることを確認し、IDアサーション・トークンも生成します。
Access ManagerはWebgateに認証およびIDアサーションを送信します。
Webgateでは、レスポンスを処理し、IDアサーション・トークンをヘッダー(Webgateがインストールされている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サービス・リクエストを作成できます。
次の属性を持つ着信リクエスト・セキュリティ・トークン(RST)の場合、リクエストを処理し、トークンを発行するようにSecurity Token Serviceを構成する必要があります。
OAMトークンを使用したアイデンティティ伝播のRST属性
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では無視されます。
プロセスの概要: OAMトークンを使用したアイデンティティ伝播
クライアントは次の方法でリクエストを準備します。
SOAPメッセージを作成します。
クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。
WS-Trust RSTメッセージを作成します。
ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むOAM ID伝播トークンを作成します。
SOAP本体にRSTメッセージを含めます。
クライアントはSecurity Token Service、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをSecurity Token Service WSS検証テンプレートにマップします。
Security Token Serviceでは着信リクエストが処理されます。
Security Token Serviceは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。
ユーザー名トークンのフォーマットを検証します。
ユーザー名トークンに含まれる資格証明とSecurity Token Serviceパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。
リクエスタ・パートナを確認した後、Security Token Serviceはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。
Security Token Serviceでは、OnBehalfOfフィールドに存在するトークンが検証されます。
OnBehalfOfフィールドに存在するトークンのタイプを判断します。
OAMトークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。
OAMトークンのフォーマットおよびOAMトークンを検証し、トークンをユーザーにマップします。
ユーザーを参照し、そのユーザーを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では、クライアントが処理するレスポンスが作成されます。
WS-Trust RSTRCを作成します。
返されたトークンを追加します。
必要に応じて証明鍵を追加します。
このトピックでは、アイデンティティ伝播シナリオの構成要件を示します。内容は次のとおりです。
構成の概要: OAMトークンを使用したアイデンティティ伝播
アイデンティティ伝播の環境と実装タスクの概要を次に示します。
クライアントとして機能するカスタム・アプリケーション・モジュールでは、次の処理が行われます。
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のリバース・プロキシ・マッピングを次に示します。
アイデンティティ伝播のトークン処理を実装するには、次のSecurity Token Service構成が必要です。
1つのリクエスタ・パートナ・プロファイル
1つのリライイング・パーティ・パートナ・プロファイル
1つの発行テンプレート
1つのWS-Trust検証テンプレート
Security Token Serviceのエンドポイント
ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Security Token ServiceにはLDAPサーバーが必要です。
目的のLDAPサーバーが、デフォルト・アイデンティティ・ストアとして構成されていることを確認します。
WebLogic Server Identity Assertion Provider
IDアサーション・プロバイダwarをデプロイします。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
図31-6に、このシナリオに必要なWebLogic Server Identity Assertion Providerを示します。
図31-6 必要なv1.0 WebLogic Server Identity Assertion Provider
Access Manager Identity Asserterの詳細
IAP-Security Token Serviceアイデンティティ・アサータを最初に設定してから、REQUIRED Controlフラグを使用して設定する必要があります。OAM_REMOTE_USER1のSSOヘッダー名を使用して、「Active Types」をObSSOCookieおよびOAM_REMOTE_USERとして設定する必要があります。
図31-7に構成を示します。
LDAP認証プロバイダの詳細
OPTIONAL JAASフラグを使用してLDAPのオーセンティケータを作成します。これは、Access Managerトークンを提供するOracle Access Managementのデフォルト・システム・ストアを指します。
図31-8では、これを説明しています。
デフォルト・アイデンティティ・ストアの構成
図31-9に、Oracle Access Managementコンソール内のデフォルト・アイデンティティ・ストアの構成を示します。
トークン発行ポリシー
図31-10に示すように、IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成します。
WebgateによるIDアサーションの認証ポリシー・レスポンス
IDアサーションは、エンド・ユーザー(およびそのOAMセッション)を表すAccess Managerから発行されたトークンのID伝播で必要です。
IDアサーション・トークンは、正常に認証された後に生成され、ポリシー・レスポンス(名前が「OAM_IDENTITY_ASSERTION」で値がSAMLトークンというHTTPヘッダー)として返されます。
Access Managerによって保護されているWebアプリケーションであるSecurity Token Serviceクライアントが、リライイング・パーティ(ID伝播ユースケース)へのプロキシ・アクセスを取得するためにトークンをリクエストすると、エンド・ユーザーを表すOAM IDアサーション・トークンを渡すように要求されます。
IDプロバイダ(Access Manager)はリクエストを処理して、認証トークンおよびIDアサーション・トークンを返します。IDアサーション・トークンは、それ自体でユーザー・セッションを表すものではないため、リソースまたはサービスへの直接アクセスをリクエストするために単独で使用することはできません。
IDアサーション・トークン・リクエスタは、後でエンド・ユーザー・セッション中にバックエンド・サービス処理リクエスト(エンド・ユーザーの代理)の一環としてこのトークンを使用します。
IDアサーション・トークン・コンシューマ(Security Token Service)は、リクエスト処理の一環として、まずIDアサーション・トークンを検証し、次に(検証が成功した場合は)エンド・ユーザー・アイデンティティのコンテキスト内でリクエストを処理します。
IAM Suiteアプリケーション・ドメイン内の認証ポリシー・レスポンスの一部として「IDアサーション」ボックスが選択されていることを確認します。これにより、保護されているリソースに対してWebgateでIDアサーションを実行できるようになります。
各レスポンスを追加すると、次のように通知される場合があります: 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)
エンドポイントの構成
図31-11に示すように、/wss10userエンドポイントが必要です。このエンドポイントはデフォルトのWS-Security検証ポリシーで保護されます。これは、RSTをポストするためにWebアプリケーションで使用されるエンドポイントです。
発行テンプレートの構成
発行テンプレートには、アイデンティティ伝播用の次の構成が必要です。
名前: 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およびヘッダー(切捨て)
クライアントによって送信されるリクエスト・セキュリティ・トークン(切捨て)
クライアントによって送信されるセキュリティ・トークンの(切り捨てられた)リクエストを次に示します。
セキュリティ・トークン・サービスによって送信されるリクエスト・セキュリティ・トークン・レスポンス(切捨て)
セキュリティ・トークン・サービスによって送信されるRSTへの(切り捨てられた)レスポンスを次に示します。
ここでは、次の内容について説明します。
プロセスの概要: アイデンティティ伝播のコンポーネント相互作用
ユーザーが保護されたリソースにアクセスを試みます。
ユーザーが認証されます。
WebLogicコンテナでは、ユーザーのアイデンティティがこのセッションのサブジェクトに設定されます。
最終的にリソースにアクセスした時点で、Webサービス・クライアントは現在のユーザー・サブジェクトからユーザーのアイデンティティを取得し、そのアイデンティティを使用してOnBehalfOf (OBO)トークンを生成した後、リクエスト・セキュリティ・トークン(RST)を作成してSecurity Token Serviceに送信します。
Security Token Serviceでは、Webサービス・クライアントをリクエスタ・パートナとして認証します。
Security Token ServiceではOBOトークン内にユーザー名トークンが表示され、ユーザーのアイデンティティがLDAP内のユーザー・レコードにマップされます。
その後、Security Token Serviceではリクエスト・セキュリティ・トークン・レスポンスが生成されます。
Security Token Serviceでは、クライアントにリクエスト・セキュリティ・トークン・レスポンスが送信されます。クライアントはリクエスト・セキュリティ・トークン・レスポンス(RSTR)内のトークンを使用して、リライイング・パーティがホストするサービスにアクセスするためのWebサービス・リクエストを作成できます。
次の属性を持つ着信リクエスト・セキュリティ・トークン(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フィールドが含まれている可能性がありますが、このフィールドはSecurity Token Serviceでは無視されます。
プロセスの概要: OAMトークンを使用したアイデンティティ伝播
クライアントは次の方法でリクエストを準備します。
SOAPメッセージを作成します。
クライアントを参照し、SOAPヘッダー内にそのクライアントを含むユーザー名トークンを作成します。
WS-Trust RSTメッセージを作成します。
ユーザーを参照し、そのユーザーをRSTのOnBehalfOfフィールドに含むユーザー名トークンを作成します。
SOAP本体にRSTメッセージを含めます。
クライアントはSecurity Token Service、WS-Securityユーザー名トークン(UNT)ポリシーで保護されたエンドポイントにメッセージを送信し、そのエンドポイントをSecurity Token Service WSS検証テンプレートにマップします。
Security Token Serviceでは着信リクエストが処理されます。
Security Token Serviceは、WS-Security検証テンプレートに含まれる設定を使用してSOAPヘッダー内のトークンを検証します。
ユーザー名トークンのフォーマットを検証します。
ユーザー名トークンに含まれる資格証明とSecurity Token Serviceパートナ・ストアを比較することで、このトークンをリクエスタ・パートナにマップします。
リクエスタ・パートナを確認した後、Security Token Serviceはこのリクエスタに関連付けられたリクエスタ・パートナ・プロファイルを取得します。
Security Token Serviceでは、OnBehalfOfフィールドに存在するトークンが検証されます。
OnBehalfOfフィールドに存在するトークンのタイプを判断します。
ユーザー名トークン・タイプに使用されるWS-Trust検証テンプレートをリクエスタ・パートナ・プロファイルから取得します。
ユーザー名トークンを検証し、トークンをユーザーにマップします。
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では、クライアントが処理するレスポンスが作成されます。
WS-Trust RSTRCを作成します。
返されたトークンを追加します。
必要に応じて証明鍵を追加します。
このトピックでは、アイデンティティ伝播シナリオの構成要件を示します。内容は次のとおりです。
構成の概要: ユーザー名トークンを使用したアイデンティティ伝播
アイデンティティ伝播の環境と実装タスクの概要を次に示します。
ユーザーがリクエストするWebアプリケーション。このWebアプリケーションはユーザーを認証した後、リモートWebサービス・プロバイダへのSOAPメッセージの送信を試行します。そのSOAP交換の一部として、WS-SecurityクライアントはWebサービス・プロバイダのWS-Securityポリシーをダウンロードし、Security Token Serviceに接続してWebサービス・プロバイダがリクエストしたトークンを取得し、Webサービス・プロバイダにSOAPメッセージを含むセキュリティ・トークンを送信します。
セキュリティ・トークン・サービスURL: http://myhost.domain.com:14100/sts/<endpoint>
注意: <endpoint>を「STSエンドポイント」の項で構成したパスに置換します。 |
アイデンティティ伝播のトークン処理を実装するには、次のSecurity Token Service構成が必要です。
1つのリクエスタ・パートナ・プロファイル
1つのリライイング・パーティ・パートナ・プロファイル
1つの発行テンプレート
1つのWS-Trust検証テンプレート
Security Token Serviceのエンドポイント
ユーザーを参照するユーザー名トークンをLDAPユーザー・レコードにマップし、そのレコードを使用して送信トークンを移入するために、Security Token ServiceにはLDAPサーバーが必要です。
目的のLDAPサーバーが、Access Managerのデフォルト・アイデンティティ・ストアとして構成されていることを確認します。
デフォルト・アイデンティティ・ストアの構成
図31-12に、Oracle Access Managementコンソール内のデフォルト・アイデンティティ・ストアの構成を示します。
図31-12 Access Managerに定義されているデフォルト・アイデンティティ・ストア
トークン発行ポリシー
図31-13に示すように、IAM Suiteアプリケーション・ドメイン内にリソースURLのトークン発行ポリシーを作成します。
エンドポイントの構成
図31-14に示すように、/wss11userエンドポイントが必要です。このエンドポイントはデフォルトのWS-Security検証ポリシーで保護されます。これは、RSTをポストするためにWebアプリケーションで使用されるエンドポイントです。
発行テンプレートの構成
発行テンプレートには、アイデンティティ伝播用の次の構成が必要です。
名前: 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-Trust
トークン・タイプ: ユーザー名
タイムスタンプの存続期間: 600
資格証明検証の有効化: 選択解除
トークン・マッピング:
トークンの宛先ユーザーのマップ: 選択
簡易ユーザー・マッピングの有効化: 選択
データストア属性: uid
これで、ユーザー名トークンのシナリオを使用したアイデンティティ伝播の構成要件は完了です。
例31-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>
例31-2 セキュリティ・トークン・サービスによって送信されるリクエスト・セキュリティ・トークン・レスポンス
セキュリティ・トークン・サービスによって送信される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="myhost.uk.example.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@mycompany.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>