| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
Oracle Access Managementセキュリティ・トークン・サービスは、トークンの取得、更新および取消しのためのモデルにおいて、プロトコルやセキュリティ・インフラストラクチャに依存せず、その一貫性と効率性を促進するための基盤をセキュリティ・インフラストラクチャに提供します。インタフェースの標準化セットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。セキュリティ・トークン・サービスは、セキュリティ・ドメインまたは管理境界をまたいでWebブラウザから、リソースにアクセスするユーザーに対するフェデレーテッドSSOとシングル・ログアウト(SLO)をサポートします。
次の項で、セキュリティ・トークン・サービスの概要を説明します。
Security Token Serviceは、Web Service (WS) Trustベースのトークン・サービスで、Webサービス間におけるポリシー主導の信頼の仲介および安全なアイデンティティ伝播とトークン交換を可能にします。セキュリティ・トークン・サービスは、セキュリティおよびアイデンティティ・サービスとしてデプロイし、企業およびそのサービス・プロバイダの内部において、分散WebサービスまたはフェデレーテッドWebサービスの統合を単純化するために使用できます。
|
注意: セキュリティ・トークン・サービスは、主としてOASIS WS-Trustプロトコルに基づきますが、SOAPメッセージに含まれるその他のWS-*プロトコルの処理は委任します。 |
セキュリティ・トークン・サービスは、Webサービス・コンシューマ(WSC)とWebサービス・プロバイダ(WSP)との間での信頼を仲介し、プロバイダとコンシューマに対してセキュリティ・トークンのライフサイクル管理サービスを提供します。これにより、SAML、WS-Federation、ライブラリ、OpenIDなどの様々なフェデレーション・プロトコルを利用できるようになります。Oracle Access Managementセキュリティ・トークン・サービス(セキュリティ・トークン・サービス)はAccess Managerとともにデプロイされ、サービスとして起動する必要があります。
Security Token Serviceは、Oracle Access Management 11gとともに管理対象サーバー上にインストールします。各管理対象サーバーは、通信チャネルをオープンするためにAccess Managerに登録する必要があります。Security Token Serviceでは、共有サービスの共通インフラストラクチャおよびAccess Manager 11g管理モデルが利用されます。すべてのセキュリティ・トークン・サービス・システムはOracle Access Managementコンソールを使用して構成され、統一された一貫性のある管理機能を提供します。また、セキュリティ・トークン・サービスは、サード・パーティのセキュリティ・トークン・サービスと相互運用します。
Security Token ServiceはAccess Managerに準拠し、Access Managerと共存します(トークンをリクエストするWebクライアントのプライマリ・オーセンティケータとしてAccess Managerを使用)。セキュリティ・トークン・サービスはOracle Web Services Managerエージェントも使用します。Webゲートは、アイデンティティ伝播用のエージェントとして使用されます。Webゲートは、通信チャネルをオープンするためにAccess Manager 11gに登録する必要があります。Security Token Serviceは次の処理を実行します。
STS監査イベントを統合
Oracle Access ManagementコンソールおよびWLSTスクリプトにおいて、使用可能なSecurity Token Serviceメソッドを公開してパートナのデータを管理
Security Token Serviceのユースケースおよび構成モデルに固有の検証操作を実行
|
注意: Security Token Serviceでは、診断、モニタリング、監査および高可用性のためのフレームワーク、ガイドラインおよび手法について、Oracle Access Management 11gで使用されているものと同じものが採用されています。詳細は、第III部「ロギング、監査、レポートおよびパフォーマンスのモニタリング」を参照してください。 |
セキュリティ・トークン・サービス11gのインフラストラクチャは、表34-1で説明します。
表34-1 セキュリティ・トークン・サービス11gのインフラストラクチャ
| コンポーネント | 説明 |
|---|---|
|
デフォルト信頼キーストア |
署名/暗号化に使用されるSecurity Token Serviceの秘密鍵は、Access Managerで使用される共通キーストアに格納されます。Security Token ServiceおよびAccess Managerでは、共通インフラストラクチャ証明書検証モジュールが使用されます。証明書の検証中に使用される信頼できる証明書および証明書失効リスト(CRL)は、信頼キーストアおよびCRLのZIPファイルに格納されます。Security Token Serviceの構成には、OCSP/CDPの設定が格納されます。 トークン・セキュリティ・キー・ペアは、Access Manager/Security Token Serviceキーストアに移入されます。 注意: Oracle WSMエージェントをセキュリティ・トークン・サービスの実装でWS_Trustとして使用しているときは、常にOracle WSMエージェント・キーストアとセキュリティ・トークン・サービス/Access Managerキーストアを別々に使用することを強くお薦めします。この2つをマージしないでください。そのようにしないと、Access Manager/Security Token ServiceキーがOPSSによって認可された任意のモジュールでキーストアへのアクセスに使用できるようになり、Access Managerキーがアクセスされる可能性があります。 |
|
デフォルトのユーザー・アイデンティティ・ストア |
Security Token Serviceは、Oracle Access Managementコンソールの「システム構成」の「共通構成」セクションで構成されたユーザー・アイデンティティ・ストアに対してユーザーを認証およびマッピングします。Security Token Serviceは、着信トークンをデフォルト・ユーザー・アイデンティティ・ストアのユーザー・レコードおよびユーザー属性にマッピングし、これがAccess ManagerとSecurity Token Serviceの両方と連動します。 |
|
証明書 |
Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Security Token ServiceをホストするOAMサーバーは一意に識別されます。
これにより、暗号化のデータおよび識別子に関して、2つのサーバーが同一ではないことが確認されます。サード・パーティ・モジュールにより一方のサーバーに付与された信頼は、識別子と暗号キーが異なるため、他方のサーバーには付与されません。同一の鍵、同一の識別子がない場合、認可ポリシーは拒否モードです。 |
|
Oracle Coherence |
Security Token Serviceは、Oracle Coherenceモジュールと統合され、Security Token Serviceのすべての物理インスタンス間でWS-Trustのランタイム・データが格納および共有されます。UserNameToken Nonceは、Coherenceストアに格納されます。この実装では、Security Token Service以外では一般的ではない次の要件がサポートされます。
|
セキュリティ・トークンには、信頼をアサートするために使用される要求と文が含まれます。Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。こうした資格証明は、信頼しているセキュリティ・トークン・サービスから取得できます。
|
注意: 相互運用可能なセキュリティ・トークンを入手するには、Webサービス・クライアントとWebサービスの両者がそのSecurity Token Serviceを信頼している必要があります。 |
今日のIT環境には、WebアプリケーションのSSOおよびセッション管理を容易にするための数多くのタイプのセキュリティ・トークン(ほとんどがブラウザCookieに基づいています)があります。その他のトークン・タイプには、Kerberos (主にWindowsネイティブ認証用)、Security Assertion Markup Language (SAML)アサーションに加えてデジタル証明書もあります。
表34-2は、セキュリティ・トークン・サービスの一般的な用語について説明しています。
表34-2 セキュリティ・トークン・サービスの用語
| 用語 | 説明 |
|---|---|
|
セキュリティ・トークン |
メッセージの完全性と機密性を保護するために、信頼するセキュア・トークン・サービスにより発行されたトークンを使用してメッセージを保護するセキュリティ・メカニズム。発行されたトークンに含まれるキーは、サーバー用に暗号化され、署名用および暗号化用の新しいキーを導出するために使用されます。 サービス・プロバイダとコンシューマが潜在的に異なる管理対象環境にいる場合は、単一のセキュリティ・トークン・サービスを使用して信頼のチェーンを確立できます。サービスはクライアントを直接信頼するのではなく、指定されたセキュリティ・トークン・サービスにより発行されたトークンを信頼します。セキュリティ・トークン・サービスは第2のサービスの役割を担い、このサービスによりクライアントが安全に認証されることになります。 |
|
セキュリティ・トークン・サービス |
サーバーとの明示的な信頼関係(およびクライアントとの信頼関係)がある、信頼されたサード・パーティ。Security Token Serviceはその一例です。 |
|
Secure Token Service |
様々なアイデンティティ・ドメインとインフラストラクチャ層との間における信頼の仲介に関して標準ベースの統合されたメカニズムを提供する共有Webサービス。 このサービスは、それ自体が信頼する証拠に基づいてアサーションを作成することにより、そのサービスを信頼する他者(または特定の受信者)に対して、WS-Trust仕様で定義されたプロトコルを実装します。このプロトコルは、セキュリティ・トークンの発行、更新、取消および検証のために、メッセージ書式およびメッセージ交換パターンを定義します。 信頼を伝達するために、サービスは、セキュリティ・トークンまたはセキュリティ・トークンのセットに関する知識を証明するものを必要とします。たとえば、XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは送信者の秘密鍵を使用して署名され、その署名は送信者の公開鍵を使用して検証されます。 |
|
リクエスト・セキュリティ・トークン(RST) |
セキュリティ・トークンのリクエスト。 |
|
リクエスト・セキュリティ・トークン・レスポンス(RSTR) |
セキュリティ・トークンのリクエストへのレスポンスとして、リクエストしたユーザーの要求を使用して、Security Token Serviceにより生成されたレスポンス。 |
|
代理(OBO) |
OBOリクエスト・セキュリティ・トークン(RST)は、本来のクライアントのアイデンティティのみが重要な場合に使用されます。OBO RSTは、リクエスタが必要としているトークンに、次の1つのエンティティのみに関する要求が含まれているをことを示します。
|
|
ActAs |
|
|
トークン交換 |
あるセキュリティ・トークンと別のセキュリティ・トークンの交換。リクエスタは、(Webサービスを開始するために)特定のトークンを必要とします。リクエスタは、Security Token Serviceを使用して着信トークンとサービスが必要とするトークンを交換します。 |
|
WS-Security |
Web Services Security (WS-Security)は、XML暗号化により機密保護を、XML署名によりデータ整合性を実現するSOAPセキュリティ拡張機能を指定します。 WS-Securityで使用される最も一般的なセキュリティ・トークンは、Username、X.509証明書、SAMLアサーション、およびKerberosチケットです(すべてがOracle Web Service Managerによりサポートされています)。 WS-Securityには、タイプの異なるバイナリとXMLのセキュリティ・トークンを、認証および認可の目的でWS-Securityヘッダーに挿入する方法を指定するプロファイルも含まれています。 WS-*仕様は、多くの場合、互いに依存しています。たとえば、WS-Policyは、WS-Securityとともに使用されます。WS-*仕様は、非WS-*仕様も利用します。たとえば、WS-Securityは、XML暗号化およびXML署名を使用します。 WS-Securityでは、SAMLアサーションのみ使用されます。プロトコルおよびバインディングは、WS-Securityフレームワークにより提供されます。 注: WS-Security、WS-Trust、WS-Policyは、Organization for the Advancement of Structured Information Standards (OASIS)またはWorld Wide Web Consortium (W3C)などの標準化団体に移管されています。 |
|
WS-Trust |
Web Services Trust Language (WS-Trust)は、WS-Securityの安全なメッセージング・メカニズムを使用して信頼関係を円滑化する仕様です。 WS-Trustは、アプリケーションが信頼されたSOAPメッセージの交換を構成できるようにするリクエスト・プロトコルおよびレスポンス・プロトコルを定義します。信頼は、セキュリティ・トークンの交換および仲介によって示されます。 WS-Securityのみを使用したメッセージ交換では、交換に関与する両当事者がセキュリティ情報の共有のために使用する必要があるセキュリティ・トークンのタイプについて事前に合意していることを前提としています。両当事者間にそうした合意がない場合でも、結果的に、メッセージを交換する前に信頼を確立する必要があります。SOAP/WS-Securityベースのメッセージを交換する両当事者間の信頼は、WS-Trust仕様を実装することにより確立されます。 |
|
WS-Policy |
Web Services Policy (WS-Policy)。WS-Securityとともに、WS-Policyは、Oracle Fusion Middlewareセキュリティのもう1つの主要な業界標準です。 WS-Policyは、WS-Securityとともに使用されます。Webサービス・プロバイダは、サービスが提供される条件(またはポリシー)を定義できます。WS-Policyフレームワークを使用すると、Oracle Web Services ManagerなどのWebサービス・アプリケーションによって処理されるポリシー情報の指定が可能になります。 ポリシーは、Webサービスの機能または要件を表す1つ以上のポリシー・アサーションとして表されます。たとえば、ポリシー・アサーションは、Webサービスへのリクエストを暗号化することを規定できます。同様に、ポリシー・アサーションでは、Webサービスで許容できる最大メッセージ・サイズを定義できます。 |
|
証明書 |
Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Security Token ServiceをホストするOAMサーバーは一意に識別されます。 |
|
キーストア |
Security Token Serviceのキーストアに含まれるものを次に示します。
|
|
ユーザー名トークン(UNT) |
リクエスタをそのユーザー名で識別し、オプションでパスワード(または共有シークレットあるいはパスワードに相当するもの)を使用してそのアイデンティティを認証します。ユーザー名トークンを使用する場合は、そのユーザーをデフォルトのユーザー・アイデンティティ・ストアで構成する必要があります。 |
|
X.509証明書 |
受信当事者に公開鍵を送信するために設計された署名付きデータ構造。証明書には、証明書ID、発行者の識別名(DN)、有効期間、所有者のDN、所有者の公開鍵などの標準フィールドが含まれています。 証明書は、Verisignなどの認証局(CA)によって発行されます。CAは、エンティティのアイデンティティを検証して証明書を付与し、CAの秘密鍵で署名します。CAは、公開鍵が含まれる独自の証明書を発行します。 各ネットワーク・エンティティには、信頼するCAの証明書のリストがあります。別のエンティティと通信する前に、指定されたエンティティはこのリストを使用して、別のエンティティの証明書の署名が信頼できるCAのものであることを検証します。 |
|
Security Assertion Markup Language (SAML) SAMLアサーション |
XMLドキュメントを使用してインターネット上でセキュリティ情報を共有するオープン・フレームワーク。SAMLにより提供されるものを次に示します。
WS-Securityでは、SAMLアサーションのみ使用されます。ただし、プロトコルおよびバインディングは、WS-Securityフレームワークにより提供されます。 SAMLアサーションには、次の3つのタイプの文が含まれます。
|
|
Kerberos |
クロス・プラットフォーム認証のシングル・サインオン・システム。Kerberosプロトコルを使用すると、共有の秘密鍵(対称鍵)に依存する2つのエンティティ間で相互認証を実行できます。Kerberos認証では、クライアント、サーバーの他、それらを仲介するための、鍵配布センター(KDC)と呼ばれる信頼された当事者が必要になります。その他必要なものを次に示します。
WS-SecurityのKerberos Token Profileを使用すると、ビジネス・パートナがサービス指向アーキテクチャ(SOA)でKerberosトークンを使用できるようになります。 |
11gリリースにおいて、Oracle Web Services Manager (WSM)のセキュリティと管理は、Oracle WSMエージェント機能とともにOracle WebLogic Serverに統合されています。表34-3では、WSMコンポーネントについて説明します。
表34-3 統合されたOracle Web Services Manager
| コンポーネント | 説明 |
|---|---|
|
Javaキーストア(JKS) |
クライアントのX.509トークンで必要な署名と暗号化鍵を格納するために必要です。JKSは、Sun Microsystemsにより定義された独自のキーストア・フォーマットです。信頼できる証明書と公開鍵および秘密鍵はキーストアに格納されます。鍵と証明書をJKSで作成し管理するには、keytoolユーティリティを使用します。鍵は、認証やデータ整合性などの様々な目的に使用されます。 クライアントとWebサーバーが、同じドメインにあり、同じキーストアにアクセス可能な場合は、同じ秘密/公開鍵のペアを共有できます。
|
|
ポリシー・インターセプタ |
Oracle Fusion Middleware 11gでは、Oracle WSMエージェントは、セキュリティおよび管理ポリシー・インターセプタによって管理されます。ポリシー・インターセプタは、信頼できるメッセージング、管理、アドレッシング、セキュリティおよびメッセージ転送最適化メカニズム(MTOM)を含むポリシーを施行します。Oracle WSMエージェントは、ポリシー・インターセプタ・パイプラインを使用してポリシーの施行を管理します。 リリース10gと11gの違いを含むOracle Web Services Managerの詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。 |
|
Oracle WSMエージェント |
OWSMエージェントは、Security Token Serviceとの通信に使用可能な、認定されたWS-Trustクライアントです。OWSMエージェントは、メッセージ保護のみのために(WSポリシーを公開するため、およびインバウンドおよびアウトバウンドのWSメッセージに対してメッセージ保護を施行するために)、Security Token Serviceにより埋め込まれ、使用されます。Security Token Serviceは、トークン検証/リクエスト認証を実行します。
注意: 埋込みは、セキュリティ・トークン・サービスが使用するWebLogic ServerのJRFレイヤーの一部としてOWSMエージェントが利用可能であることを意味します。 |
|
メッセージ/トークンの保護 |
Security Token Service/Access Managerは、それぞれのキーストアおよび信頼ストアを管理します。 Oracle WSMがSecurity Token Serviceのメッセージ保護を施行するために、OWSMのキーストアがその自己署名付き証明書でシードされ、それに対応する鍵のパスワードがCSFに格納されます。これは、Security Token Serviceキーストアを使用しません。 注意: 反対に、Oracle WSMは、Access Manager/Security Token Serviceがメッセージ保護に関連する鍵をOPSSキーストアに格納することを必要とします。クライアントがSKI、Thumbprintなどのスキームを使用してその証明書を参照する場合、Oracle WSMには、クライアント証明書がOPSSキーストアにあることが必要です。 |
|
トークン署名鍵 |
Security Token Serviceでは、トークン署名鍵に関して厳しい要件があり、クライアントとリライイング・パーティとの間の信頼を仲介するためにトークン署名鍵が使用されます。したがって、この鍵は、Security Token Serviceのみがアクセス可能な排他的パーティションに格納する必要があります。 |
|
セキュリティ・キー・ペア |
Security Token Serviceは、発行されたトークンのセキュリティおよびメッセージ・セキュリティのために別々の鍵ペアを作成することで、トークン署名鍵のセキュリティを提供し、Oracle WSMエージェントがAccess Manager/Security Token Serviceキーストアと連携する必要性を排除します。
|
|
OPSSキーストア |
メッセージ・セキュリティ・キー・ペアは、OPSSキーストアに移入されます。クライアントが(Webサービス・リクエストの一部として受信した証明書トークンではなく)SKIなどの参照スキームを使用する特別な場合、Security Token Serviceは、要求当事者の証明書をOPSSキーストアに移入します。これは一般的なシナリオではありません。Security Token Serviceには、OPSSキーストアに対して鍵を手動でプロビジョニングして機能させることについて、用意されている手順もあります。 |
セキュリティ・トークン・サービスは、WS-Trustプロトコルをサポートする一元化トークン・サービスです。また、セキュリティ・トークンの発行と交換、および信頼関係の構築のためのWS-Security仕様への拡張機能も定義します。セキュリティ・トークン・サービスは、Webサービス・エンドポイントとしてホストされ、WSCとWSPとの間におけるセキュリティに基づく相互作用を調整します。セキュリティ・トークン・サービスとの通信はすべて、図34-1に見られるように、WS_Trustクライアントを通して発生します。
WSCがWSPにコールすると、WSCは、セキュリティ・トークン・サービスにより発行されたセキュリティ・トークンの提示が必要であることを示すWS-Securityポリシーを取得します。ポリシーにはセキュリティ・トークン・サービスの場所が含まれ、WSCはその場所を使用して、セキュリティ・トークン・サービスに問い合せて、WSPが必要とするトークンを取得します。(また、WSPは、着信SOAPリクエストの検証前に、許容可能なセキュリティ・メカニズムをセキュリティ・トークン・サービスに登録しておき、セキュリティ・トークン・サービスに確認して、セキュリティ・メカニズムを決定できます)。認証されたWSC (エンド・ユーザーまたはアプリケーションのアイデンティティを確証する資格証明を保持)は、WSPにアクセスするためにトークンをリクエストし、Security Token Serviceは、資格証明を検証し、それに応えて、WSCが認証済である証拠を提供するセキュリティ・トークンを発行します。WSCはセキュリティ・トークンをWSPに提示し、WSPは信頼できるセキュリティ・トークン・サービスによってトークンが発行されたことを検証します。
図34-2は、セキュリティ・トークン・サービスに対するトークン・サポート・マトリックスを示しています。
この項では、次の異なるデプロイメント・オプションの概要を示します。
Web SSOとWebサービス・セキュリティ層との間におけるセキュリティ統合のためのトークン交換は、Webアプリケーションが内部または外部のWebサービスをコールする場合のデプロイメントにおいて需要があります。たとえば、内部ポータルをパートナまたは同一会社内の別組織により提供されている外部Webサービスと統合するような場合です。ポータルは、サービスに安全にアクセスする方法を必要としますが、この場合のセキュリティ統合の難しさは、Web SSO層とWS層がユーザー認証に異なるメソッドを使用するという事実に起因します。
Web SSO環境において、Webアプリケーションは、ユーザーを認証するために、WACにより発行されたセッション・トークン(SMSESSION、OBSSO)、SAMLアサーションまたは独自のトークンを受け入れることができます。WS*セキュリティ層はまた、様々な(標準および独自の)トークンを使用し、多くの場合、2つの層の間での統合を実現するために、トークンのローカル変換が必要となります。ほとんどの場合、変換を実行するWSは、トークンを分解するために、トークンを発行した認証局(Oracle Adaptive Access Manager)に問い合せる必要があり、その後にトークンを変換できます。分解においては、すべてのWSサービスがWACシステムの信頼を維持する必要があります。これは複雑であり、複数の信頼関係を維持することになるので、セキュリティも高くありません。図34-3に示すように、セキュリティ・トークン・サービスの導入により、一元化された認証局でトークンの変換を行うことが可能です。
アプリケーションがビジネス・ロジック用の特別な形式の資格証明に依存している状況は、Oracleアクセス製品のデプロイメントにおいてよく見られます。Oracleアプリケーションとカスタム・アプリケーション両方とのWACシステムの統合は、ほぼ必ず、次のことを行う拡張コードを必要とします。
独自のベンダーAPI (SMエージェントAPIまたはASDK)をコールすることにより、1つのトークン認証局(OAM、SiteMinderなど)によって発行されるトークンの分解。
内部ビジネス・ロジック用にアプリケーションが必要とする新しいトークン・フォーマット(PSFT、Siebel)の構成。
そうした変換は、アプリケーションのコーディングにより処理されることが多く、DMZにある複数のアプリケーション・インスタンス上でデプロイされた場合、ユーザー名やパスワードが公開されるリスクの要因となります。したがって、セキュリティ管理者には、変換プロセスをアプリケーションから離して外在させ、そのプロセスを管理する能力が必要です。セキュリティ・トークン・サービスの導入により、この状況は大幅に改善されます。図34-4に示すように、セキュリティ・トークン・サービスは一元化されたトークン認証局の役割を担い、ファイアウォールの背後でトークン変換を実行します。
アプリケーション1およびアプリケーション2は、Access Managerにより保護されています。アプリケーション2は、その内部ビジネス・ロジックのために別のタイプのトークンに依存しています。このアプリケーションには、OBSSOトークンをユーザー名トークンと交換するためにSecurity Token Serviceにコンタクトするクライアント側コネクタがあります。セキュリティ・トークン・サービスは、OBSSOトークンを分解するためにAccess Managerに依存しており、アプリケーション2が必要とする新しいトークンを生成します。ここでは同一の認証局(Access Manager)が両方の操作(OBSSOトークンの構成および分解)を実行するため、より安全です。アプリーション側でトークンを分解する必要はありません。
Web SSOと同様に、WebサービスSSOは便利な機能です。違いとしては、Web SSOの場合、この機能によってメリットのある側はユーザーであり、WS SSO環境では、セキュリティ管理者です。
WebサービスSSOでは、異なるWebサービスに異なるトークン要件があり、それが頻繁に変更されます。セキュリティ・トークン・サービスに交換を外在させると、アプリケーションが目的のトークンおよび現在保持しているトークンを単純に供給できるようになります。Security Token Serviceは、リクエストされた各サービスのトークン・タイプを決定することを引き受けます。1つ以上のWebサービスでその認証要件が変更されても、Security Token Serviceは、アプリケーションにより送信されたトークン・タイプをシームレスに検証できます。トークンがリクエストされたタイプではない場合は、古いトークンが取り消され、正しいタイプの新しいトークンが発行されます。図34-5に、WebサービスSSOを示します。
この項では、次のインストール・オプションの概要を示します。
このインストール・オプションは、単一のWebLogicドメイン内の複数の管理対象サーバーにデプロイされたセキュリティ・トークン・サービス・インスタンス間のクラスタリングを利用しています。このデプロイメント・トポロジでは、ロード・バランサにより高可用性機能が円滑化されます。デフォルトでは、Access ManagerとSecurity Token Serviceが同一の管理対象サーバーに共存します。ただし、Security Token Serviceはデフォルトで無効になっており、これを使用できるようにするには、手動で有効化する必要があります。このデプロイメント・トポロジは次のデプロイをサポートします。
スイート・インストーラを使用したセキュリティ・トークン・サービスの複数のインスタンスのデプロイ。
高可用性に加えてセキュリティ・トークン・サービス・クラスタのフロントでのフェイルオーバー・シナリオをサポートするロード・バランサのデプロイ。
詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
このインストール・オプションでは、リクエスタおよびリライイング・パーティとサード・パーティSTSサーバーとの間に相互運用性がもたらされます。実行時に、Security Token Serviceは、OPSS WS-Trustプロバイダを使用して、サード・パーティ・セキュリティ・トークン・サーバーのリクエスタおよびリライイング・パーティとの相互運用をサポートします。たとえば、サード・パーティ・セキュリティ・トークン・サービスが有効なSAMLアサーションを作成し、Security Token Serviceがそれを使用できます。
リクエスタとリライイング・パーティのためのすべての実行時シナリオは、WLSClient、MetroClientおよびOracle Web Services Manager (Oracle WSM)を含む、他のOracle WS-Trustクライアントによりサポートされています。WS-Trustバインディングを介した場合のみ、すべてのWebサービス・クライアントがSecurity Token Serviceでサポートされます。
Access Managerとセキュリティ・トークン・サービスは、単一のEARファイルから、WebLogicドメイン内の同じ管理対象サーバーにまとめてインストールされ、デプロイされます。Oracle WSMエージェントは、様々な暗号化操作のためにキーストアを使用します。それらのタスクのために、Oracle WSMエージェントは、Oracle WSMのタスク用に構成されたキーストアを使用します。インストール中、Oracle WSMキーストアが構成されていない場合にインストーラが行うことを次に示します。
$DOMAIN_HOME/config/fmwconfigフォルダに新しいキーストアを作成します(デフォルト名は、default-keystore.jks)
署名および暗号化の操作のためにOWSMにより使用されるキー・エントリを、対応する証明書付きで作成します。このキー・エントリは、OWSMキーストア内のorakey別名の下に格納されます
キー・エントリおよびキーストアのパスワードをCSFに格納します
キーストアへのアクセス権があると、次のことが必要になる場合があります。
必要に応じて、署名証明書または暗号化証明書を抽出してクライアントに配布します
署名または暗号化のキー・エントリを更新または置換します
信頼できる証明書を追加します
詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイドを参照してください。
Security Token Serviceをホストするサーバーは、Access Managerに登録する必要があります。これはインストール中に自動的に、またはインストール後に手動で行うことができます。
Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。Oracle Access Managementコンソールの要素を使用すると、管理者はセキュリティ・トークン・サービスを容易に構成してWS Trustトークンをパートナと交換できます。他のセキュリティ・トークン・サービス要素は、パートナ、エンドポイント、検証テンプレート、発行テンプレートおよびデータ・ストア接続の作成、表示、変更および削除のために用意されています。
セキュリティ・トークン・サービスの詳細は、第VIII部「Oracle Access Managementセキュリティ・トークン・サービスの管理」を参照してください。
初回のデプロイメント中に、Oracle Fusion Middleware構成ウィザードを使用して、管理者のユーザーIDおよびパスワードが設定されます。管理者は、Oracle Access Managementコンソール(およびWebLogic Server管理コンソール)にログインして使用できます。1つのLDAPグループ、WebLogic ServerのAdministratorsグループがデフォルトで設定されます。詳細は、第2章「Oracle Access Managementのスタート・ガイド」を参照してください。
