| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
前 |
次 |
この章では、Oracle Access Manager 11gおよびOracle Security Token Serviceの高度な概要ならびに詳細情報へのリンクを提供します。この章には次の項が含まれます。
Oracle Access Manager 11gは、全面的なWeb周辺のセキュリティ機能を提供します。これにはWebシングル・サインオン、認証および認可、ポリシー管理、監査などが含まれます。
シングル・サインオン(SSO)は、ユーザーやユーザーのグループが、認証後に複数のアプリケーションにアクセスできるようにします。SSOにより、サインオンを何度も要求されるということがなくなります。Oracle Access Manager 11gは、Oracle Fusion Middleware 11gのシングル・サインオン・ソリューションです。Oracle Access Manager 11gは、このマニュアルの説明にあるように単独で動作する他、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の説明にあるようにOracle Access Manager認証プロバイダとともに動作します。
Oracle Access Manager 11gはJavaプラットフォームのEnterprise Edition(Java EE)に基づいた、エンタープライズ・レベルのセキュリティ・アプリケーションで、機密情報へのアクセスを制限したり、認証や認可のサービスを一元化します。Oracle Identity Managementスタックのすべての既存のアクセス・テクノロジは、Oracle Access Manager 11gに集約されています。
Webサーバー、アプリケーション・サーバーまたは任意のサード・パーティ・アプリケーションは、Webgateにより、またはOracle Access Managerにエージェントとして登録されたmod_ossoインスタンスにより保護する必要があります。ポリシーを施行するために、エージェントはHTTPリクエストのフィルタとして機能します。Oracle Access Managerでは、管理者が認証および認可のポリシーを定義できます。
|
注意: Webgateは、様々なWebサーバーのためにOracleが製品の一部として提供するエージェントです。Access Manager SDKを使用して作成されたカスタムのアクセス・クライアントは、Web以外のアプリケーションで使用できます。明記されている場合を除いて、このマニュアルの情報はどちらにも同じように該当します。 |
OAM 11gや現在Oracle ADF SecurityおよびOPSS SSOフレームワークを使用する任意のWebアプリケーションと統合することもできます。詳細は、付録Cを参照してください。
この項の残りの部分では、次のトピックを説明します。
「Oracle Access Manager 11g、10g、OracleAS SSO 10gの比較」で説明しているように、Oracle Access Manager 11g、Oracle Access Manager 10gおよびOSSO 10gの間にはいくつかの重要な違いがあります。
このトピックでは、Oracle WebLogicサーバー上に存在し、Oracle Fusion Middlewareアクセス管理アーキテクチャの一部であるOracle Access Manager 11gの概要を説明します。
既存のソリューションとの下位互換性および共存が提供される一方で、Oracle Access Manager 11gでは次の旧テクノロジが置換および集約されます。
Oracle Access Manager 10g
Oracle Application Server SSO(OSSO)10g
図1-1に、基本的なOracle Access Manager 11gのコンポーネントおよびサービスを示します。プロトコル互換性フレームワークは、OAM Webgate、mod_ossoエージェント、Access Managerソフトウェア開発キット(SDK)を使用して作成されたカスタムのアクセス・クライアントとインタフェースします。
図1-2は、Oracle Access Managerコンポーネントの分散を示します。
Oracle Access Managerコンソールは、Oracle WebLogic Administration Server (AdminServerとも呼ばれます)に備わっています。OAMランタイム・インスタンスをホストするWebLogic管理対象サーバーは、OAMサーバーとして知られています。
共有情報は次の項目で構成されます。
エージェントおよびサーバー構成データ
Oracle Access Managerポリシー
ユーザー・セッション・データはすべてのOAMサーバーで共有されます。
この項では、OAMのデプロイメントおよびインストールの簡単な概要を説明します。
表1-1では、企業内のデプロイメントのタイプについて説明しますが、これらの名前は企業によって異なる可能性があります。
表1-1 デプロイメント・タイプ
| デプロイメント・タイプ | 説明 |
|---|---|
|
開発デプロイメント |
理想的にはサンドボックスタイプの設定で、開発全体への依存は最小限 |
|
QAデプロイメント |
通常、テスト用に使用される、比較的小さな共有されたデプロイ |
|
本番前デプロイメント |
通常、より幅広い対象者でのテストに使用される、共有されたデプロイメント |
|
日常的に企業内で完全に共有および使用可能 |
初回のインストールおよび構成のときに、新しいWebLogic Serverドメインを作成(または既存のドメインを拡張)して、OAMサーバー、データベース・スキーマ、オプションのWebLogic管理対象サーバー、クラスタ、埋込みLDAPサーバーを定義します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』ガイドの「Oracle WebLogic Serverドメインの理解」の章で、Oracle WebLogic Server管理ドメインについて説明しています。 |
デプロイメントのサイズやタイプに関係なく、新しいWebLogic Serverドメインでは、Oracle Fusion Middleware構成ウィザードを使用して、次のOAM関連コンポーネントがデプロイされます。
WebLogic管理サーバー
WebLogic管理サーバーにデプロイされたOracle Access Managerコンソール
Oracle Access ManagementのWebLogic管理対象サーバー
管理対象サーバーにデプロイされたアプリケーション
|
注意: 既存のWebLogic Serverドメインでは、WebLogic管理サーバーはすでにインストールされて動作の準備ができています。 |
Oracle Fusion Middleware構成ウィザードを使用する際、アプリケーション・ドメインのメタデータを設定するためにDBを使用した構成テンプレートが選択されました。Repository Creation Utility(RCU)を使用して、OAM固有のスキーマによりデータベースを拡張する必要があります。構成ウィザードを実行した後に、初回のAdminServer起動でポリシー・ストアのブートストラップが発生します。詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
デフォルトの埋込みLDAPは、OAM 11gの基本ユーザー・アイデンティティ・ストアとして設定されます。
認可時にOAMサーバーとWebgate間の簡易または証明書ベースの通信のための証明書として使用するために、Javaキーストアが設定されます。構成ウィザードを実行した後に、初回のAdminServer起動でキーストアのブートストラップも発生します。
初回のデプロイメント中、Oracle Access ManagerコンソールとWebLogic Server管理コンソールの両方にサインインするときに、WebLogic管理者のユーザーとパスワードが設定されます。「管理者について」で説明しているとおり、Oracle Access Management (Oracle Access ManagerおよびOracle Security Token Service)に対して別の管理者を割り当てることができます。
Oracle Access Management管理者は、Oracle Access Managerコンソールにログインしてこれを使用し、次に示す内容を管理できます。
ユーザー・アイデンティティ・ストア
OAMサーバー登録
パートナ(エージェントおよびパートナ・アプリケーション)登録
リソースを保護するためのアプリケーション・ドメインおよびポリシー
ユーザー・セッション
共通サーバー・プロパティ
「Oracle Security Token Serviceの概要」で紹介しているOracle Security Token Serviceの設定および構成
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
インストールの後、新しいWebLogic Serverドメインまたは既存のWebLogic ServerドメインでOracle Access Managerを構成できます。Oracle Fusion Middleware構成ウィザードを使用して、次のコンポーネントが新しいドメインにデプロイされます。
WebLogic管理サーバー
WebLogic管理サーバー(OAM管理サーバー、または単にAdminServerということもあります)上にデプロイされたOracle Access Managerコンソール
Oracle Access Managerの管理対象サーバー
管理対象サーバーにデプロイされたアプリケーション
|
関連項目:
|
OracleAS 10g SSOのデプロイメントは、Oracle Access Manager 11g SSOを使用するようにアップグレードできます。OAM 11gでOSSOエージェントをアップグレードしてプロビジョニングした後は、認証はOAM 11g認証ポリシーに基づきます。ただし、OAMエージェント(Webgate/アクセス・クライアント)のみがOAM 11g認可ポリシーを使用します。時間が経つにつれて、アップグレードされた環境にあるすべてのmod_ossoエージェントをWebgateと置換してOAM 11g認可ポリシーを使用できるようにする必要があります。
アップグレード後の共存の詳細は、次を参照してください。
『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』
『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』(B56245-01)
ここでは、次の内容について説明します。
Oracle Access Manager 11gには、Oracle Access Manager 10gにはなかった重要な機能拡張がいくつか含まれています。機能拡張の一覧は、表1-2にあります。
表1-2 Oracle Access Manager 11gの機能拡張
| Oracle Access Manager 11gの新機能 |
|---|
|
|
OracleAS 10g SSOパートナ・アプリケーション、OSSO 10gで保護されたアプリケーションおよびOAM 10g Webgateで保護されたアプリケーションに対するシングル・サインオンの組込みサポート。第IV部を参照してください。 エージェントごとの共有秘密鍵は、Cookieの暗号化と説明をエージェントに移すことにより、セキュリティとパフォーマンスを向上させます。第9章および第11章を参照してください。 |
|
ユーザーおよびグループ情報の埋込みLDAPについては、第5章で説明しています。 ポリシーのデータベース・ストレージを可能にするOracle Entitlement Server MicroSMとの統合。第5章を参照してください。 |
|
|
OAM 10g Access Testerは新しいOAM 11g Access Testerに置き換えられ、Oracle Access Managerポリシーの評価が簡単になりました。第14章を参照してください。 |
|
セッション管理機能については、第7章で説明しています。
|
|
第24章で説明しているように、イベントは、基礎となるOracle Fusion Middleware共通監査フレームワークを使用して監査できます。 |
|
Windowsのネイティブ認証は、OSSOエージェントまたはOAMエージェントにより保護されたアプリケーションでサポートされています。詳細は、Oracle Fusion Middleware統合ガイド for Oracle Access Managerを参照してください。 |
|
カスタム認証プラグインの作成に必要な拡張性フレームワーク。詳細は、『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』を参照してください。 |
|
複雑なポリシー構成(複数のルールのAND、ORセマンティク) |
|
偽装のサポート |
Oracle Access Manager 10gには、Oracle Access Manager 11gに含まれていない機能がいくつかあります。表1-3に概要を示します。
この項では、Oracle Access ManagerおよびOSSOの10gアーキテクチャとの比較について説明します。次のトピックが含まれます。
Oracle Access Manager 11gは、アイデンティティ管理機能がOracle Identity Manager 11g(ユーザー・セルフサービス、セルフ登録、ワークフロー機能、動的グループ管理、委任されたアイデンティティ管理を含む)に移管されたという点で、Oracle Access Manager 10gとは異なります。
Oracle Access Manager 10gは、認証レベルが同じかより低いターゲット・リソースへのアクセスに必要なユーザー・アイデンティティおよびユーザー・セッションの情報を含む単一のセッションcookie(ObSSOCookie)を使用して、シングル・サインオンをサポートしていました。ObSSOCookieは、グローバル共有の秘密鍵を使用して暗号化、復号化され、秘密鍵の値はディレクトリ・サーバーに格納されていました。ObSSOCookieは、ユーザー・アイデンティティを検証して保護されたリソースへのアクセスを許可または却下するために、アクセス・システム・コンポーネントによって消費されていました。
あらゆるセキュリティ・ギャップを埋めるために、Oracle Access Manager 11gでは、既存のOracle Access Manager 10gポリシー施行エージェント(Webgate)およびOSSO 10gエージェント(mod_osso)との下位互換性を維持するサーバー側コンポーネントが新たに提供されます。新しいOracle Access Manager 11g Webgateは10g Webgateの強化バージョンで、シングル・サインオン(SSO)・ソリューションのためにエージェントごとの秘密鍵をサポートしています。したがって、Cookieリプレイ型の攻撃が阻止されます。11g Webgateは、すべて同じレベルで信頼されます。つまり、Webgate固有のCookieが設定され、それを使用しても、他のWebgateで保護されたアプリケーションにユーザーの代理でアクセスすることはできません。
特に明記しないかぎり、「Webgate」という用語は新規のWebgateまたはカスタムのアクセス・クライアントの両方を指します。
Oracle Access Manager 11gでは、Oracle Coherenceの技術を使用して、分散されて集中化された信頼のできるセッション管理が可能です。
表1-4では、Oracle Access Manager 11g、OAM 10g、OracleAS SSO 10gの比較を示します。Oracle Access Manager 11gでの名称変更のリストについては、「製品とコンポーネントの名称変更」を参照してください。
表1-4 比較: OAM 11g、OAM 10g、OSSO 10g
| OAM 11g | OAM 10g | OSSO 10g | |
|---|---|---|---|
|
アーキテクチャ・コンポーネント |
注意: 8つの管理者言語がサポートされています。 |
注意: 8つの管理者言語がサポートされています。 |
|
|
Cookie |
ホストベースの認証Cookie
|
|
|
|
暗号化キー インターネット上での情報交換の保護に使用されるプロトコル。 |
|
すべてのWebgateに1つのグローバル共有秘密鍵 |
|
|
キー・ストレージ |
|
ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(Webgateに対してはアクセス不可) |
|
|
暗号化 / 復号化(暗号化されたデータを元の形式に変換するプロセス) |
クライアント側の暗号化を導入して、エージェントとサーバーの両側で暗号化が実行されるようにします。
|
|
暗号化はmod_ossoおよびOSSOサーバーの両方で実行されます。
|
|
セッション管理 |
|
|
|
|
クライアントIP |
|
|
|
|
レスポンス・トークンの再生防止 |
|
なし |
|
|
一元化されたログアウト |
詳細は、第15章を参照してください。 |
|
OSSOサーバーのcookieには、パートナIDのリストが含まれます。 ユーザーがあるパートナ・アプリケーションからログオフすると、次の処理が行われます。
|
Oracle Security Token Serviceは、Oracle Access Managerとともにデプロイし、サービスとしてアクティブ化する必要があります。
|
関連項目:
|
Oracle Security Token Serviceは、トークンの取得、更新および取消のためのモデルにおいて、プロトコルやセキュリティ・インフラストラクチャに依存せず、その一貫性と効率性を促進するための基盤を現在のセキュリティ・インフラストラクチャに提供します。
Oracle Security Token Serviceは、Web Service (WS) Trustベースのトークン・サービスで、Webサービス間におけるポリシー主導の信頼の仲介ならびに安全なアイデンティティ伝播およびトークン交換を可能にします。Oracle Security Token Serviceは、企業およびそのサービス・プロバイダの内部において、分散WebサービスまたはフェデレーテッドWebサービスの統合を単純化するために必要なセキュリティおよびアイデンティティ・サービスとしてデプロイできます。
Oracle Security Token Serviceは、主にOASIS WS-Trustプロトコルを基盤とします。ただし、Oracle Security Token Serviceは、SOAPメッセージに含まれるその他のWS-*プロトコルの処理を委任します。
Oracle Security Token Serviceは、Webサービス・コンシューマ(WSC)とWebサービス・プロバイダ(WSP)との間での信頼を仲介し、プロバイダとコンシューマに対してセキュリティ・トークンのライフサイクル管理サービスを提供します。Oracle Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。
Oracle Security Token Service (Oracle STS)はOracle Identity Federation (OIF)を拡張します。これにより、SAML、WS-Federation、LibertyまたはOpenIDなどの各種フェデレーション・プロトコルを介して、異なるセキュリティ・ドメインにまたがる、または管理境界を越えたリソースにアクセスするためにWebブラウザ経由で訪れるユーザーに対して、フェデレーテッド・シングル・サインオン(SSO)およびシングル・ログアウト(SLO)が円滑化されます。
セキュリティ・トークンには、信頼をアサートするために使用される要求と文が含まれます。Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。こうした資格証明は、信頼しているセキュリティ・トークン・サービス(STS)から取得できます。相互運用可能なセキュリティ・トークンを入手するには、Webサービス・クライアントとWebサービスの両者がそのSTSを信頼している必要があります。
今日のIT環境には数多くのタイプのセキュリティ・トークンがあり、そのほとんどがWebアプリケーションのSSOおよびアプリケーション・セッション管理を容易にするブラウザCookieを基にしています。その他のトークンには、Kerberos (主にWindowsネイティブ認証用)、Security Assertion Markup Language (SAML)アサーションに加えてデジタル証明書もあります。
詳細は、次のトピックを参照してください。
表1-5 Oracle Security Token Serviceの一般的な用語の識別
表1-5 Oracle Security Token Serviceの用語
| 用語 | 説明 |
|---|---|
|
セキュリティ・トークン |
メッセージの完全性と機密性を保護するために、信頼するセキュア・トークン・サービスにより発行されたトークンを使用してメッセージを保護するセキュリティ・メカニズム。発行されたトークンに含まれるキーは、サーバー用に暗号化され、署名用および暗号化用の新しいキーを導出するために使用されます。 サービス・プロバイダとコンシューマが潜在的に異なる管理対象環境にいる場合は、単一のセキュリティ・トークン・サービスを使用して信頼のチェーンを確立できます。サービスはクライアントを直接信頼するのではなく、指定されたセキュリティ・トークン・サービスにより発行されたトークンを信頼します。セキュリティ・トークン・サービスは第2のサービスの役割を担い、このサービスによりクライアントが安全に認証されることになります。 |
|
セキュリティ・トークン・サービス |
サーバーとの明示的な信頼関係(およびクライアントとの信頼関係)がある、信頼されたサード・パーティ。Oracle Security Token Serviceはその一例です。 |
|
セキュア・トークン・サービス |
様々なアイデンティティ・ドメインとインフラストラクチャ層との間における信頼の仲介に関して標準ベースの統合されたメカニズムを提供する共有Webサービス。 このサービスは、それ自体が信頼する証拠に基づいてアサーションを作成することにより、そのサービスを信頼する他者(または特定の受信者)に対して、WS-Trust仕様で定義されたプロトコルを実装します。このプロトコルは、セキュリティ・トークンの発行、更新、取消および検証のために、メッセージ書式およびメッセージ交換パターンを定義します。 信頼を伝達するために、サービスは、セキュリティ・トークンまたはセキュリティ・トークンのセットに関する知識を証明するものを必要とします。たとえば、XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは送信者の秘密鍵を使用して署名され、その署名は送信者の公開鍵を使用して検証されます。 |
|
リクエスト・セキュリティ・トークン(RST) |
セキュリティ・トークンのリクエスト。 |
|
リクエスト・セキュリティ・トークン・レスポンス(RSTR) |
セキュリティ・トークンのリクエストへのレスポンスとして、リクエストしたユーザーの要求を使用して、Oracle Security Token Serviceにより生成されたレスポンス。 |
|
代理(OBO) |
OBOリクエスト・セキュリティ・トークン(RST)は、本来のクライアントのアイデンティティのみが重要な場合に使用されます。OBO RSTは、リクエスタが必要としているトークンに、次の1つのエンティティのみに関する要求が含まれているをことを示します。
|
|
ActAs |
ActAs RSTは、複合的な委任を必要とします。発行されたトークンの最終受信者が、(クライアントのみでなく)委任チェーン全体を検査できます。ActAs RSTは、リクエスタが必要としているトークンに、次の異なるエンティティに関する要求が含まれているをことを示します。
|
|
トークン交換 |
あるセキュリティ・トークンと別のセキュリティ・トークンの交換。リクエスタは、(Webサービスを開始するために)特定のトークンを必要とします。リクエスタは、Oracle 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サービスで許容できる最大メッセージ・サイズを定義できます。 |
|
証明書 |
Oracle Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Oracle Security Token ServiceをホストするOAMサーバーは一意に識別されます。 |
|
キーストア |
Oracle 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トークンを使用できるようになります。 |
Oracle Security Token ServiceはOracle Access Managerに準拠し、Oracle Access Managerと共存します(トークンをリクエストするWebクライアントのプライマリ・オーセンティケータとしてOracle Access Managerを使用)。
Oracle Security Token Serviceは、Oracle Access Manager 11gとともに管理対象サーバー上にインストールします。各管理対象サーバーは、通信チャネルをオープンするためにOracle Access Managerに登録する必要があります。Oracle Security Token Serviceシステムのすべての構成は、Oracle Access Managerコンソールを使用して実行します。Oracle Security Token Serviceは、サード・パーティのセキュリティ・トークン・サービスと相互運用します。
Oracle Security Token Serviceでは、Oracle Web Services Managerエージェントが使用されます。Webgateは、アイデンティティ伝播用のエージェントとして使用されます。Webgateは、通信チャネルをオープンするためにOracle Access Manager 11gに登録する必要があります。
Oracle Security Token Serviceでは、共有サービスの共通インフラストラクチャおよびOracle Access Manager 11g管理モデルが利用されます。さらに、Oracle Security Token Serviceは、Oracle Access Managerコンソールと統合され、統一的で一貫性のある管理エクスペリエンスを提供します。
Oracle Security Token Serviceでは、診断、監視、監査および高可用性のためのフレームワーク、ガイドラインおよび手法について、Oracle Access Manager 11gで使用されているものと同じものが採用されています。詳細は、第VI部「共通のロギング、監査、パフォーマンス・モニタリング」を参照してください。
Oracle Security Token Serviceの処理。
STS監査イベントを統合
Oracle Access ManagerコンソールおよびWLSTスクリプトにおいて、使用可能なOracle Security Token Serviceメソッドを公開してパートナのデータを管理
Oracle Security Token Serviceのユースケースおよび構成モデルに固有の検証操作を実行
Oracle Security Token Service 11gのインフラストラクチャは、表1-6で説明します。
表1-6 Oracle Security Token Service 11gのインフラストラクチャ
| コンポーネント | 説明 |
|---|---|
|
デフォルト信頼キーストア |
署名/暗号化に使用されるOracle Security Token Serviceの秘密鍵は、Oracle Access Managerで使用される共通キーストアに格納されます。Oracle Security Token ServiceおよびOracle Access Managerでは、共通インフラストラクチャ証明書検証モジュールが使用されます。証明書の検証中に使用される信頼できる証明書および証明書失効リスト(CRL)は、信頼キーストアおよびCRLのZIPファイルに格納されます。Oracle Security Token Serviceの構成には、OCSP/CDPの設定が格納されます。 トークン・セキュリティ・キー・ペアは、Oracle Access Manager/Oracle Security Token Serviceキーストアに移入されます。 注意: OSTSのデプロイメントにおいてOracle WSMエージェントをWS_Trustクライアントとして使用する場合は、Oracle WSMエージェントのキーストアとOSTS/OAMのキーストアを別にすることをお薦めします。この2つをマージしないでください。その他の場合は、キーストアへのアクセスをOPSSにより認可されたすべてのモジュールに対してOAM/OSTSの鍵を使用可能なため、OAMの鍵にアクセスできます。 |
|
デフォルトのユーザー・アイデンティティ・ストア |
Oracle Security Token Serviceは、Oracle Access Managerコンソールの「システム構成」の「共通構成」セクションで構成されたユーザー・アイデンティティ・ストアに対してユーザーを認証およびマッピングします。Oracle Security Token Serviceは、着信トークンをデフォルト・ユーザー・アイデンティティ・ストアのユーザー・レコードおよびユーザー属性にマッピングし、これがOracle Access ManagerとOracle Security Token Serviceの両方と連動します。 |
|
証明書 |
Oracle Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Oracle Security Token ServiceをホストするOAMサーバーは一意に識別されます。
これにより、暗号化のデータおよび識別子に関して、2つのサーバーが同一ではないことが確認されます。サード・パーティ・モジュールにより一方のサーバーに付与された信頼は、識別子と暗号キーが異なるため、他方のサーバーには付与されません。同一の鍵、同一の識別子がない場合、認可ポリシーは拒否モードです。 |
|
Oracle Coherence |
Oracle Security Token Serviceは、Oracle Coherenceモジュールと統合され、Oracle Security Token Serviceのすべての物理インスタンス間でWS-Trustのランタイム・データが格納および共有されます。UserNameToken Nonceは、Coherenceストアに格納されます。この実装では、Oracle Security Token Service以外では一般的ではない次の要件がサポートされます。
|
11gリリースにおいて、Oracle Web Services Manager (WSM)のセキュリティと管理は、Oracle WSMエージェント機能とともにOracle WebLogic Serverに統合されています。表1-7では、これらのコンポーネントについて説明します。
表1-7 統合された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エージェントは、OSTSとの通信に使用可能な、認定されたWS-Trustクライアントです。OWSMエージェントは、メッセージ保護のみのために(WSポリシーを公開するため、およびインバウンドおよびアウトバウンドのWSメッセージに対してメッセージ保護を施行するために)、Oracle Security Token Serviceにより埋め込まれ、使用されます。Oracle Security Token Serviceは、トークン検証/リクエスト認証を実行します。
注意: 埋込みとは、OSTSが使用するWebLogic Server上でJRFレイヤーの一部としてOWSMエージェントが使用可能であることを意味します。 |
|
メッセージ/トークンの保護 |
Oracle Security Token Service/Oracle Access Managerは、それぞれのキーストアおよび信頼ストアを管理します。 Oracle WSMがOracle Security Token Serviceのメッセージ保護を施行するために、OWSMのキーストアがその自己署名付き証明書でシードされ、それに対応する鍵のパスワードがCSFに格納されます。これはOSTSキーストアと連携しません。 注意: 反対に、Oracle WSMは、Oracle Access Manager/Oracle Security Token Serviceがメッセージ保護に関連する鍵をOPSSキーストアに格納することを必要とします。クライアントがSKI、Thumbprintなどのスキームを使用してその証明書を参照する場合、Oracle WSMには、クライアント証明書がOPSSキーストアにあることが必要です。 |
|
トークン署名鍵 |
Oracle Security Token Serviceでは、トークン署名鍵に関して厳しい要件があり、クライアントとリライイング・パーティとの間の信頼を仲介するためにトークン署名鍵が使用されます。したがって、この鍵は、Oracle Security Token Serviceのみがアクセス可能な排他的パーティションに格納する必要があります。 |
|
セキュリティ・キー・ペア |
Oracle Security Token Serviceは、発行されたトークンのセキュリティおよびメッセージ・セキュリティのために別々の鍵ペアを作成することで、トークン署名鍵のセキュリティを提供し、Oracle WSMエージェントがOracle Access Manager/Oracle Security Token Serviceキーストアと連携する必要性を排除します。
|
|
OPSSキーストア |
メッセージ・セキュリティ・キー・ペアは、OPSSキーストアに移入されます。クライアントが(Webサービス・リクエストの一部として受信した証明書トークンではなく)SKIなどの参照スキームを使用する特別な場合、Oracle Security Token Serviceは、要求当事者の証明書をOPSSキーストアに移入します。これは一般的なシナリオではありません。Oracle Security Token Serviceには、OPSSキーストアに対して鍵を手動でプロビジョニングして機能させることについて、用意されている手順もあります。 |
Oracle STSは、WS-Trustプロトコルをサポートする一元化されたトークン・サービスで、セキュリティ・トークンの発行および交換ならびに信頼関係の確立のために、WS-Security仕様に対する拡張機能を定義します。Oracle STSは、Webサービス・エンドポイントとしてホストされ、WSCとWSPとの間におけるセキュリティに基づく相互作用を調整します。Oracle STSとのすべての通信は、図1-3に示すように、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-4では、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-5に示すように、Oracle Security Token Serviceの導入により、一元化された認証局でトークンの変換を行うことが可能です。
アプリケーションがビジネス・ロジック用の特別な形式の資格証明に依存している状況は、Oracleアクセス製品のデプロイメントにおいてよく見られます。Oracleおよびカスタム・アプリケーションとのWACシステムの統合では、(1)独自のベンダーAPI (SMエージェントAPIやASDK)をコールすることによる、あるトークン認証局(OAMやSiteMinderなど)により発行されたトークンの分解、および(2)アプリケーションがその内部ビジネス・ロジックのために必要とする新しいトークン形式(PSFT、Siebel)の構成のために、ほぼ必ず広範なコーディングが必要となります。
そうした変換は、アプリケーションのコーディングにより処理されることが多く、そのコードがDMZにある複数のアプリケーション・インスタンス上でデプロイされた場合に、ユーザー名やパスワードがさらされるといったリスクの要因となります。
セキュリティ管理者には、変換プロセスをアプリケーションから離して外在させ、そのプロセスを管理する能力が必要です。Oracle Security Token Serviceの導入により、この状況は大幅に改善されます。図1-6に示すように、Oracle Security Token Serviceは一元化されたトークン認証局の役割を担い、ファイアウォールの背後でトークン変換を実行します。
アプリケーション1およびアプリケーション2は、Oracle Access Managerにより保護されています。アプリケーション2は、その内部ビジネス・ロジックのために別のタイプのトークンに依存しています。このアプリケーションには、OBSSOトークンをユーザー名トークンと交換するためにOracle Security Token Serviceにコンタクトするクライアント側コネクタがあります。Oracle Security Token Serviceは、OBSSOトークンを分解するためにOracle Access Managerに依存しており、アプリケーション2が必要とする新しいトークンを生成します。
ここでは同一の認証局(Oracle Access Manager)が両方の操作(OBSSOトークンの構成および分解)を実行するため、より安全です。アプリケーション側でトークンを分解する必要はありません。
Web SSOと同様に、WebサービスSSOは便利な機能です。その違いは、Web SSOでは、その機能から恩恵を受ける当事者はユーザーであるという点です。WS環境では、次のようになります。
Web SSO: ユーザーが恩恵を受けます。
WebサービスSSO: セキュリティ管理者が恩恵を受けます。
WebサービスSSOでは、異なるWebサービスに異なるトークン要件があり、それが頻繁に変更されます。Oracle Security Token Serviceに交換を外在させると、アプリケーションが目的のトークンおよび現在保持しているトークンを単純に供給できるようになります。Oracle Security Token Serviceは、リクエストされた各サービスのトークン・タイプを決定することを引き受けます。
1つ以上のWebサービスでその認証要件が変更されても、Oracle Security Token Serviceは、アプリケーションにより送信されたトークン・タイプをシームレスに検証できます。トークンがリクエストされたタイプではない場合は、古いトークンが取り消され、正しいタイプの新しいトークンが発行されます。
図1-7に、WebサービスSSOを示します。
この項では、様々なインストール・オプションの簡単な概要として次のトピックを説明します。
単一のWebLogicドメイン内にある様々な管理対象サーバーでデプロイされたOracle Security Token Serviceインスタンスの間でクラスタリングを利用できます。このデプロイメント・トポロジでは、ロード・バランサにより高可用性機能が円滑化されます。デフォルトでは、Oracle Access ManagerとOracle Security Token Serviceが同一の管理対象サーバーに共存します。ただし、Oracle Security Token Serviceはデフォルトで無効になっており、これを使用できるようにするには、手動で有効化する必要があります。
このデプロイメント・トポロジでは、次に示すことを行うことになります。
スイート・インストーラを使用してOracle Security Token Serviceの複数のインスタンスをデプロイします。
ロード・バランサをデプロイして高可用性に加えてOracle Security Token Serviceクラスタのフロントでのフェイルオーバー・シナリオをサポートします。
詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
このインストール・オプションでは、リクエスタおよびリライイング・パーティとサード・パーティSTSサーバーとの間に相互運用性がもたらされます。実行時に、Oracle Security Token Serviceは、OPSS WS-Trustプロバイダを使用して、サード・パーティ・セキュリティ・トークン・サーバーのリクエスタおよびリライイング・パーティとの相互運用をサポートします。たとえば、サード・パーティ・セキュリティ・トークン・サービスが有効なSAMLアサーションを作成し、Oracle Security Token Serviceがそれを使用できます。
リクエスタとリライイング・パーティのためのすべての実行時シナリオは、WLSClient、MetroClientおよびOracle Web Services Manager (Oracle WSM)を含む、他のOracle WS-Trustクライアントによりサポートされています。
WS-Trustバインディングを介した場合のみ、すべてのWebサービス・クライアントがOracle Security Token Serviceでサポートされます。
Oracle Access ManagerとOracle Security Token Serviceは、1つのEARファイルから一緒にインストールされます。Oracle Access ManagerとOracle 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 Managementインストレーション・ガイド』を参照してください。
Oracle Access ManagerをOracle Security Token Serviceとともにホストするすべてのサーバーは、Oracle Access Managerに登録する必要があります。これはインストール中に自動的に、またはインストール後に手動で行うことができます。
Oracle Access Managerコンソールの要素を使用すると、管理者はトークン・サービスを容易に構成してWS Trustトークンをパートナと交換できます。トークン・サービスの要素は、パートナ、エンドポイント、検証テンプレート、発行テンプレートおよびデータ・ストア接続の作成、表示、変更および削除のために用意されています。
Oracle Security Token Serviceシステムのすべての構成は、Oracle Access Managerコンソールを使用して実行します。これにはこれまでに扱った次のトピックが含まれます。
情報はマニュアル全体から探すようにしてください。第V部「Oracle Security Token Service」のOracle Security Token Serviceの詳細には、特に注意してください。
1つのデフォルトLDAPグループ、WebLogic Serverの「Administrators」グループがデフォルトで設定されます。
初回のデプロイメント中に、Oracle Fusion Middleware構成ウィザードを使用して、管理者のユーザーIDおよびパスワードが設定されます。管理者は、Oracle Access Managerコンソール(およびWebLogic Server管理コンソール)にログインして使用できます。
詳細は、第3章「共通の管理およびナビゲーションの基礎」を参照してください。
