| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.1) B69533-05 |
|
 前 |
 次 |
このマニュアルでは、管理者がAccess Managerのコンポーネントやポリシーを1つ以上のWebLogic管理ドメイン内で管理する上で役立つ情報を提供しています。この章では、Oracle Access Managementの概要について説明し、関連情報へのリンクを示します。
この章には次の項が含まれます:
Oracle Access ManagementはJavaプラットフォームのEnterprise Edition (Java EE)に基づいた、エンタープライズ・レベルのセキュリティ・アプリケーションで、Web周辺のセキュリティ機能およびWebシングル・サインオン・サービスを全面的に提供します。これにはアイデンティティ・コンテキスト、認証および認可、ポリシー管理、テスト、ロギング、監査などが含まれます。
Oracle Access Managementは、セッション管理、アイデンティティ・コンテキスト、リスク分析、監査などの共有プラットフォーム・サービスを利用し、また、機密情報へのアクセスを制限します。図1-1に示すように、Oracle Identity Managementスタックの多くの既存アクセス技術は、Oracle Access Managementにまとめられています。
リリース11.1.2以降のOracle Access Managementには、次のサービスが含まれます。
Oracle Access Management Access Manager (Access Manager)。「Oracle Access Management Access Managerの概要」を参照してください。
Oracle Access Managementセキュリティ・トークン・サービス(セキュリティ・トークン・サービス): セキュリティ・ドメイン全体でのサービスへのアクセスや、組織の境界を越えたサービスへのアクセスを容易にする、トークンの検証および生成機能を提供します。サービスは、基本的に、クライアント要求を受信して検証し、要求対象リソースに適切なトークンを生成するトラスト・ブローカとして機能します。詳細は、「Oracle Access Management Security Token Serviceの概要」を参照してください。
Oracle Access Management Identity Federation (Identity Federation): オープンなフェデレーション・プロトコル標準(SAMLやOpenIDなど)を使用したドメイン間シングル・サインオンのサポートを提供します。リリース11.1.2より、Identity Federationはスタンドアロン製品ではなくなり、Oracle Access Managementに付属し、緊密に統合されています。この新しいOracle Access Managementではユーザー・インタフェースと管理の操作性が改良されています。詳細は、第VII部「Oracle Access ManagementのIdentity Federationの管理」を参照してください。
Oracle Access Management Mobile and Social (Mobile and Social): 保護されているリソースへのアクセスを必要とするユーザーと、リソースを保護するバックエンドのアイデンティティ管理サービスおよびアクセス管理サービスの間の新しい中間サービスです。Mobile and Socialは、モバイル・プラットフォームのセキュリティと準拠性を拡張し、FacebookやGoogleなどのソーシャル・アイデンティティ・サービスとの統合を簡単にします。Mobile and SocialのRESTfulはアイデンティティおよびアクセス管理のインフラストラクチャを使用可能にし、主要なモバイル・プラットフォームの専用開発者キットを含んでいます。管理者は、これによりセキュリティ・サービスに簡単にアクセス可能になり、ネイティブおよびモバイル・ブラウザベース・アプリケーションでのシングル・サインオンが可能になります。詳細は、第IX部「Oracle Access Management Mobile and Socialの管理」を参照してください。
アイデンティティ・コンテキスト: コンテキストを認識するセキュリティ・ポリシー管理を提供し、管理者は、Oracle Identity Managementが提供するセキュリティ・フレームワークを通じて、アプリケーション配信環境で付与されるセキュリティのレベルを制御できます。詳細は、第X部「アイデンティティ・コンテキストの使用」を参照してください。
OpenSSO 8.0およびSun Access Manager 7.1もOracle Access Management 11.1.2に統合されています。詳細は、次を参照してください:
Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイド
Oracle Fusion Middleware Supported System Configurationsのドキュメントには、サポートされているインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDK、Oracle Identity Management 11gに関連するサード・パーティ製品の動作保証の情報があります。Oracle Fusion Middleware Supported System Configurationsのドキュメントは、Oracle Technology Network (OTN) Webサイトで検索すれば見ることができます。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Oracle Fusion Middleware構成ウィザードを使用して、次のコンポーネントが新しいドメインにデプロイされます。
WebLogic管理サーバー
WebLogic管理サーバー(OAM管理サーバー、または単にAdminServerということもあります)上にデプロイされたOracle Access Managementコンソール
Oracle Access Managementの管理対象サーバー
管理対象サーバーにデプロイされたアプリケーション
|
関連項目:
|
OracleAS 10g SSOのデプロイメントは、Oracle Access Management 11g SSOを使用するようにアップグレードできます。OSSOエージェントをアップグレードして登録した後は、認証がAccess Manager 11g認証ポリシーに基づいて実行されます。ただし、OAMエージェント(Webgate/アクセス・クライアント)のみがAccess Manager 11g認可ポリシーを使用します。時間が経つにつれて、アップグレードされた環境にあるすべてのmod_ossoエージェントをWebgateと置換して11g認可ポリシーを使用できるようにする必要があります。
アップグレード後の共存の詳細は、Oracle Fusion Middleware Oracle Identity and Access Management更新、アップグレードおよび移行ガイドを参照してください。
各WebLogic Serverのドメインは、論理的に関連するOracle WebLogic Serverリソースのグループです。WebLogic管理ドメインには、Administration Serverという特殊なOracle WebLogic Serverインスタンスが含まれています。このドメインは通常、管理対象サーバーという追加のOracle WebLogic Serverインスタンスを含み、WebアプリケーションとWebサービスがここにデプロイされます。
初回のデプロイメント中、Oracle Access ManagementコンソールとWebLogic Server管理コンソールの両方にサインインするときに、WebLogic管理者のユーザーIDとパスワードが設定されます。「Oracle Access Management管理者の概要」で説明しているとおり、Oracle Access Managementに対して別の管理者を割り当てることができます。
管理者は、次のインストール後タスクのためにOracle Access Managementコンソールにログインして使用できます。
表1-1 Oracle Access Managementのインストール後のタスク
| サービス | 要件 |
|---|---|
|
Access Manager |
Access Managerサービスを有効化します。 次の項目を登録します。
次の項目を構成します。
Access Managerの設定を構成します。 |
|
アイデンティティ・フェデレーション |
Identity Federationサービスを有効化します。 フェデレーション設定を構成します。 アイデンティティ・プロバイダを登録します。 |
|
セキュリティ・トークン・サービス |
セキュリティ・トークン・サービスを有効化します。 セキュリティ・トークン・サービスの設定を構成します。 エンドポイントを登録します。 トークン発行および検証テンプレートを作成します。 パートナ・プロファイルとパートナを登録します。 |
|
Mobile and Social |
モバイルおよびソーシャル・サービスを有効化します。 モバイルおよびソーシャル・サービスを構成します。 モバイル・サービスを構成します。 インターネット・アイデンティティ・サービス |
このセクションでは、Oracle Access Management Access Managerの概要を説明します(以前は、Oracle Access Managerという名前のスタンドアロン製品でした)。
Access Managerシングル・サインオン(SSO)は、ユーザーやユーザーのグループが、認証後に複数のアプリケーションにアクセスできるようにします。SSOにより、サインオンを何度も要求されるということがなくなります。Access Managerは、Oracle Fusion Middleware 11gのシングル・サインオン・ソリューションを提供します。Access Managerは、このマニュアルの説明にあるように単独で動作し、また、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の説明にあるようにAccess Manager認証プロバイダとともに動作します。
Webサーバー、アプリケーション・サーバーまたは任意のサード・パーティ・アプリケーションは、Webgateにより、またはAccess Managerにエージェントとして登録されたmod_ossoインスタンスにより保護する必要があります。ポリシーを施行するために、エージェントはHTTPリクエストのフィルタとして機能します。Access Managerでは、管理者が認証および認可のポリシーを定義できます。
|
注意: Webgateは、様々なWebサーバーのためにOracleが製品の一部として提供するエージェントです。Access Manager SDKを使用して作成されたカスタムのアクセス・クライアントは、Web以外のアプリケーションで使用できます。明記されている場合を除いて、このマニュアルの情報はどちらにも同じように該当します。 |
Access Managerや現在Oracle ADF SecurityおよびOPSS SSOフレームワークを使用する任意のWebアプリケーションと統合することもできます。詳細については、付録Cを参照してください。
この項の残りの部分では、次のトピックを説明します。
|
関連項目: Access Manager 11gと10g、OSSO 10gとOpenSSOの間の相違点について: |
このトピックでは、Oracle WebLogicサーバー上に存在し、Oracle Fusion Middlewareアクセス管理アーキテクチャの一部であるAccess Manager 11gの概要を説明します。既存のソリューションとの下位互換性および共存が提供される一方で、Access Manager 11gでは次の旧テクノロジが置換および集約されます。
Access Manager 10g
Oracle Application Server SSO (OSSO) 10g
図1-2は、基本的なAccess Manager 11gのコンポーネントおよびサービスを示します。プロトコル互換性フレームワークは、OAM Webgate、mod_ossoエージェント、Access Managerソフトウェア開発キット(SDK)を使用して作成されたカスタムのアクセス・クライアントとインタフェースします。
図1-3は、Access Managerコンポーネントの分散を示します。
Oracle Access Managementコンソールは、Oracle WebLogic Administration Server (AdminServerとも呼ばれます)に備わっています。OAMランタイム・インスタンスをホストするWebLogic管理対象サーバーは、OAMサーバーとして知られています。共有情報は次の項目で構成されます。
エージェントおよびサーバー構成データ
Access Managerポリシー
セッション・データはすべてのOAMサーバーで共有されます。
表1-2は、エンタープライズ内のデプロイメントのタイプについて説明します。ただし、これらの名前は企業によって異なる可能性があります。
表1-2 デプロイメント・タイプ
| デプロイメント・タイプ | 説明 |
|---|---|
|
開発デプロイメント |
理想的にはサンドボックスタイプの設定で、開発全体への依存は最小限 |
|
QAデプロイメント |
通常、テスト用に使用される、比較的小さな共有されたデプロイ |
|
本番前デプロイメント |
通常、より幅広い対象者でのテストに使用される、共有されたデプロイメント |
|
日常的に企業内で完全に共有および使用可能 |
初回のインストールおよび構成のときに、新しいWebLogic Serverドメインを作成(または既存のドメインを拡張)して、OAMサーバー、データベース・スキーマ、オプションのWebLogic管理対象サーバー、クラスタ、埋込みLDAPを定義します。
|
関連項目: Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解ガイドの「Oracle WebLogic Serverドメインの理解」の章で、Oracle WebLogic Server管理ドメインについて説明しています。 |
WebLogic Serverドメイン: デプロイメントのサイズやタイプに関係なく、Oracle Fusion Middleware構成ウィザードを使用すると、新しいWebLogic Serverドメインに、次のコンポーネントがデプロイされます。
WebLogic管理サーバー
WebLogic管理サーバーにデプロイされたOracle Access Managementコンソール
Oracle Access ManagementサービスのWebLogic管理対象サーバー
管理対象サーバーにデプロイされたアプリケーション
|
注意: 既存のWebLogic Serverドメインでは、WebLogic管理サーバーはすでにインストールされて動作の準備ができています。 |
ポリシー・ストア: デフォルト・ポリシー・ストアは、デプロイメントや実証を目的としたファイル・ベースのものです。これは、本番環境ではサポートされません。本番環境では、すべてのポリシー操作と構成は、ポリシー・ストアとして構成されたデータベースに対して直接実行されます。
アイデンティティ・ストア: デフォルトの埋込みLDAPは、Access Managerの基本ユーザー・アイデンティティ・ストアとして設定されます。
キーストア: 認可時にOAMサーバーとWebgate間の簡易または証明書ベースの通信のための証明書として使用するために、Javaキーストアが設定されます。構成ウィザードを実行した後に、初回のAdminServer起動でキーストアのブートストラップも発生します。
この項では、次の概要を示します。
表1-3に、Access Manager 11.1.2の概要を示します。11.1.2で変更された名前のリストについては、「11.1.2で変更された製品およびコンポーネントの名前」を参照してください。
表1-3 概要: Access Manager 11.1.2
| Access Manager 11g | 説明 |
|---|---|
|
Oracle Identity Managementインフラストラクチャ |
エンタープライズ・アイデンティティのセキュアな集中管理を有効化します。 |
|
ポリシー施行エージェント |
依存するパーティとともに存在し、認証および認可タスクをOAMサーバーに委任します。
注意: 8つの管理者言語がサポートされています。 特に明記しないかぎり、「Webgate」という用語は新規のWebgateまたはカスタムのアクセス・クライアントの両方を指します。 エージェントの概要については、第13章を参照してください。 |
|
サーバー側のコンポーネント |
|
|
コンソール |
Oracle Access Managementコンソールを使用すると、すべてのサービスおよび構成の詳細にアクセスできます。 第2章を参照してください。 |
|
インターネットでの情報交換用プロトコル |
エージェントとサーバー間で交換されるフロント・チャネル・プロトコル: HTTP/HTTPS バック・チャンネル・プロトコル: 認証クライアントは、Oracle Accessプロトコル(OAP)の拡張機能を使用してセッションの処理を実行できます。 |
|
プロキシ |
レガシー・システムのサポートを提供します。
関連項目: 埋込みプロキシ・サーバーおよび下位互換性について |
|
暗号化キー |
注意: 登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成され、使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。
|
|
キー・ストレージ |
|
|
暗号化 / 復号化(暗号化されたデータを元の形式に変換するプロセス) |
クライアント側の暗号化を導入して、エージェントとサーバーの両側で暗号化が実行されるようにします。
|
|
ポリシー・ストア |
本番環境では、データベースです。実証環境および開発環境では、ファイル・ベースです。詳細は、「ポリシーおよびセッション・データベースの管理」を参照してください。 |
|
アプリケーション |
認証および認可をAccess Managerに委任して登録されたエージェントからヘッダーを受け入れるアプリケーション。 注意: 外部アプリケーションは認証が委任されません。かわりに、アプリケーション・ユーザー名とパスワードを求めるHTMLログイン・フォームが表示されます。たとえば、 Yahoo! Mailは、HTMLのログイン・フォームを使用する外部アプリケーションです。 |
|
SSOエンジン |
セッションのライフサイクルを管理し、有効なセッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。Access Manager 11gによって登録されたエージェントを使用します。
関連項目: 第16章 |
|
セッション管理 |
第15章を参照してください。 |
|
ポリシー |
登録済エージェントは、Access Manager認証、認可およびトークン発行ポリシーを使用して、保護されたアプリケーション(定義されたリソース)のアクセスを取得するユーザーを決定します。 関連項目: 第18章 |
|
クライアントIP |
|
|
レスポンス・トークンの再生防止 |
|
|
複数のネットワーク・ドメインのサポート |
Access Manager 11gは、ネットワーク間ドメインの設定不要なシングル・サインオンをサポートします。 この場合は、Oracle Federationを使用することをお薦めします。 |
|
Cookie |
ホストベースの認証Cookie
第16章を参照してください。 |
|
一元化されたログアウト |
第20章を参照してください。 |
Access Manager 10gでは、Access Manager 11gに含まれていない、いくつかの機能が提供されています。表1-4に概要を示します。
Security Token Serviceは、Access Managerとともにデプロイし、サービスとしてアクティブ化する必要があります。Security Token Serviceは、トークンの取得、更新および取消しのためのモデルにおいて、プロトコルやセキュリティ・インフラストラクチャに依存せず、その一貫性と効率性を促進するための基盤を現在のセキュリティ・インフラストラクチャに提供します。
|
関連項目:
|
Security Token Serviceは、Web Service (WS) Trustベースのトークン・サービスで、Webサービス間におけるポリシー主導の信頼の仲介ならびに安全なアイデンティティ伝播およびトークン交換を可能にします。Security Token Serviceは、企業およびそのサービス・プロバイダの内部において、分散WebサービスまたはフェデレーテッドWebサービスの統合を単純化するために必要なセキュリティおよびアイデンティティ・サービスとしてデプロイできます。
Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を委任します。
Security Token Serviceブローカは、Webサービス利用者(WSC)とWebサービス・プロバイダ(WSP)との間において信頼関係があり、セキュリティ・トークンのライフサイクル管理サービスを利用者とプロバイダに提供します。Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。Oracle Access Management Security Token ServiceはOracle Access Management Identity Federationを拡張します。これにより、SAML、WS-Federation、LibertyまたはOpenIDなどの各種フェデレーション・プロトコルを介して、異なるセキュリティ・ドメインにまたがる、または管理境界を越えたリソースにアクセスするためにWebブラウザ経由で訪れるユーザーに対して、フェデレーテッド・シングル・サインオン(SSO)およびシングル・ログアウト(SLO)が円滑化されます。
セキュリティ・トークンには、信頼をアサートするために使用される要求と文が含まれます。Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。こうした資格証明は、信頼しているOracle Access Managementセキュリティ・トークン・サービスから取得できます。相互運用可能なセキュリティ・トークンを入手するには、Webサービス・クライアントとWebサービスの両者がそのSecurity Token Serviceを信頼している必要があります。
今日のIT環境には数多くのタイプのセキュリティ・トークンがあり、そのほとんどがWebアプリケーションのSSOおよびアプリケーション・セッション管理を容易にするブラウザCookieを基にしています。その他のトークンには、Kerberos (主にWindowsネイティブ認証用)、Security Assertion Markup Language (SAML)アサーションに加えてデジタル証明書もあります。
詳細な情報は、次のトピックを参照してください:
表1-6は、Security Token Serviceの一般的な用語について説明しています。
表1-5 Security Token Serviceの用語と概要
| 用語 | 説明 |
|---|---|
|
セキュリティ・トークン |
メッセージの完全性と機密性を保護するために、信頼するセキュア・トークン・サービスにより発行されたトークンを使用してメッセージを保護するセキュリティ・メカニズム。発行されたトークンに含まれるキーは、サーバー用に暗号化され、署名用および暗号化用の新しいキーを導出するために使用されます。 サービス・プロバイダとコンシューマが潜在的に異なる管理対象環境にいる場合は、単一のセキュリティ・トークン・サービスを使用して信頼のチェーンを確立できます。サービスはクライアントを直接信頼するのではなく、指定されたセキュリティ・トークン・サービスにより発行されたトークンを信頼します。セキュリティ・トークン・サービスは第2のサービスの役割を担い、このサービスによりクライアントが安全に認証されることになります。 |
|
セキュリティ・トークン・サービス |
サーバーとの明示的な信頼関係(およびクライアントとの信頼関係)がある、信頼されたサード・パーティ。Security 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トークンを使用できるようになります。 |
表1-6 セキュリティ・トークン・サービスの用語
| 用語 | 説明 |
|---|---|
|
セキュリティ・トークン |
メッセージの完全性と機密性を保護するために、信頼するセキュア・トークン・サービスにより発行されたトークンを使用してメッセージを保護するセキュリティ・メカニズム。発行されたトークンに含まれるキーは、サーバー用に暗号化され、署名用および暗号化用の新しいキーを導出するために使用されます。 サービス・プロバイダとコンシューマが潜在的に異なる管理対象環境にいる場合は、単一のセキュリティ・トークン・サービスを使用して信頼のチェーンを確立できます。サービスはクライアントを直接信頼するのではなく、指定されたセキュリティ・トークン・サービスにより発行されたトークンを信頼します。セキュリティ・トークン・サービスは第2のサービスの役割を担い、このサービスによりクライアントが安全に認証されることになります。 |
|
セキュリティ・トークン・サービス |
サーバーとの明示的な信頼関係(およびクライアントとの信頼関係)がある、信頼されたサード・パーティ。Security 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トークンを使用できるようになります。 |
Security Token ServiceはAccess Managerに準拠し、Access Managerと共存します(トークンをリクエストするWebクライアントのプライマリ・オーセンティケータとしてAccess Managerを使用)。
Security Token Serviceは、Oracle Access Management 11gとともに管理対象サーバー上にインストールします。各管理対象サーバーは、通信チャネルをオープンするためにAccess Managerに登録する必要があります。Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。Security Token Serviceは、サード・パーティのセキュリティ・トークン・サービスと相互運用します。
Security Token Serviceでは、Oracle Web Services Managerエージェントが使用されます。Webgateは、アイデンティティ伝播用のエージェントとして使用されます。Webgateは、通信チャネルをオープンするためにAccess Manager 11gに登録する必要があります。
Security Token Serviceでは、共有サービスの共通インフラストラクチャおよびAccess Manager 11g管理モデルが利用されます。さらに、Security Token Serviceは、Oracle Access Managementコンソールと統合され、統一的で一貫性のある管理エクスペリエンスを提供します。
Security Token Serviceでは、診断、監視、監査および高可用性のためのフレームワーク、ガイドラインおよび手法について、Oracle Access Management 11gで使用されているものと同じものが採用されています。詳細は、第III部「共通のロギング、監査、パフォーマンス・モニタリングおよびチューニング」を参照してください。
Security Token Serviceは次の処理を実行します。
STS監査イベントを統合
Oracle Access ManagementコンソールおよびWLSTスクリプトにおいて、使用可能なSecurity Token Serviceメソッドを公開してパートナのデータを管理
Security Token Serviceのユースケースおよび構成モデルに固有の検証操作を実行
セキュリティ・トークン・サービス11gのインフラストラクチャは、表1-7で説明します。
表1-7 セキュリティ・トークン・サービス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以外では一般的ではない次の要件がサポートされます。
|
11gリリースにおいて、Oracle Web Services Manager (WSM)のセキュリティと管理は、Oracle WSMエージェント機能とともにOracle WebLogic Serverに統合されています。表1-8では、これらのコンポーネントについて説明します。
表1-8 統合されたOracle Web Services Manager
| コンポーネント | 説明 |
|---|---|
|
Javaキーストア(JKS) |
クライアントのX.509トークンで必要な署名と暗号化鍵を格納するために必要です。JKSは、Sun社により定義された独自のキーストア・フォーマットです。信頼できる証明書ならびに公開鍵および秘密鍵はキーストアに格納されます。鍵と証明書を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キーストアに対して鍵を手動でプロビジョニングして機能させることについて、用意されている手順もあります。 |
Oracle STSは、WS-Trustプロトコルをサポートする一元化されたトークン・サービスで、セキュリティ・トークンの発行および交換ならびに信頼関係の確立のために、WS-Security仕様に対する拡張機能を定義します。Oracle STSは、Webサービス・エンドポイントとしてホストされ、WSCとWSPとの間におけるセキュリティに基づく相互作用を調整します。Oracle STSとのすべての通信は、図1-4に示すように、WS_Trustクライアントを介して発生します。
WSCがWSPにコールすると、WSCは、Oracle STSにより発行されたセキュリティ・トークンの提示が必要であることを示すWS-Securityポリシーを取得します。ポリシーにはOracle STSの場所が含まれ、WSCは、その場所を使用してOracle STSにコンタクトし、WSPに要求されたトークンを取得します(あるいは、WSPが自ら許容できるセキュリティ・メカニズムをSecurity Token Serviceに登録し、着信SOAPリクエストの検証前に、Security Token Serviceに確認してそのセキュリティ・メカニズムを決定することもできます)。認証されたWSC (エンド・ユーザーまたはアプリケーションのアイデンティティを確証する資格証明を保持)は、WSPにアクセスするためにトークンをリクエストし、Security Token Serviceは、資格証明を検証し、それに応えて、WSCが認証済である証拠を提供するセキュリティ・トークンを発行します。WSCはセキュリティ・トークンをWSPに提示し、WSPは信頼できるセキュリティ・トークン・サービスによってトークンが発行されたことを検証します。
図1-5では、Oracle STSのトークン・サポート・マトリックスを示します。
この項では、次の異なるデプロイメント・オプションの概要を示します。
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システムを使用して信頼を維持する必要があります。これは複数の信頼リンクを維持することが必要になる複雑なもので、あまり安全ではありません。
図1-6に示すように、Security Token Serviceの導入により、一元化された認証局でトークンの変換を行うことが可能です。
アプリケーションがビジネス・ロジック用の特別な形式の資格証明に依存している状況は、Oracleアクセス製品のデプロイメントにおいてよく見られます。Oracleおよびカスタム・アプリケーションとのWACシステムの統合では、(1)独自のベンダーAPI (SMエージェントAPIやASDK)をコールすることによる、あるトークン認証局(OAMやSiteMinderなど)により発行されたトークンの分解、および(2)アプリケーションがその内部ビジネス・ロジックのために必要とする新しいトークン形式(PSFT、Siebel)の構成のために、ほぼ必ず広範なコーディングが必要となります。
そうした変換は、アプリケーションのコーディングにより処理されることが多く、そのコードがDMZにある複数のアプリケーション・インスタンス上でデプロイされた場合に、ユーザー名やパスワードがさらされるといったリスクの要因となります。
セキュリティ管理者には、変換プロセスをアプリケーションから離して外在させ、そのプロセスを管理する能力が必要です。Security Token Serviceの導入により、この状況は大幅に改善されます。図1-7に示すように、Security Token Serviceは一元化されたトークン認証局の役割を担い、ファイアウォールの背後でトークン変換を実行します。
アプリケーション1およびアプリケーション2は、Access Managerにより保護されています。アプリケーション2は、その内部ビジネス・ロジックのために別のタイプのトークンに依存しています。このアプリケーションには、OBSSOトークンをユーザー名トークンと交換するためにSecurity Token Serviceにコンタクトするクライアント側コネクタがあります。Security Token Serviceは、OBSSOトークンを分解するためにAccess Managerに依存しており、アプリケーション2が必要とする新しいトークンを生成します。
ここでは同一の認証局(Access Manager)が両方の操作(OBSSOトークンの構成および分解)を実行するため、より安全です。アプリケーション側でトークンを分解する必要はありません。
Web SSOと同様に、WebサービスSSOは便利な機能です。その違いは、Web SSOでは、その機能から恩恵を受ける当事者はユーザーであるという点です。WS環境では、次のようになります。
Web SSO: ユーザーが恩恵を受けます。
WebサービスSSO: セキュリティ管理者が恩恵を受けます。
WebサービスSSOでは、異なるWebサービスに異なるトークン要件があり、それが頻繁に変更されます。Security Token Serviceに交換を外在させると、アプリケーションが目的のトークンおよび現在保持しているトークンを単純に供給できるようになります。Security Token Serviceは、リクエストされた各サービスのトークン・タイプを決定することを引き受けます。
1つ以上のWebサービスでその認証要件が変更されても、Security Token Serviceは、アプリケーションにより送信されたトークン・タイプをシームレスに検証できます。トークンがリクエストされたタイプではない場合は、古いトークンが取り消され、正しいタイプの新しいトークンが発行されます。
図1-8に、WebサービスSSOを示します。
この項では、次のインストール・オプションの概要を示します。
単一のWebLogicドメイン内にある様々な管理対象サーバーでデプロイされたSecurity Token Serviceインスタンスの間でクラスタリングを利用できます。このデプロイメント・トポロジでは、ロード・バランサにより高可用性機能が円滑化されます。デフォルトでは、Access ManagerとSecurity Token Serviceが同一の管理対象サーバーに共存します。ただし、Security Token Serviceはデフォルトで無効になっており、これを使用できるようにするには、手動で有効化する必要があります。
このデプロイメント・トポロジでは、次に示すことを行うことになります。
スイート・インストーラを使用して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とSecurity Token Serviceは、1つのEARファイルから一緒にインストールされます。Access ManagerとSecurity Token Serviceは、1つの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に登録する必要があります。これはインストール中に自動的に、またはインストール後に手動で行うことができます。
Oracle Access Managementコンソールの要素を使用すると、管理者はトークン・サービスを容易に構成してWS Trustトークンをパートナと交換できます。トークン・サービスの要素は、パートナ、エンドポイント、検証テンプレート、発行テンプレートおよびデータ・ストア接続の作成、表示、変更および削除のために用意されています。
Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。これにはこれまでに扱った次のトピックが含まれます。
情報はマニュアル全体から探すようにしてください。Security Token Serviceサービスの詳細は第VIII部「Oracle Access Management Security Token Serviceの管理」を参照してください。
1つのLDAPグループ、WebLogic ServerのAdministratorsグループがデフォルトで設定されます。
初回のデプロイメント中に、Oracle Fusion Middleware構成ウィザードを使用して、管理者のユーザーIDおよびパスワードが設定されます。管理者は、Oracle Access Managementコンソール(およびWebLogic Server管理コンソール)にログインして使用できます。
詳細は、第2章「Oracle Access Management管理およびナビゲーション・スタート・ガイド」を参照してください。
ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、Oracle Technology Network (OTN)で、システム要件と動作保証情報のドキュメントを参照してください。
システム要件に関するドキュメントには、ハードウェア要件およびソフトウェア要件、ディスク領域とメモリーの最小要件、必要なシステム・ライブラリ、パッケージ、パッチなどの情報が記載されています。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-requirements-100147.html
動作要件に関するドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品が記載されています。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
