Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SAgenda
WebサービスにおけるQoS高信頼性Webサービス~WS-ReliableMessaging~会話型Webサービス・セキュリティ~WS-SecureConversation~Webサービス・ポリシー(参考)Webサービス・トランザクション
4
# 4
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWAS V7 W/SWebサービスにおけるQoS
5
WAS V7 W/S
# 5
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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)の3つの仕様を追加したものになります。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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWS-RM登場の背景
システムA システムB
システムA システムB
Webサービス・リクエスター
Webサービス・プロバイダー
SOAP/HTTP
SOAP/JMS
SOAP/HTTP
SOAP/JMS
Webサービス・リクエスター
Webサービス・プロバイダー
既存技術で信頼性を確保する際の問題点
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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からメッセージを受信
CreateSequence
WS-RMプロトコルによるメッセージ配信保証
CreateSequenceResponseSequence
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWS-RMの基本動作 -非同期型片方向-
リクエスト1
リクエスター(RM Source)
プロバイダー(RM Destination)
リクエスト1の送達確認
リクエスト2障害
リクエスト2
リクエスト2の送達確認
リクエストに対して、WS-RMのメッセージで送達確認(Ack)が返される送達確認が返されないリクエストは自動で再送信重複メッセージはRM Destinationで削除
RM Sourceによるリクエスト送信はアプリケーションとは別スレッド
リクエスト2 ×削除
WS-RMの基本動作について、非同期型片方向を例に説明します。
[リクエスト1]Webサービス・リクエスターがWebサービス呼び出しを実行すると、アプリケーションが実行されているスレッドとは別スレッドでRM Sourceがリクエスト送信を行います。WS-RMのプロトコルでは、リクエストに対して送達確認(Ack)が返ってくると正常に処理が完了したことになります。
[リクエスト2]リクエストの送信中にネットワーク障害などが発生し、リクエストがRM Destinationに届かないとします。RM Sourceは一定の間隔で送達確認が返されないリクエストを自動的に再送信します。
リクエスト2をRM Destinationが受信し、送達確認をRM Sourceが受け取る前に、RM Sourceがリクエスト2の再送信を実行したとします。RM Destinationはリクエスト2を既に受信し、Webサービス・プロバイダーに渡したことを記録しているので、重複メッセージとなるリクエスト2は削除します。
13
WAS V7 W/S
# 13
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWS-RMの基本動作 -同期型、非同期型双方向-
正常時正常時
リクエスト1
リクエスト1の送達確認
レスポンス1
レスポンス1の送達確認
リクエスター(RM Source)
プロバイダー(RM Destination)
リクエスト1
プロバイダー(RM Destination)
リクエスト1の送達確認
レスポンス1
レスポンス1の送達確認
障害
リクエスト1
障害
レスポンス1
障害時障害時
リクエスター(RM Source)
リクエストとレスポンスの両方に対して、送達確認(Ack)が返される送達確認が返されないリクエストとレスポンスは再送信重複メッセージは削除
同期型、非同期型双方向のWebサービス呼び出しのケースを説明します。前ページの非同期型片方向を組み合わせた形でリクエストとレスポンスの両方に対して送達確認(Ack)が返されます。非同期型片方向と同様に、送達確認が返されないリクエストとレスポンスは再送信され、重複メッセージは削除されます。
14
WAS V7 W/S
# 14
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/Sメッセージは「シーケンス」の概念の元で送受信される
シーケンス:特定のRMSourceとRMDestination間で送受信されるメッセージ集合
特定のWebサービスで送受信されるメッセージ集合
シーケンス確立でRMSourceとRMDestinationのエンドポイントURLの組を情報として持つ
シーケンス確立後にメッセージ送信を行う
リクエスター(RM Source)リクエスター(RM Source)
プロバイダー(RM Destination)
プロバイダー(RM Destination)
CreateSequence
CreateSequenceResponse(Identifier=seq1)
リクエスト1(Identifier=seq1,Message#=1)
①シーケンスの確立①シーケンスの確立
リクエスト1送達確認(Identifier=seq1,Message#=1 )
②メッセージの送信SOAPヘッダーにSequence情報を含む②メッセージの送信SOAPヘッダーにSequence情報を含む
リクエスト2(Identifier=seq1,Message#=2)
リクエスト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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
応答メッセージが送信されるべきEPR(エンドポイント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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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からメッセージを受信
CreateSequence
WS-RMプロトコルによるメッセージ配信保証
CreateSequenceResponseSequence
SequenceAcknowledgement
Webサービス・リクエスター
Webサービス・プロバイダー
server1 server2
QoS
WASではメッセージをメモリー、またはMessagingEngine(ME)に保管
別JVM上で稼動するMEを使用することでメッセージの永続化を実現
メッセージ送信を委譲
メモリーメモリー
QoS
WS-RMを使用する上で、WASではWebサービスのSOAPメッセージをローカルのメモリー上、もしくは別JVMで稼動するMessaging Engine(ME)に保持することができます。ME上にメッセージを保管することで、アプリケーション・サーバーの障害時にもメッセージを失うことなく永続化が可能です。
処理の遷移は以下になります。
1.Webサービス・リクエスター・アプリケーションでWebサービス呼び出しが実行されると、メッセージ送信はRM Sourceに委譲されます。2.RM SourceはSOAPメッセージをメモリー、もしくはMEに保管してから、制御をアプリケーションに戻します。
3.RM SourceはSOAPメッセージをRM Destinationに送信します。(この間はWS-RMプロトコルによるメッセージのやりとりが行われます)4.RM DestinationはSOAPメッセージを受信すると、メモリー、もしくはMEに保管してから送達確認を送信します。
5.RM DestinationはWebサービス・プロバイダー・アプリケーションにメッセージを送信します。
18
WAS V7 W/S
# 18
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWS-RMのQoSの設定
WASでは3つのレベルのQoSを提供
QoSの内容
①メッセージ、シーケンス情報の保管方法
②トランザクション・サポートの有無
非管理非パーシスタント
ローカル・メモリー上に情報を保持
トランザクション・サポート無し
サーバー障害時にメッセージ情報を失う
管理非パーシスタント
MEに情報を保持、情報を非同期にデータストアに保管
トランザクション・サポート有り
ME障害時にはメッセージ情報を失う
管理パーシスタント
MEに情報を保持、情報を同期的にデータストアに保管
トランザクション・サポート有り
ME障害時にもメッセージ情報を失わないDB
ME自体はJVM上で稼動
メッセージ永続化のためにデータストアとしてDBかファイルを指定
WASでは、WS-RMのQoS設定として3つのレベルを設けています。QoSで設定する内容は、①WS-RMのメッセージやシーケンス情報の保管方法と②トランザクション・サポートの有無の2点です。・非管理非パーシスタント
メッセージやシーケンス情報はJVMのメモリー上に保持するため、サーバー障害(JVM障害)時に情報を失い、メッセージのロスに繋がります。また、トランザクションをサポートしていません。
・管理非パーシスタント
メッセージやシーケンス情報をMEに保管し、MEのデータストアに対して非同期に永続化を実施します。サーバー障害時には情報を失いませんが、ME障害時に情報を失う可能性があります。(ME障害時にデータストアへ保管されていない情報を失います)トランザクションをサポートしています。
・管理パーシスタント
メッセージやシーケンス情報をMEに保管し、MEのデータストアに対して同期的に永続化を実施します。サーバー障害時、ME障害時の両方で情報を失うことはありません。トランザクションをサポートしています。
※以下、用語の使い方をまとめています。
非管理:メモリー上に情報を保持。トランザクション・サポート無し
管理:MEに情報を保持。トランザクション・サポート有り非パーシスタント:サーバー障害、もしくはME障害時に情報を失う可能性があります。パーシスタント:サーバー障害、ME障害時、共に情報を失うことはありません。
19
WAS V7 W/S
# 19
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/S(参考)管理非パーシスタントと管理パーシスタントの違い
MEの「メッセージの信頼性」が異なる
管理非パーシスタント:「高信頼性非パーシスタント」
MEはアプリケーションからメッセージの送信/受信要求を受け取ると、メッセージをキャッシュ・バッファに書き込んだ時点で、アプリケーションに制御を戻します。メッセージがある程度、キャッシュ・バッファに滞留した場合のみ書き込みます。
キャッシュ・バッファのサイズ指定可能です。
管理パーシスタント:「保障パーシスタント」(最も信頼性が高くメッセージのロスはなし)
MEはアプリケーションからメッセージの送信/受信要求を受け付けると、同期的にメッセージをデータ・ストアに挿入/削除します。書き込みがうまくいったことを確認してから、アプリケーションに制御を戻します。
共にMEの高可用性は別途考慮が必要
管理非パーシスタントと管理パーシスタントの違いを説明します。
共にメッセージやシーケンス情報をMEに保管するという点は同じですが、MEに設定する「メッセージの信頼性」のレベルが異なります。
管理非パーシスタントの信頼性は「高信頼性非パーシスタント」でMEのJVM上にある一定のメッセージが滞留した段階でデータストアにメッセージが保管されます。
管理パーシスタントの信頼性は「保障パーシスタント」でMEはメッセージの送受信と同期的にデータストアに情報を挿入/削除します。データストアへの書き込みが成功してからアプリケーションに制御を戻すため、データストアへの情報保管は確実に実行されます。
共にMEを使用する構成となるため、MEの高可用性については別途考慮が必要です。
20
WAS V7 W/S
# 20
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/Sトポロジー構成
シングルサーバー構成が対象
クラスター構成のサービスに適用するとアプリケーションが始動しない
アプリケーション・サーバー障害時に情報を損失
メッセージのロス
RM Destination
Webサービス・プロバイダー
server1
RM Source
Webサービス・リクエスター
メモリー
シーケンス情報を別JVM上のMEで共用
クラスター構成が可能
全クラスターメンバーがMEからシーケンス情報を取得
サーバー障害時に情報を損失しない
他のクラスター・メンバーが処理を実施RM
Destination
RM Destination
Webサービス・プロバイダー
Webサービス・プロバイダー
Cluster
server1
server2
RM Source
Webサービス・リクエスター
WASProxyサーバー
ME
非管理非パーシスタント
管理非パーシスタント/管理パーシスタント
WS-RMを使用した場合のトポロジー構成について説明します。WS-RMのトポロジー構成はQoS設定によって画面に示すように異なります。・非管理非パーシスタント
シーケンスやメッセージの情報をメモリー上に保管する非管理非パーシスタントは、シングルサーバー構成を対象としており、クラスター構成を組むことができません。アプリケーション・サーバー障害時には情報を損失するので、メッセージのロスにも繋がります。最もシンプルな構成でネットワーク障害時のみに対応可能です。
・管理非パーシスタント/管理パーシスタントクラスター構成が可能で、シーケンスやメッセージ情報をMEで共用します。サーバー障害時にもMEに保管された情報によって他のクラスター・メンバーが処理を続行します。クラスター構成を組む場合、WS-RMプロトコルのメッセージを同一のアプリケーション・サーバー(クラスター・メンバー)に処理させるためには、Webサービス・リクエスターとWebサービス・プロバイダーの間にIHSなどのWebサーバーではなくWASのプロキシー・サーバーを配置する必要があります。同一シーケンスの情報を同じアプリケーション・サーバーに送信するアフィニティ機能をWebサーバーは持っていないためです。クラスター構成では、ネットワーク障害に加えてアプリケーション・サーバー障害にも対応できます。
21
WAS V7 W/S
# 21
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/Sトランザクション・サポート <プロバイダー側>
プロバイダー側
非同期型片方向と双方向でトランザクション処理が可能
RM Destinationからアプリケーションへのメッセージのディスパッチがトランザクションスコープに含まれる
双方向ではトランザクションがコミットされてから応答メッセージが送信されます
Webサービス・リクエスター Webサービス・プロバイダー
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/S(参考)その他考慮点
順序性
WS-RMポリシーで「送信順にメッセージを配信」にチェックをつける
WS-ATとの関係
QoSでMEを使用する場合WS-ATは使用できない
MEを使用しない非管理対象ではWS-ATを使用可能
1UOW
Webサービス・リクエスター Webサービス・プロバイダー
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWS-RMの運用②
トラブルシューティングは管理コンソールから可能
障害が回復すれば処理は正常に実施される
RM Sourceで保持するメッセージ数
送信済み+保持するメッセージ数
エラー情報
WS-RMの処理でエラーが発生した場合のトラブルシューティングは管理コンソールから行うことができます。
例としてアウトバウンドシーケンスのページを画面に示します。
シーケンスごとに、シーケンスID、アプリケーション名、エンドポイントURL、RM Sourceで保持している(未送信の)メッセージ数、送信済みメッセージ(送信済み+保持するメッセージ)数、エラー情報、状況を示します。
シーケンスIDを選択すると、保持しているメッセージのメッセージ番号とメッセージ内容を確認することができます。エラーが発生した場合などで、保持しているメッセージの送信をキャンセルする場合は、この画面で削除します。
26
WAS V7 W/S
# 26
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/S(参考)WS-RMの運用③
新規シーケンスを作成して未送信メッセージを割り振る
ZIPファイルでエクスポート(中身はテキスト形式)
エラーが発生している場合、未送信メッセージ(保持しているメッセージ)をZIP形式のファイルでエクスポートすることができます。("未送信メッセージのエクスポート"ボタン)また、現在のシーケンスでの送信を止め、新規シーケンスを作成して未送信メッセージを割り振るということも可能です。("メッセージの再割り振り"ボタン)
27
# 27
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWebサービスにおけるセキュリティ
Webサービスのセキュリティを確保するためには以下の方法がある
トランスポート・レベル
SSL(HTTPS)通信とHTTPベーシック認証によるアクセス制御
メッセージ・レベル
SOAPメッセージの全体または一部へのデジタル署名の付加/メッセージ自体の暗号化
Webサービスアプリケーション
Webサービスリクエスター SSL通信
データは全て暗号化
SOAP
平文
SOAP
平文
Webサービスリクエスター
SOAP
平文
SOAP
暗号化
Webサービスアプリケーション
SOAP
平文
SSLは2地点間のみの仕組み
SOAP/HTTPのみの環境でしか利用できない
マシン間でのセキュリティ
トランスポート層に非依存
メッセージ・レベルのセキュリティ
サービス単位のセキュリティ
SOAPメッセージをセキュアに扱うための仕様としてWS-Securityが策定
Webサービスを使用する環境において、セキュリティを確保するためには、「トランスポート・レベルのセキュリティ」と「メッセージ・レベルのセキュリティ」の2つの方法が挙げられます。
・トランスポート・レベルのセキュリティ
SSL(HTTPS)通信とHTTPベーシック認証によるアクセス制御を行う従来の方法です。SSLはマシン間の通信データを全て暗号化し、セキュリティを確保しています。2地点間のみの仕組みであること、SOAP/HTTPのみの環境でしか利用できないといった特徴があります。・メッセージ・レベルのセキュリティ
SOAPメッセージの全体、または一部に対してデジタル署名の付加やメッセージの暗号化を行います。このSOAPメッセージをセキュアに扱うための仕様として作成されたのがWS-Securityです。
Webサービスの考えをベースとしていることから、トランスポート層に依存せず、また、サービス単位でセキュリティをかけることができます。更に、細かくメッセージ・レベルでのセキュリティも可能です。
29
WAS V7 W/S
# 29
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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メッセージにおける、セキュリティ・トークンの受け渡し、メッセージの完全性、およびメッセージの機密性の3つの主要なメカニズムを提供します。
これらのメカニズムは単独で使用することも、統合した手法で使用することもできます。(メッセージの署名と暗号化を行い、署名と暗号化で使用される鍵に関連付けられたセキュリティトークン階層を提供するなど)また、SOAP仕様のactor/role要素を使用して、複数のセキュリティ・モデルを使用して別々のメッセージ要素に対して署名・暗号化をかけることや、同一のメッセージ要素に対して署名・暗号化を同時にかけるなど柔軟な設計が可能です。
WS-Securityは明示的な固定されたセキュリティプロトコルについて記述しているわけではありません。将来的なスタンダードへの対応も見据え、拡張可能な形のフレームワークとして設計されています。
30
WAS V7 W/S
# 30
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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-I Basic Profile 1.1
WS-I Basic 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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/S
セキュリティ・コンテキスト
リクエスター、プロバイダー間の認証を確立するために使用した鍵や関連プロパティ
WS-SCの通信関係が存続している間、2者間で共有される
セキュリティ・コンテキスト・トークンとはセキュリティ・コンテキストを含む、セキュリティ・トークン
WS-SCの仕組み① セキュリティ・コンテキスト・トークンの生成
RequestSecurityToken(RST)リクエスター プロバイダー
RequestSecurityTokenResponse(RSTR)
WS-Securityランタイム
トラスト・サービス
RSTを受けて、セキュリティ・コンテキスト・トークン(SCT)を作成
Webサービス・プロバイダー
SCTSCTはメモリー上にキャッシュ
SCT
共通秘密鍵
WS-SCの仕組みの前半としてセキュリティ・コンテキスト・トークン(SCT)の生成について説明します。セキュリティ・コンテキストとは、リクエスターとプロバイダー間の認証を確立するために使用した鍵や関連プロパティを示します。WS-SCの通信関係が存続している間、2者間で共有される共通秘密鍵のようなものです。※SOAPメッセージ内ではセキュリティ・コンテキストをと表します。セキュリティ・コンテキスト。トークン(SCT)とは、セキュリティ・コンテキストを含んだセキュリティ・トークンを意味します。
WS-SCは最初にSCTを生成し、リクエスターとプロバイダーの両者間で共有するところからConversationが開始されます。WS-SCの最初の処理シーケンスを説明します。①リクエスターからRequestSecurityTokenメッセージ(SOAPメッセージ)が送信されます。②RSTを受けて、プロバイダーのトラスト・サービスはセキュリティ・コンテキスト・トークン(SCT)を生成します。*③プロバイダーは生成したSCTをリクエスターに送信します。リクエスターとプロバイダーの両者間でSCTは一定期間キャッシュされます。
WS-SCの最初に行われるSCTの受け渡し(①と③)処理はWS-Securityの公開鍵暗号方式を使用し、セキュリティを確保します。
*SCTの生成はWS-Trustで規定されており、通常は第3者機関に委ねられるようです。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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWS-SCの仕組み② 派生鍵
セキュリティ・コンテキスト・トークンから派生した鍵を使用してアプリケーション・メッセージにセキュリティをかける
RequestSecurityToken(RST)リクエスター プロバイダー
暗号化
暗号化
復号化RequestSecurityTokenResponse(RSTR)
WS-Securityランタイム
トラスト・サービス
復号化
暗号化
派生鍵 派生鍵
+WS-SC
SCTSCT
SOAP
+WS-SC
SOAP
復号化
暗号化 復号化
復号化
復号化 暗号化
暗号化
WS-Securityランタイム
アプリケーション・メッセージはSCTから派生した派生鍵を使用して暗号化・署名を実行
WS-Trustプロトコル(SCTの受け渡し)はWS-Securityの公開鍵暗号方式
対称鍵暗号方式によるパフォーマンスの向上
WS-SCの仕組みについて前ページのセキュリティ・コンテキスト・トークン(SCT)の受け渡しに続いて説明します。
リクエスターとプロバイダーの両者間でSCTを共有し、次の段階から通常の要求/応答処理が行われます。
WS-Securityでは公開鍵暗号方式が使用されますが、WS-SCではSCTから派生した派生鍵を使用した対称鍵暗号方式を使用してメッセージの暗号化・署名が実行されます。公開鍵暗号方式と比較して対称鍵暗号方式は負荷が低く、複数メッセージ交換を行うケースではパフォーマンスの向上が見込めます。
派生鍵のしくみについては次ページで詳細に説明しています。
37
WAS V7 W/S
# 37
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWS-RMにWS-SCを使用する
WS-RMで、シーケンス上のメッセージ送受信にWS-SCを使用可能
WS-RMシーケンスはSCTの派生鍵によって署名、暗号化
SCTにWS-RMのシーケンスをスコープとして宣言する
リクエスター(RM Source)リクエスター(RM Source)
プロバイダー(RM Destination)
プロバイダー(RM Destination)
CreateSequence
CreateSequenceResponse(Identifier=seq1)
リクエスト1(Identifier=seq1,Message#=1)
リクエスト1送達確認(Identifier=seq1,Message#=1 )
リクエスト2(Identifier=seq1,Message#=2)
リクエスト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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/SWAS V7 W/SWebサービス・ポリシー WAS V7 W/SWAS V7 W/S
42
WAS V7 W/S
# 42
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
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
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/Sポリシーとポリシー・セット
ポリシー使用可能なポリシー(7種類)
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で使用可能なポリシーは以下の7種類です。HTTPトランスポート / JMSトランスポート / SSLトランスポート / WS-Addressing / WS-ReliableMessaging / WS-Security / WS-Transaction
ポリシー・セットはWASにデフォルトで用意されているものと、ポリシーを組み合わせて作成した独自のポリシー・セットの両方を使用することができます。
デフォルトで用意されているポリシー・セットはアプリケーション・ポリシー・セットとシステム・ポリシー・セットの2種類で、計14種類です。デフォルトで用意されているポリシー・セットをコピーして独自にカスタマイズして新規ポリシー・セットを作成することも可能です。
46
WAS V7 W/S
# 46
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/Sポリシー・セットの使用方法①
アプリケーション単位サービス単位
オペレーション単位
①
②
ポリシー・セットの使用方法について説明します。
例として、Webサービス・リクエスターにポリシー・セットをアタッチする方法を説明します。①ナビゲーション・ツリーから[サービス]>[サービス・クライアント]を選択し、サービス・クライアントがリストされた画面を表示し、対象のアプリケーションのリンクをクリックします。
②アプリケーション単位/サービス単位/オペレーション単位でポリシー・セットを関連付けることができるので、適宜チェックボックスにチェックを付けて、「クライアント・ポリシー・セットの関連付け」を選択します。
どの単位でポリシー・セットの関連付けが可能かはポリシー・セットに含まれるポリシーによって異なり、オペレーション単位で関連付けができないものも多くあります。詳細につきましてはInfoCenterでご確認ください。
47
WAS V7 W/S
# 47
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/Sポリシー・セットの使用方法②
③
③関連付け可能なポリシー・セット一覧がプルダウンに表示されるので、選択してポリシー・セットを関連付けます。
※独自のポリシー・セットを使用したい場合は、事前にポリシー・セットを作成する必要があります。
48
WAS V7 W/S
# 48
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/Sポリシー・セットの使用方法③
④
④ポリシー・セットの関連付けの後に、バインディングの割り当てを行います。「バインディングの割り当て」ボタンを選択すると、割り当て可能なバインディング一覧が表示されるので、選択します。独自のバインディング設定を行いたい場合は「新規アプリケーション固有バインディング」を選択します。
49
WAS V7 W/S
# 49
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/S(参考)HTTPトランスポート・ポリシー
SOAP/HTTPのWebサービス・アプリケーションに対して設定可能
読み取りタイムアウト
書き込みタイムアウト
接続タイムアウト
持続接続を使用
再送有効
参考情報としてHTTPトランスポート・ポリシーについて説明します。ここでの設定内容は、HTTPトランスポートでの設定内容と同一であり、通常はアプリケーション・サーバー単位で設定するものです。
HTTPトランスポート・ポリシーを使用することで、アプリケーション単位でHTTPトランスポートの設定を行うことができます。
50
WAS V7 W/S
# 50
© IBM Corporation.Announcement Workshop 2008WebSphere Application Server V7WebSphere Application Server V7
Announcement Workshop 2008
WAS V7 W/S(参考)JMSトランスポート
SOAP/JMSのWebサービス・アプリケーションに対して設定可能
要求タイムアウト
SOAP/JMSの双方向処理で使用
応答が返るまでのタイムアウト値
今まではアプリケーションのコーディングやDeploymentDescripterで設定
アプリケーションの変更や再デプロイすることなく変更が可能に!!
Webサービス・リクエスター
transaction.begin()
WS.invoke()
transaction.commit()
1UOW
参考情報としてJMSトランスポート・ポリシーについて説明し