| Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド 11g リリース2 (11.1.2.3) E61957-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド 11g リリース2 (11.1.2.3) E61957-01 |
|
前 |
次 |
Security Token Serviceは、共有Webサービス(JAX-WS)であり、様々なIdentityドメインとインフラストラクチャ層との間での信頼を仲介する機能が統合された標準ベースのメカニズムを提供します。Security Token Serviceブローカは、Webサービス利用者(WSC)とWebサービス・プロバイダ(WSP)との間において信頼関係があり、セキュリティ・トークンのライフサイクル管理サービスを利用者とプロバイダに提供します。Security Token Serviceでは、標準化されたインタフェースのセットを使用することで、各種のシステム間を橋渡しするために必要な作業を単純化できます。
Security Token Serviceの高可用性デプロイメントは、Oracle Access Management Access Managerに依存します。Access Managerアプリケーションには、Oracle Security Token Serviceのサーバー・ランタイムが含まれています。Access ManagerとSecurity Token Serviceは、どちらもOAM J2EEアプリケーションEARファイルに同梱されていて、WebLogicドメイン内の同じ管理対象サーバーにまとめてインストールされ、デプロイされます。さらに、Security Token Serviceは、Oracle Access Managementコンソールに統合されます。
Security Token Serviceを管理および構成するには、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』で次のいずれかのトピックを参照してください。
Security Token Serviceのデプロイメントについて
Security Token Serviceの管理について
Security Token Serviceの実装シナリオ
Security Token Serviceの設定値と設定の管理
Security Token Serviceの証明書と鍵の管理
テンプレート、エンドポイントおよびポリシーの管理
Token Serviceパートナとパートナ・プロファイルの管理
パッチの適用については、Oracle Access Managerの管理の第11.1.1.3.0項から第11.1.1.6.0項を参照してください。
この章の内容は次のとおりです。
次の図は、高可用性アーキテクチャのSecurity Token Serviceを示しています。
この図は、Access ManagerとSecurity Token Serviceコンポーネントの2ノード・デプロイメントを示しています。
ロード・バランサはトークン・リクエストを受信すると、そのリクエストをSecurity Token Service (STS)にルーティングします。HTTP/SOAPのインバウンド接続には、外部ロード・バランサを使用することをお薦めします。LDAPに対するアウトバウンド外部接続は、接続フェイルオーバーのサポートとともにロード・バランシングされます。
Oracle Access Managementコンソールは、Security Token Serviceデプロイメントを管理するためのサービスを提供します。OAMデプロイメントの一部として、管理コンソールを管理サーバーにデプロイする必要があります。
各WebLogic Serverドメインで1つのSecurity Token Serviceクラスタがサポートされます。OAMとSecurity Token Serviceのクラスタは、ドメイン間にまたがることはできません。
RACデータベースは、Access ManagerによってCoherenceバックエンド・ストアとして使用されるデータベースと同じです。
Access Managerの全体的な高可用性アーキテクチャの詳細は、第6.2.1項「Access Managerの高可用性アーキテクチャ」を参照してください。
WS-Trustプロトコルを実装するWebサービス・クライアントは、トークンの発行および検証のために、Security Token Serviceと対話します。STSサーバーと対話するように設計されたクライアント(OWSMクライアントなど)は、リライイング・パーティへのWebサービス・コールの一環として、Security Token Serviceを呼び出すことができます。
このクライアント接続は、次のように処理されます。
Webサービス・クライアントは、httpまたはhttpsによってSOAPメッセージを送信します。
WSSプロトコルによって、メッセージを保護します。ペイロードには、実行する操作、発行または検証するトークンの種類、およびトークンの特性についての追加情報を示すWS-Trustリクエスト(RST)が格納されます。
サーバーはリクエストを処理して、そのリクエストをサーバーが受信したチャネルと同じチャネルでレスポンスを送信します。
WSSプロトコルによって、メッセージを保護します。処理が成功したときには、ペイロードにWS-Trustレスポンス(RSTRC)が格納されます。エラーが発生したときには、SOAP障害が格納されます。
Security Token Serviceアクセス・サーバーの各インスタンスは、他のインスタンスのピアになりますがインスタンス間の通信はありません。サーバーがリクエストを受信できるようになる前に、すべての初期化が組込のスロット機能と同時に行われるため、WebLogic ServerはSecurity Token Serviceアクセス・サーバーのパフォーマンス特性に大きな影響を与えることなく急増する条件を適切に処理します。
クラスタが停止すると、Security Token Serviceは新しいリクエストを拒否し、アクセス・サーバーのアプリケーションが停止する前に既存のリクエストを完了できるようにします。強制停止が行われた場合、Security Token Serviceはその強制停止によって破損または無効になったデータをリカバリできます。
構成の変更は、Coherence分散オブジェクト・キャッシュを利用する分散メカニズムに基づいて、すべてのクラスタ・メンバー伝播されます。Coherenceレイヤーは、すべてのSecurity Token Serviceコンポーネントに変更イベントを通知します。その後、このコンポーネントはそれらの変更を取り込みます。Access Managerコンポーネントには、変更が行われるたびにそれらの構成全体がリロードされます。
|
注意: アクセス・サーバーのインスタンスの追加または削除は、クラスタ内の他のSecurity Token Serviceインスタンスに対して透過的になります。特定のSecurity Token Serviceサーバーの削除が、ロードに影響しないことを確認してください。 |
この項には次のトピックが含まれます:
起動時に、Access ManagerとSecurity Token Service Serverは、バックエンド・リポジトリへの接続を開始します。このリポジトリにアクセスできない場合、Access ManagerとSecurity Token Serviceサーバーは、指数関数的に増加するタイムアウトを使用して接続を再試行します(このタイムアウトは上限を構成できます)。
Access ManagerとSecurity Token Service Serverは、バックエンドの接続が停止したときには、ローカルにキャッシュしたデータに基づいてサービスの持続性を提供します。サービスは、キャッシュの有効性が失われるか、バックエンドの接続が回復するまで持続されます。
次の図は、Security Token Serviceのランタイム・プロセスを示しています。
Security Token Serviceのランタイム・プロセスは、次の説明のように動作します。
Webサービス・コンシューマ(WSC)は、WSPが要求するセキュリティ・トークンのタイプについてのWeb Services-Trust (WS-Trust) Request Security Token (RST)メッセージを送信します。クライアントの認証は、トランスポート・レイヤーの認証を使用するか、WSSトークンをRSTメッセージにバインドすることで行われます。
Security Token Service (STS)はRSTメッセージを検証し、リクエストを認証してから、要求された操作の権限を付与します。
RSTメッセージによって指定されたメタデータに応じて、適切なセキュリティ・トークンが生成されます。ポリシー主導型の交換ユースケースでは、STSが適切なトークン生成ポリシーを検索し、該当するセキュリティ・トークンを生成します。
STSは、生成されたセキュリティ・トークンを格納するRSTメッセージを生成し、このメッセージをレスポンスとしてWSCに送信します。
|
注意: WSPによるセキュリティ・トークンの検証は、トークンのタイプに応じて異なります。STSが信頼の仲介者としてのみ機能する場合は、Kerberosなどの基幹セキュリティ・インフラストラクチャに対する検証が実行されます。 |
アクセス・サーバー(Security Token Serviceのデプロイ先)と管理コンソールは、どちらもJ2EEアプリケーションであるため、アプリケーション・サーバーが提供するユーザー・インタフェースやコマンド行ツールから起動できます。
J2EEのコンポーネントとサブコンポーネントには、次のものがあります。
STS: イベント・ベースのデザイン・パターンであり、Security Token Service 11g-PS1の中核部分を実装します。WARアプリケーションとしてAccess Manager EARファイルにパッケージ化されています。WSプロバイダ・サーブレットとJavaクラスが含まれています。STS Webアプリケーションは、/stsルート・パスにバインドされます。
管理コンソール: ADF/IDMシェルに基づくスタンドアロン・コンソールです。.EARファイルとしてパッケージ化されています。
JMX Mbeans: アクセス・サーバーにパッケージ化されています。構成Mbeanは、スタンドアロンのJARファイルとしてパッケージ化されています。
WSLTコマンド: Access Manager/Security Token Serviceパッケージに含まれているJavaクラスで構成されています。
OWSMエージェント: WSSプロトコルをサポートするWebサービスのインターセプタであり、JRFに含まれます。
ORAProvider: JRF Webサービス・プロバイダです。
Access ManagerとSecurity Token Serviceは一組になるように構築され、構成やロギングなどのプロセスに同一のモジュールを使用します。Security Token Serviceの構成アーティファクトには、次のファイルが含まれます。
DOMAIN_HOME/config/fmwconfig/oam-config.xml — インスタンス固有の情報を格納する構成ファイルです。
DOMAIN_HOME/config/fmwconfig/oam-policy.xml — OES Micro SMが使用されていない場合にのみ存在します。
DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — ロギング構成です。
DOMAIN_HOME/config/fmwconfig/cwallet.sso — アイデンティティ・ストア、データベースおよびその他のエンティティへの接続に使用するパスワードを格納します。これは、エンド・ユーザー用のパスワードではありません。
DOMAIN_HOME/config/fmwconfig/.oamkeystore — Access Manager/Security Token Serviceが所有する鍵と証明書を格納するキーストアです。
DOMAIN_HOME/config/fmwconfig/amtruststore — X509証明書の検証に使用されるトラスト・アンカーを格納するキーストアです。
DOMAIN_HOME/config/fmwconfig/amcrl.jar — 証明書失効に使用するCRLを格納するzipファイルです。
DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSMエージェントが使用する鍵と証明書を格納するOWSMキーストアです。また、WSS操作のためのX.509証明書の検証に使用されるトラステッド・アンカーも格納されます。
DOMAIN_HOME/config/fmwconfig/.cohstore.jks - Coherence SSL通信で使用されるトラスト・ストアです。
Security Token Serviceは、次の項目に対して外部依存性があります。
LDAPベースのアイデンティティ・ストア
ユーザー・アイデンティティ・リポジトリ
ユーザー/ロールAPIによって抽象化されるLDAPアクセス
|
注意: Access Managerは、常に1つのアイデンティティ・ストアに接続しますが、そのアイデンティティ・ストアは物理サーバーまたはロード・バランサIPです。プライマリが停止した場合、Access Managerはロード・バランサに再接続し、ロード・バランサによってセカンダリに接続します。 |
OCSPレスポンダ・サービス
リアルタイムX.509認証検証
RDBMSポリシー・ストア/Coherenceストア
ポリシー(認証および認可)リポジトリ
OAMポリシー・エンジンによって抽象化されるRDBMSアクセス
OPSSセキュリティ・ストア
Security Token Serviceの高可用性は、Access Managerの一部として構成されます。Security Token Serviceシステムのすべての構成は、Oracle Access Managementコンソールを使用して実行します。詳細は、第6.4項「Access Managerの高可用性の構成手順」を参照してください。
個別のSecurity Token Serviceサーバー上のSecurity Token Serviceのエンドポイントが稼働状態であり実行中であることを検証できます。これを実行するには、Security Token ServiceのエンドポイントのWSDLドキュメント(http(s)://[hostname:port]/sts/[ENDPOINT]/WSDL)に直接アクセスします。
[ENDPOINT]の部分は、既存の公開エンドポイントに置換してください。
Access Manager Access Serverは、ハートビート・チェック(HTTPによるPingリクエスト)をサポートしています。また、ノード・マネージャは、アプリケーションを監視し、必要に応じてそのアプリケーションを再起動できます。
WebLogic Serverノードに障害が発生すると、構成、再試行のタイムアウトおよび再試行の回数に基づいて外部接続のフェイルオーバーが行われます。Access Managerエージェントとアクセス・サーバーのフェイルオーバーはタイムアウトに基づいています。
ロード・バランシング・ルーターまたはプロキシ・サーバーがWebLogic Serverノードの障害を検出すると、後続のクライアント接続はアクティブなインスタンスに送信されます。このインスタンスは、セッション状態をCoherence分散オブジェクト・キャッシュから取得して処理を継続します。
フロント・チャネルHTTPバインディングでは、フェイルオーバーのためにロード・バランシング・ルーターが使用されます。
別のサービスから例外を受信した場合、Access Managerは、外部接続リクエストを再試行します。再試行の回数は構成可能です(no retriesのオプションもあります)。
詳細は、次の各項を参照してください。
Access Manager Access ServerとSecurity Token Service Access Serverは、HTTPでPingリクエストを送信する方式によるハートビート・チェックをサポートしています。また、管理対象サーバー上のWebLogicノード・マネージャでは、アプリケーションを監視して、イベントが実行されていない場合にはアプリケーションを再起動できます。Access Manager Access Serverを再起動しても、その他のクラスタ・コンポーネントまたはメンバーに影響はありません。
外部接続のフェイルオーバーは、構成、再試行のタイムアウトおよび再試行の回数に基づいて行われます。ロード・バランサまたはプロキシ・サーバーはノード障害を検出すると、後続のクライアント接続をアクティブなインスタンスにルーティングし、このインスタンスが、Coherence DOCからセッション状態を取得して処理を継続します。
Security Token Serviceは、デフォルトで有効化されています。Security Token Serviceを無効化するには、Oracle Access Managementコンソールを使用します。『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の使用可能なサービスの有効化または無効化に関する説明を参照してください。
Security Token Serviceのログは、管理対象サーバーのログ・ファイルに記録されます。ただし、logging.xmlを編集すると、Security Token Serviceのログを、<DomainHome>/config/fmwconfig/servers/<servername>/sts/log/のdiagnostic.logファイルに記録できます。
Security Token Serviceをトラブルシューティングするために、Security Token Serviceのログ・ファイルを作成する手順は、次のとおりです。
ファイルDomainHome/config/fmwconfig/servers/servername/logging.xmlを開きます。
次を、適切なセクションに追加します。
<log_handler name='sts-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='sts/log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
</log_handler>
<logger name='oracle.security.fed' level='TRACE:32'>
<handler name='sts-handler'/>
</logger>
すべてのログ・メッセージは、アプリケーションがデプロイされるWebLogic Serverのサーバー・ログ・ファイルに記録されます。デフォルトのサーバー・ログ・ファイルの場所は次のとおりです。
WL_HOME/user_projects/domains/domainName/servers/serverName/logs/serverName-diagnostic.log
Security Token Serviceサーバーは、リプレイ攻撃などの偽のリクエストを検出できますが、リプレイ攻撃は、リクエストからトークン・データを不正入手しようとして、同じトークンで別のリクエストを送信した場合に発生することがあります。この場合には、サーバーは2番目の偽のリクエストを検出します。2番目に発行された<Env: Body>に同一のトークンを持つリクエストは、Security Token Serviceサーバーに送られます。そこでは、UNTトークン・キャッシュを確認して、リプレイ攻撃を示すリクエストを拒否します。
