[SOA, Security] Securing Heterogeneous Systems Using Oracle Web Services Manager

原文はこちら。
http://www.oracle.com/technetwork/articles/soa/osb-silverlight-owsm-1634070.html

著者について
Ronald van Luttikhuizen
VennsterのManaging Partnerであり、Architect。Oracle ACE Directorでもある。
Jens Peters
Microsoft Certified Gold PartnerであるOne FoxのTechnical Architect。

Oracle Web Services Managerを使い、Microsoft .NETおよびSilverlightで構築されている従業員ポータルとOracle Service Busで公開されているWebサービス間の通信をセキュアに保つケーススタディをご紹介します。

Webサービスが新鮮でわくわくさせてくれた時期を思い出してみましょう。"真の"相互運用性と基本的なプラットフォームとツールセットからの独立性を提供することを約束して出発しました。当時、ベンダーは、WS-*標準がまだ完全に成熟していなかったときに、Webサービスを作成および使用するためのツールを投入したので、すぐに真の相互運用性を達成しなかったのは当然でした。クライアントがプロバイダと同じツールセットを利用して簡素かつ古いWebサービスを統合する場合はまず問題がありませんでしたが、クライアントの利用するものとは完全に異なる技術で生成されたWebサービスを利用しようとすると、それは悪夢になったことでしょう。特に、WS-Securityなど1つまたは複数のWS-*標準を適用した場合は。
我々は簡単に標準の解釈やサポート対象の標準のバージョン、エンコーディングなどが異なっていたために、.NETクライアントと容易に統合できなかったJava Webサービスのシェアを見てきました。一つの解決策は、Webサービスを生成するツールを使わずに手作業でWebサービスのプロバイダーやコンシューマを作る、というものですが、それは標準がもたらす付加価値の目的に反するものでした。幸いにも、WS-*標準、WS-Interoerabilityのような適合テストやツールセットが時間をかけて成熟してきました。今日、真の相互運用性という約束は、5、10年前よりもはるかに現実的です。
この記事では、Microsoft NET FrameworkとSilverlightの上に構築された従業員ポータル·アプリケーションがOracle Service Bus(OSB)で公開されているWebサービスを利用するケーススタディを調査しています。言うまでもなく、このシナリオには、2つの完全に異なるツールセット間のWebサービスの相互作用を伴います。記事では、これらのツールセット間のファースト・コンタクトを実現する方法、Oracle Web Services Manager(OWSM)を使って宣言的に公開されたWebサービスをセキュアにする方法、そして、ポータル·アプリケーションがこれらの保護されたサービスと対話する方法について説明します。

Case Study

ケーススタディは、オランダの公共セクターのプロジェクトをベースにしています。このプロジェクトの主な目標は、組織のIT環境の柔軟性と俊敏性を高め、それによって、組織とITシステムの両方で、将来の変更を簡素化することです。特にこの目標は、「ちょっとずつ実施する」サイロ化したアプリケーションの集合体というアプリケーションランドスケープから、明確かつ具体的な目的を持つ、再利用可能な、簡単に統合されたビルディングブロック(またはサービス)のランドスケープに徐々に変化することによって達成されます。これらのビルディングブロックは、新たに購入したコンポーネント(COTS)や、新規でカスタム開発されたサービス、既存のコンポーネントである可能性があります。
新しいアプリケーションランドスケープとそのコンポーネント概要を簡単に図1にまとめました。バックエンドシステム(黄色)の機能は、Oracle Service Busを使ってWebサービスとして公開されます。このような独自のプロトコルやデータフォーマットなどの基礎となる仕様は、バスが隠蔽します。こうした一般的なビルディングブロックの例には以下のようなものがあります。
  • 2個の既存の文書管理システムを仮想化するドキュメントサービス
  • ケース管理システムの機能を公開ケース管理サービス
  • 金融サービス
  • カスタマーサービスを介してアクセスできるCRM機能
公開されているサービスは、Oracle SOA Suite(赤)や組織の業務プロセスをサポートするために従業員が使用するポータルアプリケーションを用いて実装された、権限付与や許可プロセスのような、再設計されたビジネスプロセスによって消費され、再利用されます。ポータルは、Microsoft .NETとSilverlight(緑)で作成されています。
osb-silverlight-oswm-fig01
Figure 1
WebベースのCustomer Portalや他のビジネスプロセスといった将来のシステムは同じサービスを再利用するはずです。こうしたシステムの基礎となるテクノロジーが何になるかまだわかっていないので、サービスは相互運用性を担保しつつ、十分なセキュリティを含むQoSを提供できることが肝要です。

Security

サイロ化されたモノリシックシステムについて色々言われることがあります。変更が難しく、管理が困難で、分析が複雑、統合や再利用が面倒だ…と。しかし、セキュリティの観点では、一つの大きなモノリシックなシステムにすべてのデータや機能を組み合わせることは簡単です。データと機能が1つの場所に位置しており、効果的にそのようなシステムを保護すれば、データは保護され、機能をセキュアになります。 SOA環境において、データと機能は様々な小さな塊に分割されており、この塊自体がシンプルで柔軟性があり、かつ容易に変更と統合することができます。副作用として、ほんの少数のモノリシックなアプリケーションからなる環境の場合に比べて、より多くのメッセージがサービスと貴社間を流れることになるでしょう。このため、セキュリティに関してさまざまな見方が必要です。次のようなサービス指向の具体的な側面が、セキュリティへ影響する可能性があります。
  • 人とマシン間よりもマシン同士の相互作用の量が増大する。自動化された相互作用はセキュリティ機構、例えば認証についても自動化される必要がある。
  • 中間層のコンポーネント、例えばESBやエージェント、ルーティングサービスといったものが、メッセージの最初の受信者から最後の受信者までの間のメッセージ交換に参加する。こうした中間コンポーネントはこれらのメッセージに対しての操作や流通するメッセージの閲覧、変更は許可されていない。情報を輸送中は完全に保護するのに加え、それ以外の部分でも保護する必要がある。
  • 再利用可能なサービスには組織内外に数多くの利用者が存在しうる。利用者にサービスが公開する機能やデータにアクセスさせるかどうか決定する必要がある。さらに様々な利用者間でアクセス制御を区別できるようにする必要があります。
  • プロセス全体もしくは大部分を完全に自動化し人手を介さないstraight-through-processingが増えるでしょう。自動化が進み、増加する処理メッセージ量が原因でその反動として、障害の結果はかなりあとになって判明する可能性があります。優れたセキュリティと管理の必要性が高まるでしょう。
  • セキュリティの直接のコントロール対象外である外部サービスの利用が増えます。例えば、インターネット越しのクラウドベースのサービスの利用などです。逆に、貴社のサービスを外部機関が利用することがあります。利用者がセキュリティを含めたサービス品質を信頼している場合にのみサービスを使用します。
  • たぶん、組織が利用する全てのサービスが同じテクノロジーで構築されているわけではありません。同時にサービス間の統合の度合いが高くなるにつれ、実装に中立なセキュリティ基準が必要です。セキュリティの実装は、これらの基準を遵守すべきです。
ITシステムのセキュリティはトランスポート層やアプリケーション層で実装されることがよくあります。トランスポートセキュリティメカニズムの例には、SSL(もしくはTLS)を利用して、転送中のメッセージの暗号化や署名、2-way SSLのようなものを使い認証の強制をするようなことがあります。トランスポートレベルのセキュリティだけを使うと、残りのデータが保護されないという欠点があります。これは中間コンポーネント(例えばESBやBPMプラットフォーム)で処理されるメッセージの場合が相当します。メッセージレベルセキュリティを利用すると、メッセージ自身が署名、暗号化され、認証・認可情報を含むことができます。メッセージレベルセキュリティを使うと、こうした中間コンポーネントに蓄積および処理している間もデータを保護することもできます。数多くの記事や書籍でトランスポートレベルのセキュリティやメッセージレベルのセキュリティについて説明していますので、この記事ではそのあたりのメカニズムの詳細には触れません。

Oracle Web Services Manager

Oracle Web Services Manager (OWSM) はポリシー(もしくはエージェント)ベースのサービスのセキュリティ要件を実装するセキュリティフレームワークを提供しています。つまり、カスタムコーディングや開発をしなくても、セキュリティ機能を宣言的にサービスプロバイダやクライアントに追加できるということです。OWSMはほとんどのよく使われるセキュリティ要件に対応する数多くのポリシーを標準で提供します。これらのポリシーを以下のカテゴリに分類します。
  • 信頼性のあるメッセージング
  • 管理
  • アドレッシング
  • セキュリティ
  • メッセージ転送最適化メカニズム(MTOM).
これらのポリシーが提供する機能は以下の通りです。
  • WS-Security Username Tokenを使った認証
  • WS-Security標準やPKI証明書を使ったメッセージの暗号化および署名
  • WS-Addressingの情報をリクエスト・レスポンスメッセージに追加
  • 入出力メッセージのロギング
すべてのサポートしているポリシーは、ドキュメント「Security and Administrator's Guide for Web Services」をご覧下さい。
OWSMはほとんどのメッセージレベルセキュリティを実装しています。トランスポートレベルのセキュリティは、OWSMやサービスが動作するOracle WebLogic ServerのSSLサポートを使って実装されています。
Oracle® Fusion Middleware Security and Administrator's Guide for Web Services 11g Release 1 (11.1.1.7)
http://docs.oracle.com/cd/E28280_01/web.1111/b32511/toc.htm
設計時にOracle JDeveloperやOracle Enterprise Pack for Eclipseからポリシーの追加や設定を実施できるだけでなく、Oracle Enterprise ManagerやOracle Service Busのコンソールを使用して、実行時にも追加や設定が可能です。 Oracle Enterprise Managerを使ってポリシーを監視し、これらのポリシーの違反検査(たとえば、間違ったユーザー名とパスワードの組み合わせを使用した場合など)が可能です。ポリシーを異なるサービス実装に適用することができます。例えばSOAコンポジット、OSBサービス、Oracle WebLogic Server上で実行されているプレーンなJAX-WS Webサービスに適用することができます。
図2では、DocumentService(再掲)とサービスを呼び出す従業員ポータルを示していますが、今回は、標準装備のoracle/wss_username_token_service_policyを使い、WS-Security Username Tokenに基づいて認証を強制してサービスを保護します。監査目的のため、oracle/log_policyポリシーを適用し、DocumentServiceに送信されるすべてのリクエスト・レスポンスメッセージのログを採取します。 DocumentServiceの実装には手を入れず、ポリシーを設定で適用します。サービス利用者はこれらのポリシー(の詳細)を認識しません。
osb-silverlight-oswm-fig02
Figure 2
ご覧の通り、ポリシーをつなげてより複雑なセキュリティ要件を満たすことができます。OWSMでは拡張できるメカニズムも提供しており、標準装備のポリシーでは不十分な場合には、カスタムポリシーをJavaで開発することもできます。
OWSMは、Oracle WebLogic Serverへ統合されており、そのプラットフォームが提供するセキュリティAPIを使用しています。つまり、OWSMは、Oracle Internet Directory(OID)やOracle Access Manager、その他のLDAP準拠の製品のようなWebLogic Serverで構成される認証プロバイダに認証・認可を委任することができます。

Implementing Security in the Case Study

ケーススタディをもう一度見てみましょう。ポータルと公開されているWebサービス間の相互作用のために次のセキュリティ要件を認識しています。
  • 直接バックエンドのサービスを呼び出して付与を作成、承認させてはいけない。認証を強制してWebサービスや基盤機能への認可されていないアクセスを避ける。認証を既存のOID(Oracle Internet Directory)に委任するべきである。
  • 志願者の個人情報のような機密データが含まれるため、ポータルとOSB間を流れる傍受されたメッセージは、秘匿されるべきである。機密性を追加し、メッセージの傍受を防ぐ必要がある。
トランスポートレベル、もしくはメッセージレベルのセキュリティを使って、こうした要件を満足することができます。この例ではWS-Security Username Tokenを認証に使い、トランスポートレベルでの秘匿性のためにSSLを使います。
次章では、OWSMを使ってWebサービスを保護する方法、そしてこうした保護されたサービスをMictrosoft Silverlightから呼び出す方法をご紹介します。

Implementation

HelloWorldデモは以下の手順からなります。これらの手順は後段で説明します。
  1. OSBのサービスを保護する
    1. WebLogic ServerでSSL有効化
    2. OWSMポリシーの適用
    3. 認証プロバイダ
    4. 保護したサービスをsoapUIでテストする
  2. Silverlightクライアントにセキュリティ構成を追加する
    1. Silverlight概要
    2. SilverlightからクロスドメインのWebサービスへのアクセスを可能にする
    3. SSLの落とし穴
    4. SilverlightのWS-Security実装

Secure OSB Services

この章ではSSLをOSBが動作する管理対象サーバーで有効化する方法と、OWSMポリシーをOracle Service Bus管理コンソールから適用する手順を説明します。

Enable SSL on WebLogic Server

トランスポートレベルセキュリティを実装する必要があるため、管理対象サーバーがSSLをサポートしていることを確認する必要があります。
  1. Oracle WebLogic Server管理コンソールにログインして、SSLを有効化し、SSLリスニングポートを割り当てます。
  2. [環境]>[サーバー]で対象とする管理対象サーバーを選択し、[SSLリスニングポートの有効化]チェックボックスを選択します。必要であれば、デフォルトのSSLリスニングポートを変更することができます。
osb-silverlight-oswm-fig03
Figure 3
ご注意頂きたいのは、Oracle WebLogic Serverは、1-way SSLや2-way SSL用にデモ用アイデンティティストア、トラストストア、鍵、証明書を使います。本番環境の場合、デモ用ストアから、自己署名証明書ではなく、信頼された証明書発行機関が発行した「本物」のキーストアに置き換えるべきです。

Apply OWSM Policies

OWSMをOSBと共に使うための前提条件は、OWSMとMDSを含むOracle WebLogicドメインにOSBをインストールし構成することです。OSBで公開しているWebサービスにOWSMポリシーを適用するのは、OEPE(設計時)もしくはService Bus管理コンソール(実行時)のいずれを使っても非常に簡単です。今回は実行時のコンソールを使います。
  1. 管理コンソールにログインし、保護したいプロキシサービスの[ポリシー]に移動し、oracle/wss_username_token_service_policyポリシーを選択します。このポリシーは(メッセージの秘匿性のために)SSLと、WS-Security Username Tokenを使った認証を強制します。

    ご注意頂きたいのは、SSLをOracle WebLogic Serverレベルで構成するということです。しかしポリシーはメッセージがSSLを使ってOSBに送信されていることを検証します。
osb-silverlight-oswm-fig04
Figure 4
  1. ポリシーをセットしたら、セキュリティ設定で[WS-Securityヘッダーの処理]を有効にする必要があります。この変更により、プロキシサービスがセキュリティの仲介ができるようになります。このフラグが設定されていない場合、認証が失敗します。
[注意] [WS-Securityヘッダーの処理]の設定が表示されないことがあります。我々のケースでは、WSDLおよびXSDファイル(documentation要素など)のいくつかの非ASCII文字がこの動作を引き起こしていることがわかりました。 WSDLおよびXSDファイルからこれらの文字を削除すると、この問題が解決しました。

osb-silverlight-oswm-fig05
Figure 5
適用したポリシーは最高のセキュリティを提供するわけではありません。それは平文のユーザー名、パスワードの組み合わせを使っているためです。代替ポリシーとして、パスワードハッシュや認証トークンを使うポリシーがあります。メッセージレベルの署名や暗号化を適用することも可能ですが、このデモの場合、相互運用性がこのポリシーを選択した主要な関心ゆえ、提供するセキュリティレベルはこれで十分です。さらに、トランスポートレベルでSSLが適用されているため、資格証明は平文で送られることはありません。
以下のスニペットは、WS-Security Username Tokenとしてユーザー名、パスワードの組み合わせを含むSOAPメッセージのサンプルです。
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <Security s:mustUnderstand="1" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd">
      <UsernameToken u:Id="7fba817f-4406-4a23-a65e-98e1df2b3e0d">
        <Username>weblogic</Username>
        <Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-
profile-1.0#PasswordText">weblogic1</Password>
      </UsernameToken>
    </Security>
  </s:Header>
  <s:Body>
    <GreetingRequestMessage xmlns="http://www.example.org/HelloWorld/">
      <in xmlns="">Hello World !</in>
    </GreetingRequestMessage>
  </s:Body>
</s:Envelope>

Authentication Provider

Oracle WebLogic Serverは認証・認可のためにデフォルトのファイルベースのAuthenticatorを使いますが、Oracle WebLogic Serverのプライマリ認証プロバイダを設定すれば、既存のOracle Internet Directory(OID)に認証 を委任することができます。この方法では、リクエストメッセージのWS-Securityヘッダーからユーザ名とパスワードの組み合わせを、LDAP準拠のOIDに対して検証します。
osb-silverlight-oswm-fig06
Figure 6
  1. Oracle WebLogic Server管理コンソールにログインし、[セキュリティ・レルム]>[プロバイダ]>[新規]で新しい認証プロバイダを構成します。
  2. OracleInternetDirectoryAuthenticator]を選択し、新しい認証プロバイダの名前を指定します(例:OIDAuthenticator.)
  3. 必要な設定情報を埋めてウィザードを完了します。OIDをプライマリ認証プロバイダとして構成する手順は以下のドキュメントに詳細が記載されています。
Oracle® Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1(10.3.6)
http://docs.oracle.com/cd/E28389_01/web.1111/b61617/toc.htm
Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6)
http://docs.oracle.com/cd/E23943_01/web.1111/e13707/toc.htm
サービス側で必要な手順(SSLおよびWS-Security)はこれで完了です。これで、サービス利用側の作業の前に、保護されたサービスをテストすることができます。

Test Secured Services with soapUI

保護されたWebサービスをsoapUIを使ってテストしますが、これは保護されていないWebサービスのテストとそれほど違いはありません。
  1. soapUIを立ち上げ、新しいプロジェクトを作成し、WebサービスのWSDLをインポートします。HTTPではなくHTTPSのWSDLを設定することに注意してください。OSB管理対象サーバのURLにOSBプロキシサービスの場所を後に付けると、WSDLエンドポイントができあがります。例えば以下のような具合です。
    https://localhost:8012/HelloWorldService/SSL?wsdl
    [注意] SSLポートなので、8011ではなく、8012を使っています。また、Service Bus管理コンソールの[プロキシサービスの設定]から、エンドポイントの場所を設定できます。
  2. [Navigator]でダブルクリックしてsoapUIプロジェクトを編集し、[Security Configurations]に移動します。
  3. [+]アイコンを選択して、発信するWS-Securityの構成を追加します。
  4. セキュリティ設定の名前を設定し、デフォルト値として使用される有効なユーザー名/パスワードの組み合わせを入力します。テスト目的のため、WebLogicアカウントを使用できますが、実際にはおそらく、新しいシステムアカウントを使用するか、動的にユーザーアカウントを使いWS-Security Username Tokenを設定することになるでしょう。 [Password Type]をPasswordTextに設定します。
  5. soapUIでテストプロジェクトを展開し、soapUIがテスト用途に使える一つのリクエストメッセージを生成したことを確認します。
  6. 一番下のAutタブで、新規に作成された送信WSS設定を選択し、WSSヘッダーに追加します。必要であれば、ユーザー名属性とパスワード属性のデフォルト値をオーバーライドすることもできます。
  7. 緑色の再生アイコンを選択して、テストリクエストメッセージを送信します。リクエストメッセージ中のWS-Securityヘッダーにはユーザー名トークンが含まれていることにご注意下さい。OSBプロキシサービスから返された有効なレスポンスメッセージがあるはずです。
  8. 応答メッセージの[SSL Info]タブを選択し、応答メッセージのSSL証明書情報を検査してください。
osb-silverlight-oswm-fig07
Figure 7
  1. リクエストメッセージを変更し、誤ったパスワードを渡してテストを再度実施します。OSBからセキュリティに関するエラーを受信するはずです。
保護されたサービスのテストが終わったので、続いてクライアント側の構成を実施しましょう。

Add Security Configuration to a Silverlight Client

次のセクションでは、Oracle Service Busで公開されているセキュアなWebサービスを利用するSilverlightアプリケーションを作成する方法を説明します。WS-SecurityヘッダをSilverlightアプリケーションに追加し、SSLを有効化する方法をご紹介します。これらの手順は通常の.NET Windows Communication Foundation (WCF) アプリケーションにも適用します。

Introduction to Silverlight

Microsoft Silverlightは主にWebベースのアプリケーションを作成するために使われるプラットフォームで、HTML5や、HTMLやCSSを描画するASP.NET、JSP、JSFといったサーバーベースのフレームワークではなく、Adobe FlashやJavaアプレットに類するプラグインが必要です。すでにMicrosoftプラットフォーム上で実行している企業にとって、ビジネスアプリケー(イントラネットの)ションを作成するにはMicrosoft Silverlightは良い選択でしょう。
Silverlightは.NET frameworkベースです。Silverlightのフレームワークは、数多くのおなじみのクラスや名前空間を.NET frameworkから継承します。Windows Communication Foundationが.NETプラットフォームにおけるプロセス間通信のためのデファクトスタンダードです。以後、Silverlightは、Webサービスにアクセスするための"WCF-light"を使用しています。
Microsoft Silverlight
http://www.silverlight.net/

Gaining Access to a Cross-Domain Web Service from Silverlight

Silverlightソリューションでは、WebサーバはバックエンドのWebサービスと通信できません。 Silverlightアプリケーションは、 「古典的な」 ASP、JSP、またはJSF Webアプリケーションとは対照的に、ブラウザから直接サービスを呼び出して動作します。つまり、1つまたは2つのサーバーからではなく、様々なクライアントマシンからWebサービスへのリクエストが発生することを意味します。このようなアーキテクチャでは、OSBのサービスにアクセスする、固定されたクライアントとして振る舞う集中型Webサーバーが存在しないため、標準的なアクセス制御ベースのセキュリティ(例えばIPアドレスベース)はあまり有効ではありません。
デフォルトではCSS(cross-site scripting)やCDRF/CSRF(Cross Domain Request ForgeryもしくはCross Site Request Forgery)のようなセキュリティリスクへの対策として、Silverlightアプリケーションと同じ起源のドメインもしくはサイト(サブドメイン、プロトコル、ポート)で実行していないWebサービスの呼びだしは許可されていないことにご注意下さい。これはSilverlightアプリケーションがOracle Service Busとは異なるドメインで実行されたとき、またはSilverlightアプリケーションがHTTPでアクセスされているのに対し、Webサービス呼び出しをHTTPSで実行している場合に相当します。これらのセキュリティ上の考慮事項ゆえに、SilverlightアプリケーションとWebサービスの間の通信を許可するように環境を設定する必要があります。
そのような場合には、まず関与するセキュリティリスクと考慮事項を分析し、クロスドメインのアクセスを有効にする前に、適切に測定することを強く推奨します。Oracle Technology NetworkにあるSecurity Guidesにもあるような、セキュリティニーズや測定に関する情報を提供する数多くのリソースがあります。
WebLogic Server Documents(英語)
http://docs.oracle.com/cd/E23943_01/wls.htm
(日本語)
http://docs.oracle.com/cd/E28389_01/wls.htm
Adobe Flashの場合と同様、Microsoft Silverlightは、実際のWebサービスへの通信を許可する前に、Webサービスをホストしているサーバーのルートにあるclientaccesspolicy.xmlまたはcrossdomain.xmlという設定ファイルを処理することができます。このような設定ファイルで、Webサービスへのアクセスを規制します。Oracle Service Busは、Oracle WebLogic Server上で動作するため、clientaccesspolicy.xmlファイルをホストするという唯一のタスクを持つ、小さなWebLogic Webアプリケーションを作成しましょう。クロスドメインアクセスの情報の詳細を知りたい方は、以下のMicrosoft MSDN Libraryのドキュメントをご覧下さい。
Networking and Web Services
http://msdn.microsoft.com/en-us/library/cc645029(v=VS.95).aspx
  1. Oracle Enterprise Pack for Eclipseを使ってDynamic Web Projectを作成します
osb-silverlight-oswm-fig08
Figure 8
  1. 以下のclientaccesspolicy.xml ファイルをプロジェクトに追加します。これにより、全てのHTTP/HTTPSインバウンドリクエストを許可します。
  2. <?xml version="1.0" encoding="utf-8"?>
    <access-policy>
      <cross-domain-access>
        <policy>
          <allow-from http-request-headers="SOAPAction">
            <domain uri="http://*" />
            <domain uri="https://*" />
          </allow-from>
          <grant-to>
            <resource path="/" include-subpaths="true"/>
          </grant-to>
        </policy>
      </cross-domain-access>
    </access-policy> 
    ポリシーファイルは任意のクライアントからのアクセスが許可されていることに注意してください。実際の環境ではこのポリシーを状況に応じて変更する(制限を厳しくする)ことをお勧めします。 ファイルを追加して、EclipseのプロジェクトはFigure 9のようになっているはずです。
osb-silverlight-oswm-fig09
Figure 9
  1. weblogic.xml デプロイメント・ディスクリプタをプロジェクトに追加します。clientaccesspolicy.xml ファイルがルートに存在する必要があるため、この中で、"/"(ルート)をコンテキストルートとして定義しています。
osb-silverlight-oswm-fig10
Figure 10
  1. プロジェクトをWARファイルにエクスポートし、WebLogic Serverの管理対象サーバーにデプロイします。
osb-silverlight-oswm-fig11
Figure 11
  1. ブラウザからclientaccesspolicy.xml ファイルにアクセスしてデプロイされていることを確認しましょう。
osb-silverlight-oswm-fig12
Figure 12

SSL Pitfalls

適用したOWSMポリシーはWSSユーザー名/パスワードの組み合わせを平文で送信することを忘れてはいけません。"PasswordText"を使うと、SilverlightはHTTPではなく、HTTPSを使うことを強制します。平文のパスワードをHTTPで送信すると、セキュリティ強化のためのこうしたWSSヘッダーの追加する目的に反します。
(参考) How to: Use Message Credentials to Secure a Service for Silverlight Applications, Microsoft MSDN Library http://msdn.microsoft.com/en-us/library/dd833059(v=vs.95).aspx
次のステップでは、Silverlightアプリケーションが実行されているブラウザでサーバ(この場合はOracle WebLogic Server)が使用する証明書をインポートします。証明書は、WebLogicキーストアから、keytoolユーティリティ(JDKの一部)を使って取得できます。詳細については、Securing Oracle WebLogic Serverをご覧ください。
Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6) http://docs.oracle.com/cd/E28280_01/web.1111/e13707/toc.htm
Oracle® Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1(10.3.6) http://docs.oracle.com/cd/E28389_01/web.1111/b61617/toc.htm
osb-silverlight-oswm-fig13
Figure 13
[注意] 不正な証明書を使う場合、常にブラウザは証明書の信頼性に関する問題を警告してきます。Webサービスを呼び出そうとすると、有名なクロスドメインエラーが現れます。

Implementing WS Security in Silverlight

では、SilverlightアプリケーションをVisual Studioで作成しましょう。
  • 新しいSilverlightプロジェクトを作成します([ファイル] > 新規作成 > プロジェクト )。
  • インストール済みテンプレートのペインでSilverlightを選択し、ウィザードを終了してプロジェクトを作成します。
  • [ソリューションエクスプローラ]で新規生成したプロジェクトを右クリックし、[サービス参照の追加]を選択してOSBのサービスのWebサービスプロキシを作成します。
  • [アドレス]にWebサービスのエンドポイントを入力し、他の必要な設定を入力して、プロキシクラスを作成します。
osb-silverlight-oswm-fig14
Figure 14
Silverlightプロジェクトの作成およびWebサービスクライアントの作成に関する詳細は、MicrosoftのMSDN Libraryにある以下のドキュメントをご覧下さい。
How to: Create a New Silverlight Project http://msdn.microsoft.com/en-us/library/cc838164%28v=vs.95%29.aspx How to: Add, Update, or Remove a Service Reference http://msdn.microsoft.com/en-us/library/bb628652.aspx
次に、生成されたWebサービスバインディングに手を入れ、WS-Securityメッセージ資格証明をアウトバウンドSOAP呼び出しに追加し、WebサービスをHTTPSで呼び出す必要があります。前述の通り、SilverlightはWebサービスとの対話においてWFCのサブセットを使用します。WCFはWS-Security Username Token標準をサポートしています。
How to: Use Message Credentials to Secure a Service for Silverlight Applications http://msdn.microsoft.com/en-us/library/dd833059(v=vs.95).aspx
Webサービスバインディングの構成をVisual Studioで編集してこの構成を作り、以下のスニペットを追加します。
<customBinding>
  <binding name="BasicWsSecurity">
    <security authenticationMode="UserNameOverTransport" includeTimestamp="false"/>
      <textMessageEncoding messageVersion="Soap11"/>
      <httpsTransport/>
  </binding>
</customBinding>
ここで、WS-Securityヘッダーを設定するために使用するClientCredentialsプロパティを使い、ユーザー名とパスワードを設定する必要があります。これは、すべてのWebサービス·プロキシに一度実行する必要があります。
HelloWorldClient client = new HelloWorldClient("HelloWorldSOAP_BasicWsSecurity");
client.ClientCredentials.UserName.UserName = "weblogic";
client.ClientCredentials.UserName.Password = "weblogic1";
Figure 15
すべての設定が終了したので、Silverlightアプリケーションを実行し、OSBが公開するセキュアなWebサービスを呼び出すことができます。
Silverlightアプリケーションが保護されたWebサービスからのレスポンスメッセージを表示しています。

Summary

OracleやMicrosoftのツールスタックのような異種プラットフォームを統合する際に、WS-Securityなど相互運用性に関する標準の付加価値が顕著に現れます。Oracle Web Services Manager (OWSM)は、SSLやWS-Security、SAMLなどの標準を適用し、実施することにより、サービスやビジネスプロセスを保護するための、Oracleの主要なツールであり、コーディングが不要で、かつセキュリティが必要なところに、ランタイムでポリシーを適用するという、宣言的な方法で行えます。OWSMは数多くの事前定義済みポリシーを備えており、これにより簡単にOracle SOA SuiteやOSB、Oracle WebLogic Serverによって公開されているWebサービス(JAX-WS Webサービス)に適用できます。 この記事ではOWSMポリシーをOracle Service Busで公開しているWebサービスに適用し、このWebサービスをMicrosoft Silverlightで構築されたWebアプリケーションから利用する方法について説明しました。SilverlightはWindows Communication Foundation (WCF)と密接に関連しており、これはWS-Securityをサポートしています。 セキュリティの計量を利用することは最も簡単な作業ではありません。セキュリティに関連するエラー·メッセージを隠蔽し、機密情報(例えばプラットフォームのバージョンやスタックトレース、必要なセキュリティ設定など)を外界にさらすことを防ぐことができると共に、ペイロードを暗号化することができます。引き替えに、セキュアな環境でのデバッグはいささか難しくなることがあります。 幸いなことに、セキュリティの実装およびテストを支援する、便利なツールがご利用頂けます。例えば…
  • Fiddler
    ネットワーク越しにどんなデータ(セキュリティヘッダを含むリクエスト、レスポンス)を送信したかを調査できます。
  • soapUI
    Webサービスのテスト、モックとして利用できます。
  • Oracle Web Services Manager
    入出力メッセージのロギングポリシーが使えます。
標準には通常、解釈の余地が残っており、ベンダーはめったに文字通りに完全に標準を実装することはありません。完全に異なるテクノロジー、例えばOracleやMicrosoftプラットフォームを統合する肝心なときに問題が起こることがあります。問題を最小化するためにも、是非相互運用ガイドを確認して下さい。
Oracle® Fusion Middleware Interoperability Guide for Oracle Web Services Manager 11g Release 1 (11.1.1.6) http://docs.oracle.com/cd/E23943_01/web.1111/e16098/toc.htm
Oracle® Fusion Middleware Interoperability Guide for Oracle Web Services Manager 11g Release 1 (11.1.1.7) http://docs.oracle.com/cd/E28280_01/web.1111/e16098/toc.htm
Oracle® Fusion Middleware Oracle Web Services Manager相互運用ガイド 11gリリース1 (11.1.1.6) http://docs.oracle.com/cd/E28389_01/web.1111/b61391/toc.htm

0 件のコメント:

コメントを投稿