WebSphere Application Server V7 アナウンスメント...

1

© 2008 IBM Corporation

WebService QoS & Policy

日本IBMシステムズ・エンジニアリング(株)Webインフラストラクチャー高浜めぐみ ([email protected])

2

WAS V7 W/S

# 2

© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7

Announcement Workshop 2008

WAS V7 W/SDisclaimer

当資料で提供する技術情報は、各製品の出荷前コードに基づくものを含みます。

この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エムシステムズ・エンジニアリング株式会社の正式なレビューを受けておりません。

当資料は、資料内で説明されている製品の仕様を保証するものではありません。

資料の内容には正確を期するよう注意しておりますが、この資料の内容は2008年10月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意下さい。

今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。

3

WAS V7 W/S

# 3



WAS V7 W/SAgenda

WebサービスにおけるQoS高信頼性Webサービス～WS-ReliableMessaging～会話型Webサービス・セキュリティ～WS-SecureConversation～Webサービス・ポリシー(参考)Webサービス・トランザクション

4

# 4



WAS V7 W/SWAS V7 W/SWebサービスにおけるQoS

5

WAS V7 W/S

# 5



WAS V7 W/SQoSとは

サービスの性能、品質一般的に非機能要件に属する

機能要件/業務要件

非機能要件

性能・品質要件

パフォーマンス信頼性セキュリティー運用管理

予算スケジュールスキル配置場所/環境既存システム準拠する標準/規約

制約

アプリケーション要件

データ要件

信頼性 WS-ReliableMessaging….セキュリティ WS-Security,WS-SecureConversation…運用管理 WS-Policy…トランザクション WS-AtomicTransaction,WS-BusinessActivity…

QoSを支えるWebサービス標準仕様QoSを支えるWebサービス標準仕様

WebサービスにおけるQoSの在り方について説明します。QoSは一般的に非機能要件に属します、システムやサービスが提供すべき性能と品質のことを指します。具体的にはパフォーマンス、信頼性、セキュリティー及び運用管理などが挙げられます。

Webサービスは実装言語や環境に依存しないという特徴から、QoSを実現するための技術を標準仕様で提供しています。OASISやW3Cなどの標準化団体が策定しています。

6

WAS V7 W/S

# 6



WAS V7 W/SWebサービス仕様群

Webサービスに関連する仕様

Service Composition

Transports

Messaging

Description

Quality ofService(QoS)

HTTP/HTTPS SMTP RMI / IIOP

XSD WSDL

SOAPXML WS-Addressing WS-Renewable References

WS-Policy

WS-Service Group

WS-Resource Properties

JMS

WS-Security

WS-Reliable Messaging WS-Transaction

WS-Resource Lifetime

WS-Base Faults

WS-Notification WS-BPEL

WS-Metadata Exchange

WASv6.1 FeaturePack for WebServices NEW WAS V7 NEW

グレー文字：WAS未サポート

現在標準化団体や営利企業グループによって策定作業が進められているWeb サービス関連仕様の一部をレイヤー化して示します。青印のものはWAS V6.1 FeaturePack for WebServicesで新たにサポートされた仕様、赤印のものは更に、WAS V7で新たにサポートされた仕様を示しています。

グレー文字の仕様はWASではまだサポートされていない仕様です。

7

WAS V7 W/S

# 7



WAS V7 W/S

WS-I Reliable Secure Profile 1.0

WS-I Basic Security Profile 1.0/1.1

WAS V7におけるWS-I プロファイル構成

WS-I ReliableSecureProfile(RSP) 1.0

Webサービスの信頼性とセキュリティに関する相互運用のためのプロファイル

IBMがGM社,Ford社,Daimler Chrysler社と共に作成したB2B要件のプロファイル

2006年4月 WS-Iから正式採用を承認

2008年5月 Working Group Draft

Webサービス非同期通信の標準技術

WS-I Basic Profile 1.0/1.1

Username Token Profile

X.509 Token Profile

WS-Security 1.0/1.1

WS-Trust 1.3

WS-SecureConversation 1.3

WS-ReliableMessaging 1.1

Kerberos Token Profile

SAML Token Profile

REL Token Profile

WS-Addressing

MTOM

WS-I Basic Profile 1.2

SOAP1.2WS-I Basic Profile 2.0

WS-I Attachment Profile

WS-I Simple SOAP Profile

Newv7

WAS V7がサポートするWS-Iプロファイルの構成を説明します。WS-IはWebサービス関連の各種標準を策定しているW3CやOASISと連携しながら活動しています。それ以外の団体とも協調しながら業界の標準となるものを作成しています。WS-Iの活動のメインは、”プロファイル”と呼ばれるインターオペラビリティに関するガイドを作成することです。プロファイルとはインターオペラビリティの実現に必要な仕様を選択し組み合わせて、矛盾、曖昧性が無いようにガイドしたものです。WS-Iでは、新しく仕様を作成することはありません。あくまでも既に存在する複数の標準を対象としてインターオペラビリティを保つにはどのようにしたらよいかをプロファイルとして文書化して公開しています。一般的な標準化団体では、技術仕様を発表してから投票採用が実施されますが、WS-Iはまず、企業顧客やソフトウェアベンダーがプロファイルを発表してから投票採用が行われます。

・WS-I Reliable Secure Profile (RAMP)RAMPはIBMがGM社、Ford社、Daimler Chrysler社とともに作成したB2B要件のプロファイルで2006年4月にWS-Iから正式採用が承認されました。Webサービスの非同期通信の標準技術です。RAMPはWS-I BasicProfileおよびWS-I Basic Security Profileの上に、WS-Addressing、WS-ReliableMessaging(WS-RM)、WS-SecureConversation(WS-SC)の３つの仕様を追加したものになります。WS-SC V1.3でWS-RM V1.1を使用するよう更新され策定されたのがWS-I RSP(Reliable Secure Profile)です。RSP1.0はWS-I BasicProfile1.2および2.0、WS-I BasicSecurityProfile1.0および1.1にWS-RM1.1、WS-SC1.3の仕様を追加したものになります。・WS-I BasicProfileWS-I Basic Profile1.2はWS-Addressingに加えてSOAP MTOM(MessageTransmissionOptimizationMechanism)およびXOP(XML-binary Optimized Packaging)も対象となっています。MTOMとXOPは添付ファイルに関して規定しています。SOAP1.2を対象としているのがWS-I BasicProfile2.0になります。

8

WAS V7 W/S

# 8



WAS V7 W/S

登場の背景

インターネットを利用したB2Bにおける高信頼性の必要性

WS-I RSPが求める信頼性

メッセージ配信保証

ネットワークの信頼性は各社で異なる

回線速度が速いとは限らない

重複排除

課金処理では必須

順序性

セキュリティ

WS-I RSPの信頼性

A社システム

C社システム

D社システム

インターネット

WS-ReliableMessaging

WS-SecureConversation

WS-I RSPの登場背景には「インターネットを利用したB2Bにおける高信頼性の必要性」があります。

信頼性としては以下の内容が挙げられます。

・メッセージ配信保証：複数の会社を相手としたB2Bの場合、ネットワークの信頼性は各社で異なり回線速度が速いとは限りません。メッセージが確実に配信されたことを保証する必要があります。

・重複排除：処理内容が課金処理であった場合、問題発生時の単純な再試行による2重更新処理というのは避けなければなりません。

・順序性：処理内容によっては順序性が必要なケースがあります。

・セキュリティ：Webサービス通信をセキュアに実行する必要があります。これらの信頼性を満たすための仕様として登場したのが"WS-ReliableMessaging"と"WS-SecureConversation"です。各仕様に対してインターオペラビリティ（相互運用性）の観点から制約を設け規定したプロファイルがWS-I RSPになります。

9

# 9



WAS V7 W/SWAS V7 W/SWAS V7 W/SWAS V7 W/S

高信頼性Webサービス～WS-ReliableMessaging～

Webサービス通信の信頼性を高める「WS-ReliableMessaging(WS-RM)」について説明します。

10

WAS V7 W/S

# 10



WAS V7 W/SWS-RM登場の背景

システムＡシステムＢ

システムＡシステムＢ

Webサービス・リクエスター

Webサービス・プロバイダー

SOAP/HTTP

SOAP/JMS

SOAP/HTTP

SOAP/JMS



既存技術で信頼性を確保する際の問題点

update

update

メッセージ転送はMOM製品が保証

1UOW

メッセージの処理をグローバルトランザクションで実施すればメッセージロス、2重更新はない

エラー発生時・・・• リクエスター側に再試行の仕組みが必要• プロバイダー側に2重更新を防ぐ仕組みが必要

SOAP/JMSを使用したい・・• SOAP/JMSのサポート（インターオペラビリティなし）• MOM製品(WMQなど)の統一

開発コスト高

共通ソフトウェア使用の制約

WS-RM登場の背景として、既存技術で信頼性を確保しようとした場合の問題点について触れてみます。

まずは、SOAP/HTTPの場合です。Webサービス・プロバイダーではデータベースなどのリソース更新処理を実行していて2重更新は防ぐ必要があるとします。このようなケースで、Webサービス・リクエスターがエラーを受け取った場合、リクエスター側には再試行の仕組みが必要になります。しかしながら、エラーの発生したタイミングがリソース更新前なのか後なのかはエラー内容からだけでは判断できません。2重更新を防ぐための仕組みが必要になり、最終的には開発コストが高くなるという問題を抱えることになります。

SOAP/JMSの場合、メッセージ転送はMOM(Message Oriented Middleware)製品によって保証されます。また、プロバイダー側でメッセージのGETとリソース更新処理をグローバル・トランザクション・スコープ内で実行すればメッセージ・ロスや2重更新を防ぐことができます。しかしながら、MOM製品を使用するという時点でMOM製品を統一しなければならないという制約がでてきます。また、SOAP/JMSはインターオペラビリティが保証されていないというデメリットがあります。

各々のケースにおいて、再試行の仕組み、2重更新を防ぐ対策、インターオペラビリティという観点での問題を抱えており、これらの問題を解決すべく登場したのがWS-RMです。

11

WAS V7 W/S

# 11



WAS V7 W/SWS-RM(Web Services Reliable Messaging)とは

Webサービスで信頼性の高いメッセージ送受信を行うための仕組み

SOAP/HTTPをベースとした高信頼性を実現するためのプロトコルを規定

RM SourceとRM Destinationが確実なSOAP/HTTPのメッセージ配信を行う

アプリケーションで再試行処理のコーディングは必要なし

受信済みのメッセージはRM Destinationが削除

メッセージはRM SoueceとRM Destinationで保管される

WS-I RSPによるインターオペラビリティの確保

WS.invoke()

RM Sourceメッセージ送信

RM Destinationメッセージ受信

invoke()

メッセージ送信を委譲 RM Destinationからメッセージを受信

ＣｒｅａｔｅSequence

WS-RMプロトコルによるメッセージ配信保証

ＣｒｅａｔｅSequenceResponseSequence

SequenceAcknowledgement

Webサービス・リクエスター・アプリ

Webサービス・プロバイダー・アプリ

server1 server2

Web Services Reliable Messaging(WS-RM)はWebサービスで信頼性の高いメッセージ送受信を行うための仕組みを規定したOASISの標準仕様です。2005年2月にV1.0、2007年6月にV1.1がリリースされ、WAS V7ではV1.0/1.1の両方をサポートしています。

○OASIS Web Services Reliable Messaging http://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.htmlWS-RMではSOAP/HTTPをベースとした高信頼性を実現するためのプロトコルを規定しています。

基本的な仕組みとして、Webサービス・リクエスター・アプリケーションがWebサービス呼び出しを実行すると、RM Sourceがメッセージ送信を委譲します。メッセージ受信についても同様で、アプリケーションの代わりにRM Destinationがメッセージを受信し、Webサービス・プロバイダー・アプリケーションのメッセージを渡します。

WS-RMプロトコルの規定に従った信頼性の高いメッセージ配信はRM SourceとRM Destinationの間で行われます。Webサービス・アプリケーションでは、例外発生時の再試行処理のコーディングは必要なく、また、一度受信されたメッセージはRM Destinationが削除するので2重更新の心配はありません。また、メッセージはRM SourceとRM Destinationの両方で保管されるため、設定によりますが、障害時のメッセージ・ロスもありません。

WS-I RSP(Reliable Secure Profile)によってインターオペラビリティも確保されています。

12

WAS V7 W/S

# 12



WAS V7 W/SWS-RMの基本動作－非同期型片方向－

リクエスト1

リクエスター(RM Source)

プロバイダー(RM Destination)

リクエスト1の送達確認

リクエスト2障害

リクエスト2


リクエストに対して、WS-RMのメッセージで送達確認(Ack)が返される送達確認が返されないリクエストは自動で再送信重複メッセージはRM Destinationで削除

RM Sourceによるリクエスト送信はアプリケーションとは別スレッド

リクエスト2 ×削除

WS-RMの基本動作について、非同期型片方向を例に説明します。

[リクエスト１]Webサービス・リクエスターがWebサービス呼び出しを実行すると、アプリケーションが実行されているスレッドとは別スレッドでRM Sourceがリクエスト送信を行います。WS-RMのプロトコルでは、リクエストに対して送達確認(Ack)が返ってくると正常に処理が完了したことになります。

[リクエスト２]リクエストの送信中にネットワーク障害などが発生し、リクエストがRM Destinationに届かないとします。RM Sourceは一定の間隔で送達確認が返されないリクエストを自動的に再送信します。

リクエスト２をRM Destinationが受信し、送達確認をRM Sourceが受け取る前に、RM Sourceがリクエスト２の再送信を実行したとします。RM Destinationはリクエスト２を既に受信し、Webサービス・プロバイダーに渡したことを記録しているので、重複メッセージとなるリクエスト２は削除します。

13

WAS V7 W/S

# 13



WAS V7 W/SWS-RMの基本動作－同期型、非同期型双方向－

正常時正常時

リクエスト1


レスポンス1

レスポンス1の送達確認



リクエスト1



レスポンス1

レスポンス1の送達確認

障害

リクエスト1

障害

レスポンス1

障害時障害時


リクエストとレスポンスの両方に対して、送達確認(Ack)が返される送達確認が返されないリクエストとレスポンスは再送信重複メッセージは削除

同期型、非同期型双方向のWebサービス呼び出しのケースを説明します。前ページの非同期型片方向を組み合わせた形でリクエストとレスポンスの両方に対して送達確認(Ack)が返されます。非同期型片方向と同様に、送達確認が返されないリクエストとレスポンスは再送信され、重複メッセージは削除されます。

14

WAS V7 W/S

# 14



WAS V7 W/Sメッセージは「シーケンス」の概念の元で送受信される

シーケンス：特定のRMSourceとRMDestination間で送受信されるメッセージ集合

特定のWebサービスで送受信されるメッセージ集合

シーケンス確立でRMSourceとRMDestinationのエンドポイントURLの組を情報として持つ

シーケンス確立後にメッセージ送信を行う

リクエスター（RM Source）リクエスター（RM Source）

プロバイダー（RM Destination）


CreateSequence

CreateSequenceResponse(Identifier=seq1)

リクエスト1(Identifier=seq1,Message#=1)

①シーケンスの確立①シーケンスの確立

リクエスト1送達確認(Identifier=seq1,Message#=1 )

②メッセージの送信SOAPヘッダーにSequence情報を含む②メッセージの送信SOAPヘッダーにSequence情報を含む


リクエスト2送達確認(Identifier=seq1,Message#=1~2 )

TerminateSequence(Identifier=seq1) ③シーケンスの終了③シーケンスの終了

：

TerminateSequenceResponse(Identifier=seq1)

WS-RMのメッセージは「シーケンス」という概念の元で送受信されています。「シーケンス」とは特定のRM SourceとRM Destinationの間で送受信されるメッセージ集合、つまり、特定のWebサービスで送受信されるメッセージ集合と言えます。WS-RMの仕様では、このシーケンスを明示的に区切り、シーケンス内で送受信されるメッセージ集合について確実な配信を行います。WASの実装では、デフォルトでアプリケーション起動後の最初のリクエスト実行時にシーケンス確立の処理が行われます。明示的にシーケンスを区切るにはアプリケーションでのコーディングが必要になります。コーディング方法の詳細については、以下リンクのInfoCenterをご参照ください。○WAS V7 InfoCenter 「Controlling WS-ReliableMessaging sequences programmatically」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/twbs_wsrm_prog_seq.html

WS-RMのプロトコルでは最初にシーケンスの確立を行い、RM SourceとRM Destinationの互いのエンドポイントURLの組を情報として保持します。この時にシーケンスIDが発行されます。確立されたシーケンスの元で、Webサービス呼び出しがRM SourceとRM Destinationの間で行われます。同一のWebサービス呼び出しについては、同じシーケンスの元で異なるメッセージIDが割り当てられることになります。すべてのリクエストにシーケンスIDとメッセージIDが付与され、管理されます。障害発生時にもシーケンスIDによって宛先にエンドポイントURLを認識し、メッセージIDによって配信に失敗したリクエストを判断し、リクエストの再送信を実行することができます。

15

WAS V7 W/S

# 15



WAS V7 W/S(参考)シーケンスの確立

http://abcd.makuhari.japan.ibm.com/HelloWSRMSrvWeb/HelloWSRMService

http://efgh.makuhari.japan.ibm.com/HelloWSRMSrvWeb/HelloWSRM

RM Source側エンドポイントURL

RM Destination側エンドポイントURL

http://efgh.makuhari.japan.ibm.com/HelloWSRMSrvWeb/HelloWSRM

urn:uuid:BB591B19CEBBA392711187699405920

シーケンスID

CreateSequenceメッセージ（新規シーケンス作成要求）

CreateSequenceResponseメッセージ（シーケンス作成応答）

シーケンスIDとRM Source/RM DestinationのエンドポイントURLが紐付けられるシーケンスIDとRM Source/RM DestinationのエンドポイントURLが紐付けられる

参考情報としてシーケンス確立時の送受信されるCreateSequenceメッセージとCreateSequenceResponseメッセージをご紹介します。SOAPヘッダーにWS-RMのプロトコルが含まれていることがわかります。CreateSequenceResponseメッセージではシーケンスIDが付与されていることがわかります。

16

WAS V7 W/S

# 16



WAS V7 W/S(参考)WS-Addressing

W3Cの仕様、Webサービスのアドレス情報を記述するための標準二つの概念を定義

End Point References(EPRs)

エンドポイントの場所を特定するためのURI（必須）+参照プロパティ＋参照パラメーター

Message Information ヘッダー

メッセージを転送するための情報

http://abcd.makuhari.japan.ibm……..

先に交換されているメッセージのMessageIdを含み、そのメッセージとの関連を示す

uuid:0123555RelatesTo

メッセージの意図を特定するための情報http://host/……Action

メッセージを一意に識別するためのURIuuid:0123555MessageID

応答メッセージが送信されるべきＥＰＲ（エンドポイントURI）

http://host/…

ReplyToヘッダー

エンドポイントのURIhttp://host/…..Toヘッダー

==

トランスポート・レベルに依存することなくメッセージを伝搬トランスポート・レベルに依存することなくメッセージを伝搬

参考情報として、WS-Addressingの情報をご紹介します。WS-Addressingは、それ自体単独で使用されることは稀ですが、WS-RMやWS-Transactionなどの他のWebサービス技術の中で暗黙的に使用されることの多い技術です。Webサービスのアドレス情報を記述するためのW3Cの標準仕様で、HTTPヘッダーの情報とは別にSOAPヘッダーにアドレス情報を含ませる場合に使用されます。

17

WAS V7 W/S

# 17



WAS V7 W/SMessagingEngine(ME)を使用したメッセージの永続化

1. アプリケーションからRM Sourceにメッセージ送信を委譲2. RM Sourceはメッセージを保管してから、制御をアプリケーションに戻す3. RM SourceはメッセージをRM Destinationに送信4. RM Destinationはメッセージを受信すると、保管してから送達確認を送信5. RM Destinationはアプリケーションにメッセージを送信

WS.invoke()

RM Sourceメッセージ送信

RM Destinationメッセージ受信

invoke()

RM Destinationからメッセージを受信

ＣｒｅａｔｅSequence

WS-RMプロトコルによるメッセージ配信保証

ＣｒｅａｔｅSequenceResponseSequence

SequenceAcknowledgement



server1 server2

QoS

WASではメッセージをメモリー、またはMessagingEngine(ME)に保管

別JVM上で稼動するMEを使用することでメッセージの永続化を実現

メッセージ送信を委譲

メモリーメモリー

QoS

WS-RMを使用する上で、WASではWebサービスのSOAPメッセージをローカルのメモリー上、もしくは別JVMで稼動するMessaging Engine(ME)に保持することができます。ME上にメッセージを保管することで、アプリケーション・サーバーの障害時にもメッセージを失うことなく永続化が可能です。

処理の遷移は以下になります。

１．Webサービス・リクエスター・アプリケーションでWebサービス呼び出しが実行されると、メッセージ送信はRM Sourceに委譲されます。２．RM SourceはSOAPメッセージをメモリー、もしくはMEに保管してから、制御をアプリケーションに戻します。

３．RM SourceはSOAPメッセージをRM Destinationに送信します。（この間はWS-RMプロトコルによるメッセージのやりとりが行われます）４．RM DestinationはSOAPメッセージを受信すると、メモリー、もしくはMEに保管してから送達確認を送信します。

５．RM DestinationはWebサービス・プロバイダー・アプリケーションにメッセージを送信します。

18

WAS V7 W/S

# 18



WAS V7 W/SWS-RMのQoSの設定

WASでは3つのレベルのQoSを提供

QoSの内容

①メッセージ、シーケンス情報の保管方法

②トランザクション・サポートの有無

非管理非パーシスタント

ローカル・メモリー上に情報を保持

トランザクション・サポート無し

サーバー障害時にメッセージ情報を失う

管理非パーシスタント

MEに情報を保持、情報を非同期にデータストアに保管

トランザクション・サポート有り

ME障害時にはメッセージ情報を失う

管理パーシスタント

MEに情報を保持、情報を同期的にデータストアに保管

トランザクション・サポート有り

ME障害時にもメッセージ情報を失わないDB

ME自体はJVM上で稼動

メッセージ永続化のためにデータストアとしてDBかファイルを指定

WASでは、WS-RMのQoS設定として３つのレベルを設けています。QoSで設定する内容は、①WS-RMのメッセージやシーケンス情報の保管方法と②トランザクション・サポートの有無の2点です。・非管理非パーシスタント

メッセージやシーケンス情報はJVMのメモリー上に保持するため、サーバー障害(JVM障害)時に情報を失い、メッセージのロスに繋がります。また、トランザクションをサポートしていません。

・管理非パーシスタント

メッセージやシーケンス情報をMEに保管し、MEのデータストアに対して非同期に永続化を実施します。サーバー障害時には情報を失いませんが、ME障害時に情報を失う可能性があります。（ME障害時にデータストアへ保管されていない情報を失います）トランザクションをサポートしています。

・管理パーシスタント

メッセージやシーケンス情報をMEに保管し、MEのデータストアに対して同期的に永続化を実施します。サーバー障害時、ME障害時の両方で情報を失うことはありません。トランザクションをサポートしています。

※以下、用語の使い方をまとめています。

非管理：メモリー上に情報を保持。トランザクション・サポート無し

管理：MEに情報を保持。トランザクション・サポート有り非パーシスタント：サーバー障害、もしくはME障害時に情報を失う可能性があります。パーシスタント：サーバー障害、ME障害時、共に情報を失うことはありません。

19

WAS V7 W/S

# 19



WAS V7 W/S（参考）管理非パーシスタントと管理パーシスタントの違い

MEの「メッセージの信頼性」が異なる

管理非パーシスタント：「高信頼性非パーシスタント」

MEはアプリケーションからメッセージの送信／受信要求を受け取ると、メッセージをキャッシュ・バッファに書き込んだ時点で、アプリケーションに制御を戻します。メッセージがある程度、キャッシュ・バッファに滞留した場合のみ書き込みます。

キャッシュ・バッファのサイズ指定可能です。

管理パーシスタント：「保障パーシスタント」（最も信頼性が高くメッセージのロスはなし）

MEはアプリケーションからメッセージの送信／受信要求を受け付けると、同期的にメッセージをデータ・ストアに挿入／削除します。書き込みがうまくいったことを確認してから、アプリケーションに制御を戻します。

共にMEの高可用性は別途考慮が必要

管理非パーシスタントと管理パーシスタントの違いを説明します。

共にメッセージやシーケンス情報をMEに保管するという点は同じですが、MEに設定する「メッセージの信頼性」のレベルが異なります。

管理非パーシスタントの信頼性は「高信頼性非パーシスタント」でMEのJVM上にある一定のメッセージが滞留した段階でデータストアにメッセージが保管されます。

管理パーシスタントの信頼性は「保障パーシスタント」でMEはメッセージの送受信と同期的にデータストアに情報を挿入/削除します。データストアへの書き込みが成功してからアプリケーションに制御を戻すため、データストアへの情報保管は確実に実行されます。

共にMEを使用する構成となるため、MEの高可用性については別途考慮が必要です。

20

WAS V7 W/S

# 20



WAS V7 W/Sトポロジー構成

シングルサーバー構成が対象

クラスター構成のサービスに適用するとアプリケーションが始動しない

アプリケーション・サーバー障害時に情報を損失

メッセージのロス

RM Destination


server1

RM Source


メモリー

シーケンス情報を別JVM上のMEで共用

クラスター構成が可能

全クラスターメンバーがMEからシーケンス情報を取得

サーバー障害時に情報を損失しない

他のクラスター・メンバーが処理を実施RM

Destination

RM Destination



Cluster

server1

server2

RM Source


WASProxyサーバー

ME

非管理非パーシスタント

管理非パーシスタント/管理パーシスタント

WS-RMを使用した場合のトポロジー構成について説明します。WS-RMのトポロジー構成はQoS設定によって画面に示すように異なります。・非管理非パーシスタント

シーケンスやメッセージの情報をメモリー上に保管する非管理非パーシスタントは、シングルサーバー構成を対象としており、クラスター構成を組むことができません。アプリケーション・サーバー障害時には情報を損失するので、メッセージのロスにも繋がります。最もシンプルな構成でネットワーク障害時のみに対応可能です。

・管理非パーシスタント/管理パーシスタントクラスター構成が可能で、シーケンスやメッセージ情報をMEで共用します。サーバー障害時にもMEに保管された情報によって他のクラスター・メンバーが処理を続行します。クラスター構成を組む場合、WS-RMプロトコルのメッセージを同一のアプリケーション・サーバー（クラスター・メンバー）に処理させるためには、Webサービス・リクエスターとWebサービス・プロバイダーの間にIHSなどのWebサーバーではなくWASのプロキシー・サーバーを配置する必要があります。同一シーケンスの情報を同じアプリケーション・サーバーに送信するアフィニティ機能をWebサーバーは持っていないためです。クラスター構成では、ネットワーク障害に加えてアプリケーション・サーバー障害にも対応できます。

21

WAS V7 W/S

# 21



WAS V7 W/Sトランザクション・サポート＜リクエスター側＞

リクエスター側

非同期型片方向のみトランザクション処理が可能（双方向はサポートされない）

MEへのメッセージのPUTがトランザクションスコープに含まれる

MEへのメッセージPUTが成功した段階でアプリケーションに制御が戻る

1UOW

Webサービス・リクエスター Webサービス・プロバイダー

トランザクションのコミットのタイミングでメッセージを送信

ut.begin()

update

invoke()

ut.commit()

RM Source RM Destination

設定方法

リクエスター側のコーディングでenableTransactionOnewayプロパティを"true"にセットする

Map rc = ((BindingProvider) port).getRequestContext();rc.put(com.ibm.websphere.webservices.Constants.ENABLE_TRAN_ONEWAY,new Boolean(true));

管理パーシスタント/管理非パーシスタントが対象

DB

server1

server2RequesterApp

ProviderApp

WS-RMを使用した場合のトランザクション・サポートについて説明します。まず、Webサービス・リクエスター側のトランザクション処理ですが、Webサービス呼び出しが非同期型片方向の場合のみサポートされています。双方向型の場合、応答メッセージの受信までをトランザクション処理に含めることはできませんのでサポートされていません。WS-RMの処理をトランザクショナルに実行したい場合、MEへのメッセージのPUT処理をトランザクション・スコープに含めることが可能です。トランザクションのコミット処理が完了したタイミングでメッセージの送信が実行されます。例えば、リクエスター側のアプリケーション処理にデータベース更新処理などが含まれている場合、データベース更新処理をMEへのメッセージのPUTを同一トランザクションの処理として実行することができます。MEのPUT処理に失敗した時に、データベース更新処理をロールバックすることが可能です。

・設定内容は以下の2点です。アプリケーション内でトランザクションの開始(begin)・終了(commit)処理を実行します。Webサービス・リクエスターのenableTransactionOnewayプロパティを"true"にセットします。

22

WAS V7 W/S

# 22



WAS V7 W/Sトランザクション・サポート＜プロバイダー側＞

プロバイダー側

非同期型片方向と双方向でトランザクション処理が可能

RM Destinationからアプリケーションへのメッセージのディスパッチがトランザクションスコープに含まれる

双方向ではトランザクションがコミットされてから応答メッセージが送信されます


RM Source RM Destination

設定方法

WS-RMポリシーで「送信順にメッセージを配信」にチェックする

*順序性を保つために、キューにメッセージが保留されるとパフォーマンスのオーバーヘッドとなる

1UOW

管理パーシスタント/管理非パーシスタントが対象

RequesterApp ProviderAppserver1

server2

DB

Webサービス・プロバイダー側のトランザクション処理について説明します。プロバイダー側では非同期型片方向と双方向の両方でトランザクション処理が可能です。

RM Destinationからアプリケーションへのメッセージのディスパッチがトランザクション・スコープに含まれます。

双方向（同期型）の処理ではトランザクションがコミットされてから応答メッセージが送信されます。

・設定方法

WS-RMポリシーの設定で「送信順にメッセージを配信」にチェックをつけます。（もしくはwsadminツールでinOrderDeliveryをtrueに設定します）順序性を保つために、キューのメッセージが保留されるのでパフォーマンスのオーバーヘッドとなることに注意してください。

23

WAS V7 W/S

# 23



WAS V7 W/S（参考）その他考慮点

順序性

WS-RMポリシーで「送信順にメッセージを配信」にチェックをつける

WS-ATとの関係

QoSでMEを使用する場合WS-ATは使用できない

MEを使用しない非管理対象ではWS-ATを使用可能

1UOW


ut.begin()

invoke()

ut.commit()

RM Source RM Destination メモリー

メモリー

DB DBupdate update

×

WS-ATのトランザクション・スコープ

×WS-AT&WS-RMプロトコル

その他の考慮点として以下の2点を説明します。

・順序性

WS-RMでRM Sourceが処理した順番通りにRM Destinationに処理を実行させたい場合に使用します。

・WS-ATとの関係QoS設定でMEを使用する場合(管理パーシスタント/管理非パーシスタント)は、WS-ATを併用することはできません。

WS-ATを使用するというのは画面の絵に示すように、Webサービス・リクエスターからWebサービス・プロバイダーまでの全ての処理をトランザクション・スコープに含めるということになります。

MEを使用しない非管理非パーシスタントの構成(シングルサーバー構成になります)ではWS-ATを併用することができます。○InfoCenter 「Providing transactional recoverable messaging through WS-ReliableMessaging」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/twbs_wsrm_trans.html

24

WAS V7 W/S

# 24



WAS V7 W/SWS-RMの運用①

管理コンソールによるシーケンスのモニタリング

RM Destinationが保持するシーケンス情報

RM Sourceが保持するシーケンス情報

RM Sourceからの送信でエラーが発生していることを示す

WS-RMの運用として、WASの管理コンソールではWS-RMのシーケンス情報をモニタリングすることができます。

ナビゲーション・ツリーから[サービス]＞[高信頼性メッセージングの状態]を選択すると画面のようなページが表示されます。

・メッセージストア：WS-RMで使用するMEの状態を確認します・インバウンド・シーケンス：RM Destinationが保持するシーケンス情報を確認します・アウトバウンド・シーケンス：RM Sourceが保持するシーケンス情報を確認します

送信が完了できていないメッセージがあると画面に示すような警告マークが表示されエラーが発生していることを示します。

25

WAS V7 W/S

# 25



WAS V7 W/SWS-RMの運用②

トラブルシューティングは管理コンソールから可能

障害が回復すれば処理は正常に実施される

RM Sourceで保持するメッセージ数

送信済み＋保持するメッセージ数

エラー情報

WS-RMの処理でエラーが発生した場合のトラブルシューティングは管理コンソールから行うことができます。

例としてアウトバウンドシーケンスのページを画面に示します。

シーケンスごとに、シーケンスID、アプリケーション名、エンドポイントURL、RM Sourceで保持している（未送信の）メッセージ数、送信済みメッセージ（送信済み＋保持するメッセージ）数、エラー情報、状況を示します。

シーケンスIDを選択すると、保持しているメッセージのメッセージ番号とメッセージ内容を確認することができます。エラーが発生した場合などで、保持しているメッセージの送信をキャンセルする場合は、この画面で削除します。

26

WAS V7 W/S

# 26



WAS V7 W/S（参考）WS-RMの運用③

新規シーケンスを作成して未送信メッセージを割り振る

ZIPファイルでエクスポート（中身はテキスト形式）

エラーが発生している場合、未送信メッセージ（保持しているメッセージ）をZIP形式のファイルでエクスポートすることができます。（"未送信メッセージのエクスポート"ボタン）また、現在のシーケンスでの送信を止め、新規シーケンスを作成して未送信メッセージを割り振るということも可能です。（"メッセージの再割り振り"ボタン）

27

# 27



WAS V7 W/SWAS V7 W/SWAS V7 W/SWAS V7 W/S

会話型Webサービス・セキュリティ～WS-SecureConversation～

会話型のWebサービス・セキュリティとして「WS-SecureConversation(WS-SC)」について説明します。

まずは、Webサービス・セキュリティの説明を簡単に行い、その後にWS-SecureConversationの説明となります。

28

WAS V7 W/S

# 28



WAS V7 W/SWebサービスにおけるセキュリティ

Webサービスのセキュリティを確保するためには以下の方法がある

トランスポート・レベル

SSL（HTTPS）通信とHTTPベーシック認証によるアクセス制御

メッセージ・レベル

SOAPメッセージの全体または一部へのデジタル署名の付加/メッセージ自体の暗号化

Webサービスアプリケーション

Webサービスリクエスター SSL通信

データは全て暗号化

SOAP

平文

SOAP

平文

Webサービスリクエスター

SOAP

平文

SOAP

暗号化

Webサービスアプリケーション

SOAP

平文

SSLは２地点間のみの仕組み

SOAP/HTTPのみの環境でしか利用できない

マシン間でのセキュリティ

トランスポート層に非依存

メッセージ・レベルのセキュリティ

サービス単位のセキュリティ

SOAPメッセージをセキュアに扱うための仕様としてWS-Securityが策定

Webサービスを使用する環境において、セキュリティを確保するためには、「トランスポート・レベルのセキュリティ」と「メッセージ・レベルのセキュリティ」の２つの方法が挙げられます。

・トランスポート・レベルのセキュリティ

SSL(HTTPS)通信とHTTPベーシック認証によるアクセス制御を行う従来の方法です。SSLはマシン間の通信データを全て暗号化し、セキュリティを確保しています。2地点間のみの仕組みであること、SOAP/HTTPのみの環境でしか利用できないといった特徴があります。・メッセージ・レベルのセキュリティ

SOAPメッセージの全体、または一部に対してデジタル署名の付加やメッセージの暗号化を行います。このSOAPメッセージをセキュアに扱うための仕様として作成されたのがWS-Securityです。

Webサービスの考えをベースとしていることから、トランスポート層に依存せず、また、サービス単位でセキュリティをかけることができます。更に、細かくメッセージ・レベルでのセキュリティも可能です。

29

WAS V7 W/S

# 29



WAS V7 W/SWS-Securityとは

WS-Security

SOAPメッセージングのセキュリティ強化仕様

OASISでの仕様策定

2004年4月 v1.0リリース / 2006年2月 v1.1リリース

以下のセキュリティ要件に対応

認証(Authentication)

サービスを使用できるクライアントか？

セキュリティ・トークンによる認証

完全性(Integrity)

メッセージが不正に改ざんされていないか？

XML署名とセキュリティ・トークンの組み合わせ

複数のメッセージ要素に対して、柔軟に署名が可能

機密性(Confidentiality)

メッセージの盗聴はされていないか？

XML暗号化とセキュリティ・トークンの組み合わせ

複数のメッセージ要素に対して、柔軟に暗号化が可能

WS-Securityの目標は、アプリケーションがセキュアなSOAPメッセージ交換を行えるようにすることです。

SOAPメッセージにおける、セキュリティ・トークンの受け渡し、メッセージの完全性、およびメッセージの機密性の３つの主要なメカニズムを提供します。

これらのメカニズムは単独で使用することも、統合した手法で使用することもできます。（メッセージの署名と暗号化を行い、署名と暗号化で使用される鍵に関連付けられたセキュリティトークン階層を提供するなど）また、SOAP仕様のactor/role要素を使用して、複数のセキュリティ・モデルを使用して別々のメッセージ要素に対して署名・暗号化をかけることや、同一のメッセージ要素に対して署名・暗号化を同時にかけるなど柔軟な設計が可能です。

WS-Securityは明示的な固定されたセキュリティプロトコルについて記述しているわけではありません。将来的なスタンダードへの対応も見据え、拡張可能な形のフレームワークとして設計されています。

30

WAS V7 W/S

# 30



WAS V7 W/S（参考）セキュリティ・トークン

セキュリティ・トークンはSOAPメッセージを保護するためのものとしてWS-Securityで定義

ID、鍵、役割等のclaims（申告）を含む

セキュリティ・ヘッダとしてSOAPメッセージに組み込まれる

WS-Securityでサポートするセキュリティ・トークン

UsernameToken

ユーザー名とパスワードをテキスト形式で含む

SSLとの併用が必要

署名なしセキュリティ・トークン

BinarySecurityToken

X.509証明書、Kerberos V5チケットなど

デジタル署名、暗号化で参照される鍵を含む

署名付きセキュリティ・トークン

SecurityToken : A security token represents a collection (one or more) of claims.Claim – A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege,

290 capability, etc).

Security TokenBinarySecurityToken

X.509証明書Kerberosチケット

UsernameToken

第3の機関によってBinary Security Tokenは保証されている

セキュリティ・トークンは内部にリクエスターのIDや鍵情報、役割情報などのclaims（申告）とよばれる認証の為の情報を含みます。

WS-Securityはこのセキュリティ・トークンをSOAPヘッダーに組み込む方法を定義しています。WS-Security1.0/1.1ではサポートされるセキュリティ・トークンとして基本認証に使用されるUsernameTokenおよび任意のバイナリ・セキュリティ・トークンがサポートされます。バイナリー・セキュリティ・トークンは証明書を含み署名が施されたトークンのため、署名付きセキュリティ・トークンとして分類されます。一方でUsernameTokenはユーザー名とパスワードのみを含む単独なトークンです。そのままではネットワーク上にこれらのトークンの値が平文で流れてしまうためSSL等と併用する必要があります。また、リプレイ攻撃への対策のため、nonceおよびタイムスタンプを使用してダイジェスト化を行うことが推奨されます。バイナリー・セキュリティ・トークンが含む証明書の公開鍵をデジタル署名・暗号化に利用することができます。

31

WAS V7 W/S

# 31



WAS V7 W/S(参考)XMLデジタル署名概要

WS-Securityのデジタル署名はXML署名がベースXML署名はXMLにデジタル署名を埋め込むための標準化仕様

平文からハッシュ関数を使用してメッセージダイジェストを生成

① 署名対象データを正規化した上で、ダイジェスト値を計算する

② ①のダイジェスト値を子要素としてXML署名情報要素(SignedInfo)に入れ、さらにその署名情報要素に対して署名値を計算する

データ

ダイジェスト

ダイジェスト

AさんのKeyAさん

送信！

Bさん

SOAP

データ

ダイジェスト

ダイジェスト

AさんのKey

計算ダイジェスト

復号化計算

計算

ダイジェスト

比較 OK！

計算

ダイジェスト

ダイジェスト

比較

復号化

OK！

SOAP

WS-Securityのデジタル署名はXML署名(http://www.w3.org/Signature/)をベースとする仕様です。

XML署名はXMLにデジタル署名を埋め込むための仕様で、公開鍵暗号化方式をベースにした署名方式です。

以下の流れで署名対象のデータに対して署名を行います。

①署名対象データを正規化した上で、ダイジェスト値を計算し、署名情報要素(SignedInfo)に格納

※XML文書では内容が同じであってもXML構文に挿入された空白文字や改行などが任意に加わると表現が異なり、結果としてダイジェスト値が変わり、署名値が異なってしまうから。

②署名情報要素に対して正規化を行った後に、指定した署名アルゴリズムで署名値(SignatureValue)を計算し文書内に含める。

検証時の流れは署名時の逆に

①署名情報要素(SignedInfo)内のダイジェスト値を検証②署名情報要素に対して計算された暗号化署名値を検証

オプションとしてKeyInfo要素に署名検証のための鍵情報を含めることができます。

32

WAS V7 W/S

# 32



WAS V7 W/S(参考)XML暗号概要

データを暗号化しXML文書で表す標準仕様

任意のXML文書、XML要素、XML要素の内容の暗号が可能

XML暗号仕様

W3C「XML Encryption WG」

http://www.w3.org/Encryption/2001/

WS-Securityの暗号化

XML暗号に基づく

SOAPメッセージ(header, body)の全部または一部を暗号化

データの暗号化そのものは、共通鍵暗号方式を使用共通鍵は事前に送受信者で共有、または、公開鍵で暗号化してメッセージに含めて送付

Aさん

送信！

Bさん

SOAP

暗号化したデータ

元のデータ暗号化

SOAP

暗号化したデータ

元のデータ復号化

暗号化Key情報暗号化Key情報

WS-Securityの暗号化はXML暗号(http://www.w3.org/Encryption/2001/)をベースとする仕様です。

XML暗号は任意のXML文書、要素、値を暗号化してXML文書で表すための仕様で、公開鍵暗号化方式をベースにすることができます。

公開鍵暗号化方式を使用する場合、以下の流れで対象データに対して暗号化を行います。

①対象データを共通鍵で暗号化

②共通鍵をプロバイダーの公開鍵で暗号化

③リクエストメッセージに暗号化した共通鍵を含め、送信

検証時の流れは、暗号化時の逆に

①プロバイダーは秘密鍵で共通鍵を復号化

②対象データを共通鍵で復号化

共通鍵を何らかの方法で事前に渡すことが可能な場合、公開鍵を間に挟まずに共通鍵のみでデータの暗号化・復号化が可能です。

33

WAS V7 W/S

# 33



WAS V7 W/SWS-Securityのインターオペラビリティ

WS-IよりWS-Securityの相互運用に関する多数のプロファイルが策定

WS-Securityの基本動作に関するプロファイル

Basic Security Profile

WS-Securityで使用するセキュリティ・トークンに関するプロファイル

Username Token Profile/X.509 Token Profile/Kerberos Token Profile

WS-RMとWS-SC、WS-Trustに関するプロファイル

Reliable Secure Profile

WS-I Basic Security Profile 1.0



WS-Security 1.0

Username Token Profile

X.509 Token Profile

WS-I Basic Security Profile 1.1 WS-Security 1.1

WS-I Reliable Secure Profile 1.0 WS-Trust 1.3

WS-SecureConversation 1.3

WS-ReliableMessaging 1.1

Kerberos Token Profile

SAML Token Profile

REL Token Profile

Newv7

異なるベンダー実装間でWebサービスによる接続を行う際には、関連する各仕様の厳密でない定義部分が相互接続性に影響を与える可能性があります。WSDLやSOAP仕様においては標準化団体WS-IのBasicProfileによって相互接続のための制約が提言されています。WS-Securityにおいては同団体によってBasicSecurityProfileが規定されています。WS-Securityで使用されるセキュリティ・トークンについては別にプロファイルが作成されており、Username Token Profile / X.509 Token Profile / Kerberos Token Profileがあります。Kerberos Token ProfileのサポートはWAS V7からの新機能です。BasicSecurityProfileではSAML Token ProfileやREL(Rights Expression Language)Token Profileについて記述されていますが、WAS V7ではサポートされておりません。WS-Security V1.0に関して規定されたプロファイルがBasic Security Profile V1.0、 WS-Security V1.1に関して規定されたプロファイルがBasic Security Profile V1.1になります。Basic Security Profile 1.1にWS-Trust V1.3/WS-SecureConversation V1.3/WS-ReliableMessaging V1.3を使用する上での相互接続性の観点での制約を規定したものがReliable Secure Profileになります。(2008/10現在 V1.0がWorkingGroupDraftのステータスです)

34

WAS V7 W/S

# 34



WAS V7 W/SWS-Secure Conversation/WS-Trust

WS-SecureConversation(WS-SC)

複数のメッセージ交換に渡るセキュリティ提供方法を定義

セキュリティ・コンテキストの作成・共有

WS-Trust

セキュリティ・トークンの発行および交換方法を定義

SCT：セキュリティ・コンテキスト・トークン

+WS-Security

暗号化 SOAP暗号化復号化

復号化

リクエスタープロバイダー

SCT作成要求

SOAP+WS-SC

SOAP+WS-SC


暗号化

復号化

復号化

復号化

復号化

暗号化

暗号化

暗号化

暗号化

暗号化

復号化

復号化SCT作成応答

メッセージレベルの保護を目的とした、認証、署名および暗号化の方法を定義

WS-SecurityWS-Security WS-SCWS-SC

複数のメッセージ交換に渡るセキュリティ提供方法を定義

拡張

WS-TrustWS-Trust

*図では例として暗号化を実施しています。

公開鍵暗号方式を使用した署名、暗号化を要求/応答の度に実行

WS-SecurityはSOAPメッセージ交換をセキュアに行うことを目的とし、認証、署名および暗号化の方法を定義していますが、将来的な拡張を見据えた仕様としていることから複数のメッセージ交換を考慮したものではありません。複数のメッセージ交換が発生すると認証、および公開鍵暗号方式を使用した署名、暗号化が要求/応答処理の度に実行され、CPU負荷を高める要因になります。

WS-SecureConversation(WS-SC)では、そのような問題を解消すべくWS-Securityを拡張した複数メッセージ交換に渡るセキュリティ提供方法を定義しています。WS-SCがセキュリティ・コンテキストの作成・共有方法について定義しているのに対して、WS-Trustではセキュリティ・トークンの発行および交換方法を定義した仕様になります。別仕様として規定されていますが、WS-SCを使用する上でWS-Trustは必須機能です。WS-SecureConversation、WS-Trustは共にOASISで策定された標準仕様です。2007年3月にV1.3がリリースされています。

35

WAS V7 W/S

# 35



WAS V7 W/S

セキュリティ・コンテキスト

リクエスター、プロバイダー間の認証を確立するために使用した鍵や関連プロパティ

WS-SCの通信関係が存続している間、２者間で共有される

セキュリティ・コンテキスト・トークンとはセキュリティ・コンテキストを含む、セキュリティ・トークン

WS-SCの仕組み① セキュリティ・コンテキスト・トークンの生成

RequestSecurityToken(RST)リクエスタープロバイダー

RequestSecurityTokenResponse(RSTR)

WS-Securityランタイム

トラスト・サービス

RSTを受けて、セキュリティ・コンテキスト・トークン(SCT)を作成


SCTSCTはメモリー上にキャッシュ

SCT

共通秘密鍵

WS-SCの仕組みの前半としてセキュリティ・コンテキスト・トークン(SCT)の生成について説明します。セキュリティ・コンテキストとは、リクエスターとプロバイダー間の認証を確立するために使用した鍵や関連プロパティを示します。WS-SCの通信関係が存続している間、２者間で共有される共通秘密鍵のようなものです。※SOAPメッセージ内ではセキュリティ・コンテキストをと表します。セキュリティ・コンテキスト。トークン(SCT)とは、セキュリティ・コンテキストを含んだセキュリティ・トークンを意味します。

WS-SCは最初にSCTを生成し、リクエスターとプロバイダーの両者間で共有するところからConversationが開始されます。WS-SCの最初の処理シーケンスを説明します。①リクエスターからRequestSecurityTokenメッセージ（SOAPメッセージ）が送信されます。②RSTを受けて、プロバイダーのトラスト・サービスはセキュリティ・コンテキスト・トークン(SCT)を生成します。*③プロバイダーは生成したSCTをリクエスターに送信します。リクエスターとプロバイダーの両者間でSCTは一定期間キャッシュされます。

WS-SCの最初に行われるSCTの受け渡し（①と③）処理はWS-Securityの公開鍵暗号方式を使用し、セキュリティを確保します。

*SCTの生成はWS-Trustで規定されており、通常は第３者機関に委ねられるようです。WASの実装ではRSTを受けたWASのランタイム上のトラスト・サービスがSCTを発行します。WASにおけるWS-Trustのサポート状況については未サポート部分がいくつかありますので、詳細については以下リンクのInfoCenterの記述をご参照ください。○InfoCenter 「Web Services Secure Conversation」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/cwbs_wssecureconv.html

36

WAS V7 W/S

# 36



WAS V7 W/SWS-SCの仕組み② 派生鍵

セキュリティ・コンテキスト・トークンから派生した鍵を使用してアプリケーション・メッセージにセキュリティをかける

RequestSecurityToken(RST)リクエスタープロバイダー

暗号化

暗号化

復号化RequestSecurityTokenResponse(RSTR)


トラスト・サービス

復号化

暗号化

派生鍵派生鍵

+WS-SC

SCTSCT

SOAP

+WS-SC

SOAP

復号化

暗号化復号化

復号化

復号化暗号化

暗号化


アプリケーション・メッセージはSCTから派生した派生鍵を使用して暗号化・署名を実行

WS-Trustプロトコル(SCTの受け渡し)はWS-Securityの公開鍵暗号方式

対称鍵暗号方式によるパフォーマンスの向上

WS-SCの仕組みについて前ページのセキュリティ・コンテキスト・トークン(SCT)の受け渡しに続いて説明します。

リクエスターとプロバイダーの両者間でSCTを共有し、次の段階から通常の要求/応答処理が行われます。

WS-Securityでは公開鍵暗号方式が使用されますが、WS-SCではSCTから派生した派生鍵を使用した対称鍵暗号方式を使用してメッセージの暗号化・署名が実行されます。公開鍵暗号方式と比較して対称鍵暗号方式は負荷が低く、複数メッセージ交換を行うケースではパフォーマンスの向上が見込めます。

派生鍵のしくみについては次ページで詳細に説明しています。

37

WAS V7 W/S

# 37



WAS V7 W/S（参考）派生鍵

元の鍵に対してハッシュ関数でハッシュを行い派生した鍵

WS-SCではセキュリティ・コンテキスト・トークンを元に派生鍵を作成

メッセージごとに異なる派生鍵を作成 ⇒鍵の堅牢性を高める

WASでは以下の形式で署名と暗号化が実施される

WS-Addressingヘッダー、タイムスタンプ、本文には派生鍵を使用してHMACアルゴリズムで署名

署名エレメント、本文には、AESアルゴリズムを使用した派生鍵で暗号化

uuid:680A09B552E9898E141189654995452

16iY6Pc4emqRf3f0n+7JZxodf9JCjdPX0PorJPYgUXER2JpddtNbATZ8WPtKduiB8SHXxZpcS+Ztinn4eSHQHAkDX76x8pHuwlzHtc8Ncz0zLDsQOaXB7IZ+HV6cB/UUV/+3tAwMmEriWuTp/TMKN7/RUS9eiuFeWJD7IR6OyfTfg=

WS-Securityヘッダーにエレメントが含まれる

鍵ID *AES(Advanced Encryption Standard):対称暗号方式

LengthとNonceを使用して、メッセージごとに異なる派生鍵を使用

SCT

派生鍵

Length,Nonce

ハッシュ

派生鍵とは元の鍵に対してハッシュダイジェスト関数でハッシュを行い派生した鍵です。WS-SCではセキュリティ・コンテキスト・トークンを元にハッシュダイジェスト関数などを使用して派生鍵を生成します。

ハッシュ関数にはLengthとNonceの値が使用されますが、Webサービス・プロバイダーにLengthとNonceの情報を渡すことで、Webサービス・プロバイダー側も同じ派生鍵を生成し、復号化することが可能になります。

また、ハッシュ関数に使用されるLengthとNonceは毎回異なる値が使用されるので、派生鍵もメッセージごとに異なるものが使用されることで鍵の安全性が高まります。

WASでは派生鍵を使用した署名にHMACアルゴリズムを使用します。HMACはハッシュ関数を共有秘密鍵と組み合わせて使用します。ハッシュの計算、署名の検証に共有秘密鍵を使用するので共有秘密鍵を保持していないと検証ができません。

派生鍵を使用した暗号化にはAESアルゴリズム(対称暗号方式)が使用されます。

38

WAS V7 W/S

# 38



WAS V7 W/SWASにおけるWS-SCのスコープ

同一リクエスターからのサービス呼び出しは同じsecure conversationを使用

同じセキュリティ・コンテキスト・トークン(SCT)を使用

リクエスター・アプリケーションA

リクエスター・アプリケーションB

Service 1

instance

instance

instance

instance

instance

Secured conversation 1

Secured conversation 2

SCT

SCT

SCT

SCT

WASにおけるWS-SCのスコープ、つまり同じセキュリティ・コンテキスト・トークンが使用される範囲について説明します。

画面の絵に示すように、同一リクエスターからの特定のサービス呼び出しは同じsecure conversationを使用します。詳細につきましては、以下のInfoCenterの記述をご参照ください。○InfoCenter 「Scoping of Web Services Secure Conversation」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/cwbs_wsscscoping.html

39

WAS V7 W/S

# 39



WAS V7 W/SWS-RMにWS-SCを使用する

WS-RMで、シーケンス上のメッセージ送受信にWS-SCを使用可能

WS-RMシーケンスはSCTの派生鍵によって署名、暗号化

SCTにWS-RMのシーケンスをスコープとして宣言する

リクエスター（RM Source）リクエスター（RM Source）



CreateSequence

CreateSequenceResponse(Identifier=seq1)


リクエスト1送達確認(Identifier=seq1,Message#=1 )


リクエスト2送達確認(Identifier=seq1,Message#=1~2 )：

RequestSecurityTokenRequestSecurityTokenResponse

SCTの派生鍵によって対称鍵暗号方式で署名と暗号化

WS-RMをセキュアに、低負荷で実行

WS-I Reliable Secure Profileの目指すところ

＋

インターオペラビリティ

WS-I Reliable Secure Profile(RSP)でWS-SCとWS-RMを規定しているのは、WS-RMを使用した際の複数メッセージ交換をセキュアに、且つ、低負荷で実行することを目的としています。

WS-RMにWS-SCを使用すると、WS-RMのシーケンスにおけるメッセージ交換はセキュリティ・コンテキスト・トークン(SCT)の派生鍵によって署名・暗号化されます。

40

WAS V7 W/S

# 40



WAS V7 W/S(参考)WS-SCクライアントのキャッシュ

リクエスターとプロバイダーの両方でセキュリティ・コンテキスト・トークンがキャッシュされる

メモリー上にキャッシュ

クラスター環境では複製ドメインを使用して共用可能（デフォルト・オフ）

WS-SCではリクエスターとプロバイダーの両方でセキュリティ・コンテキスト・トークン(SCT)がJVMのメモリー上にキャッシュされます。WASでは管理コンソールからキャッシュに関する設定を行うことができます。

また、クラスター環境においては複製ドメインを使用することによって、クラスター・メンバー内でSCTを複製し共用することができます。詳細情報につきましては、以下リンクのInfoCenterの記述をご参照ください。○InfoCenter 「Secure conversation client cache」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/cwbs_wssecureconvclientcache.html○InfoCenter 「Enable distributed cache and session affinity when using Secure Conversation」http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/twbs_enablesecconvcluster.html

41

# 41



WAS V7 W/SWAS V7 W/SWebサービス・ポリシー WAS V7 W/SWAS V7 W/S

42

WAS V7 W/S

# 42



WAS V7 W/SWS-*とポリシーの関係

WebサービスにおけるQoSの設定をポリシー(ルール)として独立に記述

WS-*の設定をDeploymentDescripterではなく、ポリシーに設定

作成したポリシーをWebサービス・アプリケーションに関連付け

Internet


SOAP/HTTP

A社 B社

ポリシーAに則ってサービスに接続し

てくださいB社のサービスに接続するために、ポリシーAをアプリケーションにアタッチしよう

Policy AWS-Security1.1を使用X509v3証明書を使用

ポリシーの表記やWebサービスに関連付ける方法を規定したOASIS標準仕様

Web Services PolicyWeb Services Policy

Webサービス・ポリシーとはWebサービスにおけるQoSの設定をポリシーとして独立に記述したものです。従来はQoSにあたるWS-*の設定はアプリケーションのDeploymentDescripter(デプロイメント記述子)ファイルに記述していましたが、アプリケーションとは分離し、ポリシーとして記述することになります。

QoS内容を記述したポリシーを作成し、Webサービス・アプリケーションに関連付けることで、QoS設定を施します。ポリシー内容の表記やWebサービスに関連付ける方法について規定したOASIS標準仕様がWeb Services Policy(WS-Policy)です。

43

WAS V7 W/S

# 43



WAS V7 W/SWeb Services Policy(WS-Policy)とは

Webサービスのポリシーに関するOASIS標準仕様以下の仕様から構成される

WS-Policy Framework 1.5

Webサービスのポリシーを表現するための文法を定義

WS-Policy Attachments 1.5

ポリシーをWebサービスに関連付ける方法を定義

WS-Policy Assertions 1.5

ポリシー内容のアサーション（表明）を定義

各QoSごとにアサーションに関する仕様が作成されている

WS-SecurityPolicy1.2

WS-RM PolicyAssertion1.0/1.1

WS-MetadataExchange

メタデータを取得する方法を規定

ポリシー情報をメタデータとして取得する際に使用

Newv7

WS-PolicyはWebサービスのポリシーに関して規定したOASISの標準仕様ですが、以下の仕様から構成されます。

・WS-Policy Framework 1.5・WS-Policy Attachments 1.5・WS-Policy Assertion 1.5

PolicyAssertionについては各QoSごとに別仕様が策定されており、QoSの表記方法について規定されています。

*WAS V6.1 FeaturePack for WebServicesではポリシーを採用していましたが、WS-Policyの仕様をサポートしたものではありませんでした。WS-Policyのサポートが明確に表明されたのはWAS V7からになります。

WS-MetadataExchangeはメタデータを取得する方法を規定した仕様ですが、WS-PolicyではWebサービス・リクエスターがWebサービス・プロバイダーのポリシー情報をメタ・データとして取得する際に使用します。

44

WAS V7 W/S

# 44



WAS V7 W/SWASにおけるWS-Policyの実装

WASではポリシー・セットとしてWS-Policyを実装

Webサービス・アプリケーション(プロバイダー/リクエスター)に対してポリシー・セットを関連付け

JAX-WSで開発したWebサービス・アプリケーションに対応(JAX-RPCは使用不可)

用語

ポリシー・セット：ポリシーをまとめたもの

ポリシー(タイプ)：QoSを定義したもの

バインディング：ポリシー・セットに対してシステム固有の情報を定義をしたもの

Webサービス・リクエスター・アプリケーション

Policy B

Policy D

BD

ポリシー・セットA

attach !!①ポリシー・セットに含めるポリシーを選択②ポリシーセットをアプリケーションに関連付け③バインディングをセット

BD

バインディング・セット

WASではポリシー・セットとしてWS-Policyを実装しています。Webサービス・アプリケーション(プロバイダー/リクエスター)に対して、ポリシー・セットを関連付けます。対象となるのはJAX-WSで開発したWebサービス・アプリケーションでJAX-RPCのアプリケーションではポリシー・セットは使用できません。

ポリシーはQoSを定義したもので、ポリシー・セットは複数（もしくは単一）のポリシーをまとめたものです。

バインディングはポリシー・セットに対してシステム固有の情報を定義したものになります。

45

WAS V7 W/S

# 45



WAS V7 W/Sポリシーとポリシー・セット

ポリシー使用可能なポリシー（７種類)

HTTPトランスポート ,JMSトランスポート,SSLトランスポート, WS-Addressing

WS-ReliableMessaging, WS-Security, WS-Transaction

ポリシー・セットアプリケーション・ポリシー・セット

アプリケーションに対するポリシー・セットデフォルトで11種類のポリシー・セットが定義Kerberos V5 HTTPS default,LTPA WSSecurity default,SSL SSL WSTransaction,UsernameSecureConversation,Username WSSecurity default,WS-I RSP,WS-I RSP ND,WSAddressingdefault,WSHTTPS default,WSReliableMessaging persistent

システム・ポリシー・セットセキュリティー・トークン・サービス(トラスト・サービス)のためのポリシー・セットデフォルトで3種類のポリシーセットが定義SystemWSSecurityDefault,TrustServiceSecurityDefault,TrustServiceSymmetricDefault

ポリシーを組み合わせてカスタムでポリシー・セットを作成可能

WAS

でデフォルトで用意

WASで使用可能なポリシーは以下の７種類です。HTTPトランスポート / JMSトランスポート / SSLトランスポート / WS-Addressing / WS-ReliableMessaging / WS-Security / WS-Transaction

ポリシー・セットはWASにデフォルトで用意されているものと、ポリシーを組み合わせて作成した独自のポリシー・セットの両方を使用することができます。

デフォルトで用意されているポリシー・セットはアプリケーション・ポリシー・セットとシステム・ポリシー・セットの2種類で、計14種類です。デフォルトで用意されているポリシー・セットをコピーして独自にカスタマイズして新規ポリシー・セットを作成することも可能です。

46

WAS V7 W/S

# 46



WAS V7 W/Sポリシー・セットの使用方法①

アプリケーション単位サービス単位

オペレーション単位

①

②

ポリシー・セットの使用方法について説明します。

例として、Webサービス・リクエスターにポリシー・セットをアタッチする方法を説明します。①ナビゲーション・ツリーから[サービス]>[サービス・クライアント]を選択し、サービス・クライアントがリストされた画面を表示し、対象のアプリケーションのリンクをクリックします。

②アプリケーション単位/サービス単位/オペレーション単位でポリシー・セットを関連付けることができるので、適宜チェックボックスにチェックを付けて、「クライアント・ポリシー・セットの関連付け」を選択します。

どの単位でポリシー・セットの関連付けが可能かはポリシー・セットに含まれるポリシーによって異なり、オペレーション単位で関連付けができないものも多くあります。詳細につきましてはInfoCenterでご確認ください。

47

WAS V7 W/S

# 47



WAS V7 W/Sポリシー・セットの使用方法②

③

③関連付け可能なポリシー・セット一覧がプルダウンに表示されるので、選択してポリシー・セットを関連付けます。

※独自のポリシー・セットを使用したい場合は、事前にポリシー・セットを作成する必要があります。

48

WAS V7 W/S

# 48



WAS V7 W/Sポリシー・セットの使用方法③

④

④ポリシー・セットの関連付けの後に、バインディングの割り当てを行います。「バインディングの割り当て」ボタンを選択すると、割り当て可能なバインディング一覧が表示されるので、選択します。独自のバインディング設定を行いたい場合は「新規アプリケーション固有バインディング」を選択します。

49

WAS V7 W/S

# 49



WAS V7 W/S(参考)HTTPトランスポート・ポリシー

SOAP/HTTPのWebサービス・アプリケーションに対して設定可能

読み取りタイムアウト

書き込みタイムアウト

接続タイムアウト

持続接続を使用

再送有効

参考情報としてHTTPトランスポート・ポリシーについて説明します。ここでの設定内容は、HTTPトランスポートでの設定内容と同一であり、通常はアプリケーション・サーバー単位で設定するものです。

HTTPトランスポート・ポリシーを使用することで、アプリケーション単位でHTTPトランスポートの設定を行うことができます。

50

WAS V7 W/S

# 50



WAS V7 W/S(参考)JMSトランスポート

SOAP/JMSのWebサービス・アプリケーションに対して設定可能

要求タイムアウト

SOAP/JMSの双方向処理で使用

応答が返るまでのタイムアウト値

今まではアプリケーションのコーディングやDeploymentDescripterで設定

アプリケーションの変更や再デプロイすることなく変更が可能に！！


transaction.begin()

WS.invoke()

transaction.commit()

1UOW

参考情報としてJMSトランスポート・ポリシーについて説明し

WebSphere Application Server V7 アナウンスメント...

Documents

Transcript of WebSphere Application Server V7 アナウンスメント...