Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
前 |
次 |
次の各トピックでは、デプロイメント・オプションについて詳しく説明します。
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システムの信頼を維持する必要があります。これは複雑であり、複数の信頼関係を維持することになるので、セキュリティも高くありません。
図41-3に示すように、セキュリティ・トークン・サービスの導入により、一元化された認証局でトークンの変換を実行できます。
セキュリティ・トークン・サービスにより、管理者は、トークン変換プロセスをファイアウォールの内側で実行することでそのプロセスを制御できます。
アプリケーションがビジネス・ロジック用の特別な形式の資格証明に依存している状況は、Oracleアクセス製品のデプロイメントにおいてよく見られます。Oracleアプリケーションとカスタム・アプリケーション両方とのWACシステムの統合は、ほぼ必ず、次のことを行う拡張コードを必要とします。
独自のベンダーAPI (SMエージェントAPIまたはASDK)をコールすることにより、1つのトークン認証局(OAM、SiteMinderなど)によって発行されるトークンの分解。
内部ビジネス・ロジック用にアプリケーションが必要とする新しいトークン・フォーマット(PSFT、Siebel)の構成。
そうした変換は、アプリケーションのコーディングにより処理されることが多く、DMZにある複数のアプリケーション・インスタンス上でデプロイされた場合、ユーザー名やパスワードが公開されるリスクの要因となります。したがって、セキュリティ管理者には、変換プロセスをアプリケーションから離して外在させ、そのプロセスを管理する能力が必要です。セキュリティ・トークン・サービスの導入により、この状況は大幅に改善されます。
図41-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は、アプリケーションにより送信されたトークン・タイプをシームレスに検証できます。トークンがリクエストされたタイプではない場合は、古いトークンが取り消され、正しいタイプの新しいトークンが発行されます。
図41-5に、WebサービスSSOを示します。