本稿では、2002 年秋に開発、配備されたある Web サービスでのセキュリティーの確保に関して、現在策定が進められている WS-Security 標準を使用したときの成り行きを紹介します。まず、Web サービスのセキュリティーに関係する要件について説明した後、HTTPS/SSL やデジタル証明書、デジタル署名といったテクノロジーを組み合わせてそれらの要件を満たしたときの事例を紹介します。Web サービスを起動するために使用される SOAP メッセージの WS-Security エレメントを丁寧に説明し、WS-Security エレメントの各セクションを詳しく説明していきます。本稿を読み終えたときには、実稼働の Web サービス・アプリケーションに WS-Security を導入する方法がよく理解され、この策定進行中の標準を皆さん自身のプロジェクトに応用できることが確信できることと思います。

Sam Thompson, jStart Program Manager for Web services, IBM

Photo of Sam ThompsonSam Thompsonは、1980年にIBMに入社し、VM製品開発にかかわるさまざまな技術的、管理的職務に従事しました。1992年には、ノース・カロライナ州Raleighのシステム管理開発研究室の配属となり、いろいろなSystemView製品の製品化に関与しました。SystemViewとTivoli Systemsとが合併したときには、技術伝道師として、合併の経緯、Tivoliの新しい戦略や製品、IBMとTivoliのワークグループ製品の統合化戦略を世界各地で説明して回りました。1997年3月、IBMのEmerging Technologies jStart (jump start) グループの現在の職務に就き、いろいろな組織と協力しながら、IBMのXML、Java、Webサービスといったテクノロジーを利用するための各種のソリューション開発を行っています。Samのメール・アドレスは thompsam at us.ibm.com です。



2003年 4月 01日

Web サービスのセキュリティー - ビジネスを始めるための準備

ここ数年の間に、Webサービスは、過大に宣伝されるテクノロジーから、数多くの組織によって生産的な使い方のなされるテクノロジーに変わってきました。新しいテクノロジー・プロジェクトはどんなものでもそうですが、Webサービスの初期の実装は、ファイアウォールの中での小さな、決してミッション・クリティカルでない砂場型の仕事やプロジェクトとなりがちでした。インターネットでWebサービスを提供する世界に乗り出していった勇気ある人々は、誰でも利用できるオープンなサービスを提供するか (XMethodsやAmazonなど)、独自に、通常は所有権のある、企業にまったく固有なセキュリティー方式を開発しなければなりませんでした。

通信手段としてインターネットを採用した初期の人々は、通常、何らかの形の登録処理を行ってオープンなインターネット・サービスを提供するか (Googleなど)、すでに緊密な信頼関係を築いている数少ないビジネス・パートナーにだけサービスを提供するかでした。たとえば、GoogleのWebサービス対応の検索エンジンを利用するためには、サービス要求者は、まず、HTMLベースのフォームを使って、Googleに登録する必要があります。登録処理の一部として、Googleは、要求者に、セキュリティー「トークン」を添えた電子メールを送信します。要求者は、サービスを起動する場合、GoogleのWebサービスの登録と認証を済ませたユーザーであることを確認するために、GoogleへのSOAPメッセージにこのトークンを提示します。

このような環境では、サービス・プロバイダーがSOAPなどの業界標準を使用している場合でも、サービス要求者がサービスを利用するためには、セキュリティー方式/処理に関する補足情報を提供する必要がありました。これは、要求者とプロバイダーを強固に結びつけるというあまり望ましくない状況を生み出していました。これは、どちらの側も望んでいないシナリオでした。


WS-Security 標準

Webサービスのセキュリティーを確保するための業界標準が必要なことは明らかでした。IBM、マイクロソフト、VeriSignがこの必要性に応えたのは2002年4月のことでした。WS-Securityの仕様には、以下のように記されています (参考文献も参照)。

「WS-Securityは、メッセージの完全性、メッセージの機密性、および単一のメッセージ認証によって、質の高い保護を行えるようにするために、SOAPメッセージングの機能拡張を記述するものである。これらのメカニズムには、さまざまな種類のセキュリティー・モデルや暗号化テクノロジーを適用できるものとする。

また、WS-Securityは、メッセージにセキュリティー・トークンを結合するための汎用的なメカニズムを提供する。WS-Securityは、特別な種類のセキュリティー・トークンを必要としない。それは、拡張可能なものとして設計される (複数のセキュリティー・トークン・フォーマットをサポートするなど)。たとえば、クライアントは、身元 (identity) の証明を与えるとともに、何かのビジネスの認証を受けていることの証明を与えることも可能である」

1997年以来、IBMは、jStartというプログラム (jump-start [活力注入] の略。参考文献参照) を実施し、カスタマーやビジネス・パートナーが新しく登場するテクノロジーを利用できるように手助けしてきています。このプログラムの目標は、新しいテクノロジーを採用して間もない企業や人々が、それらのテクノロジーを活用することで、ビジネスを成功に導けるようにするということです。昨秋、jStartプログラムは、インターネットを通信手段として利用したB2B (business-to-business) のWebサービスを提供したいという会社といっしょに開発を行う機会がありました。この会社は、強固なセキュリティーと相互運用性を望んでおり、そのビジネス・パートナーとの間のSOAPメッセージのトラフィックのセキュリティーを確保するためにWS-Securityの手法を採用することにしました。本稿では、そのプロジェクトおよびそこでのWS-Securityの使い方を紹介します。


なぜ WS-Security なのか

われわれのカスタマー (以下、単にカスタマーという) のアプリケーションのユースケースの開発を進めていくと、以下のように、セキュリティーに関係するもので非機能的な要件が、いくつか特定されました。

  1. カスタマーとそのビジネス・パートナーとの間の通信は、インターネット上を流れる際、第3者からは見られてはならない。
  2. カスタマーは、メッセージがどこから送られてきたのかを確認できなければならないし、送信者が主張している通りの送信者であることを照合できなければならない。
  3. カスタマーは、送信されているデータが改竄されていないことを確認できなければならない。

非機能的な要件の1は、HTTPS/SSLトランスポートのセキュリティーを使用することで対処できるでしょう。このアプリケーションは、第3者のサービス・プロバイダーや中継者が関与することのない、ポイント・ツー・ポイントのアプリケーションですので、暗号技術を使ってSOAPメッセージの全部または一部を暗号化することも考慮されましたが、このときには、それは実施されませんでした。第3者が関与しないのであれば、SOAPメッセージの一部を暗号化するという暗号化の手順を追加することで得られる利点は、開発費の増加やメッセージ・レベルで暗号化を実装する場合に必要となったであろう複雑さを充分正当化できるだけのものではありませんでした。

非機能的な要件の2と3は、デジタル署名およびデジタル証明書を利用することで対処できるでしょう。デジタル証明書という手法を採用する場合、Webサービスの要求者は、信頼できる認証局 によって署名されたデジタル証明書を所有している必要があります。要求者の身元とメッセージの完全性の確認が行えるように、要求者は、この証明書を使って、その身元を主張し、SOAPメッセージにデジタル的に署名することになります。

メッセージがカスタマーのシステムで受信されると、メッセージには時間のタイムスタンプが付加され、ログがとられます。この時点で、デジタル署名の妥当性が検査されます。妥当性の検査では、送信者のサイトで署名がなされて以降、メッセージの内容が変更されていないことを照合するだけでなく、そのメッセージがその送信者から出されたものであるかどうかが確認されます。カスタマーがDB2に作成するSOAPメッセージのログは、否認防止の目的で使用されます。


Web サービス

要件や技術的な手法を理解したところで、次に、実際の実装について見ていくことにします。カスタマーがWebサービスを実装するために選択したアプリケーションは、WebSphere Studio Application DeveloperおよびIBMのalphaWorks Webサイトに登録されているいくつかのツール、すなわちXML Security SuiteやIBM Web Services Toolkitに含まれているApache Axisランタイムを使って開発されました。このアプリケーションは、カスタマーのコア・ビジネス・アプリケーションを駆動する上で充分強力ではありますが、1つの手法を実装するだけのシンプルなものとなっています。このアプリケーションは、WebSphere Application Server上に配備され、WebSphere MQ Seriesを通してカスタマーのコア・ビジネス・アプリケーションとのやりとりを行います。

以下は、このWebサービスを受けるために送られてきたSOAPメッセージの例であり、Application Developerに含まれているTCP/IPモニターを使って捕捉したものです。ここでは、カスタマーの機密を守るために、SOAPのURLを一般的なものにし、アプリケーションに固有なSOAPのペイロードは除去し、計算される値のいくつかは少し変更してあります。

1.<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
2.<soapenv:Header>
3.<wsse:Security soapenv:actor="http://www.jStartcustomer.com/actors#verifier" 
        soapenv:mustUnderstand="1" 
        xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
4.<SignedInfo>
5.<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
6.<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
7.<Reference URI="#sign_content_1043176028580">
8.<Transforms>
9.<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
10.</Transforms>
11.<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
12.<DigestValue>FLuQTa/LqDIZ5F2JSaMRHSRuaiQ=</DigestValue>
13.</Reference>
14.</SignedInfo>
15.<SignatureValue>
16.kGlrrXjKku/WXKxID+JJkEXY+aGNYHc5dy8GwbLFtB5Msll2/MhwdnO9wastJ0gLPzLy3oHL
17.7A8ggkMkjgAqnLg6PTzM7MdKoIAhe+xRHdOysamGucFJQRMrU+JQ4WATJt0bpdClwJy6mexT
18.Su48mq1q5rM9YZh61P7UEUKt+EQ=
19.</SignatureValue>
20.<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
21.<KeyValue>
22.<RSAKeyValue>
23.<Modulus>
24.2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8ARepOA1ABFK2OMy
25.pzb+Rb+nWQeo//yFz/28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGpFIRH
26.18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492k=
27.</Modulus>
28.<Exponent>AQAB</Exponent>
29.</RSAKeyValue>
30.</KeyValue>
31.<X509Data>
32.<X509IssuerSerial>
33.<X509IssuerName>OU=Java,O=IBM,L=Unknown,ST=Oklahoma,C=US</X509IssuerName>
34.<X509SerialNumber>0</X509SerialNumber></X509IssuerSerial>
35.<X509SubjectName>CN=John Doe</X509SubjectName>
36.<X509Certificate>
37.MIIB0TCCAToCAQAwDQYJKoZIhvcNAQEEBQAwTzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE9rbGFo
38.b21hMRAwDgYDVQQHEwdVbmsam3duMQwwCgYDVQQKEwNJQk0xDTALBgNVBAsTBEphdmEwHhcNMDIw
39.OTI1MTAxMTQ4WhcNMDMwOTI1MTAxMTQ4WjATMREwDwYDVQQDEwhKb2huIERvZTCBnzANBgkqhkiG
40.9w0BAQEFAAOBjQAwgYkCgYEA2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8A
41.RepOA1ABFK2OMypzb+Rb+nWQeo//yFz/28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGp
42.FIRH18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492kCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCs
43.OD02WMoYcMR7Sqdb9oQyk7Nn4rQ5DBgZ5mxGGVzWxBZW/QON+Ir2j4KUjX1jalMvbHa9lnhPQmJi
44.Ued923rza7fvdRG2CDalbW0R3aPd5q0u3akP0/Ejb7z5o88heajCSgfRruvU+ZdOTT3Oe+RBQgw8
45.VuzbLApPnXiehowYuA==
46.</X509Certificate>
47.</X509Data>
48.</KeyInfo>
49.</Signature>
50.</wsse:Security>
51.</soapenv:Header>
52.<soapenv:Body>
53.application specific data/content
54.</soapenv:Body>
55.</soapenv:Envelope>:

このSOAPメッセージの中身を詳しく調べていきたいと思います。見ればすぐわかるように、これは、<soapenv:Envelope> の開始と終了のタグの組で一番外側を囲ってある典型的なSOAPメッセージです。SOAPエンベロープの中には、<soapenv:Header> セクションと<soapenv:Body> セクションが含まれています。WS-Securityセクションは、WS-Security仕様で定義されているように、SOAP Headerの中に設けられ、<wsse:Security> で開始、終了されるブロックで指定されます (3~50行)。<Security> ヘッダー・ブロックは、特定の受信者 (SOAPアクター) を対象とするセキュリティー関係の情報を添付するためのメカニズムを提供します。このユースケースでは、関係するSOAPアクターは1個だけですので、メッセージに含まれる<Security> ヘッダー・ブロックは、1個だけです。

3行目では、SOAPアクター属性でヘッダー・エントリーの受信者を定義しています (Security soapenv:actor="http://www.jStartcustomer.com/actors#verifier")。また3行目には、soapenv:mustUnderstand="1" という属性も指定されています。SOAPのmustUnderstand属性を"1" とすることで、サーバー・プロバイダーが、このSOAPヘッダー・エントリーを処理しなければならないことを指示しています。SOAPの仕様にあるように、この属性が"1" に設定されていれば、受信者がそのセマンティクス (そのエレメントの完全修飾名によって伝達されるもの) に従うことができず、それらのセマンティクスどおりにメッセージを処理できない場合には、受信者は、そのメッセージの処理を失敗に終わらせ、フォールトを発生させなければなりません。

SignedInfo と Digest

4行目から14行目までの<SignedInfo> </SignedInfo> は、メッセージの署名内容 (signed content) を表しています。デジタル署名アプリケーションで慣例となっていることですが、ダイジェスト (digest) は、処理を高速化するために使用されます。これは業界標準の慣行であり、性能面のいろいろな理由から行われていることです。上のSOAPメッセージのペイロード (SOAP Body) は、かなり長いものになっており、メッセージ全体に公開鍵アルゴリズムを適用すると、Webサービスの性能に大きな影響を及ぼすことになります。そこで、ダイジェスト が使用されます。ダイジェストは、固定長の短いメッセージで、そのデジタル署名は、簡単に生成、検証することができます。メッセージを受信すると、われわれが使用したWebサービス・デジタル署名検証クラス (Apache Axisのプラグ可能なプロバイダーとして実装したもの) は、ダイジェストを計算し、新たに計算されたダイジェストが送信されてきたダイジェストと一致するかどうかを検証します。

メッセージの署名内容 (Signed Content) の部分を構成する各エレメントを眺めてみます。5行目の<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> は、署名のなされている情報 (ここでは、ダイジェスト) の正規化形式(canonicalized form)を作成するために使用される正規化アルゴリズムを指定しています。この指定が必要なのは、XML文書およびそれらの文書を扱うプログラミング・ツールの性質からです。XML文書は、ときに、テキストとしては少し違うけれども、論理的には本質的に同じ文書であるということがあります。コメントの表記の仕方とか、XMLのデータ構造をシリアライズ/デシリアライズする際のXMLパーサーの行区切り子の処理の仕方のちょっとした差異が、同じ内容でも、バイナリー表現を少し違ったものにしてしまうことがあります。シリアライズされたデータのバージョンが少し異なるものに対してデジタル署名を検証するアルゴリズムを実行した場合、本来なら合格 であるべきはずなのに、不合格 になってしまうことがあり得ます。

この問題を回避するために、文書を、まず、正規化アルゴリズムを使って正規化形式に変換しておきます。このアルゴリズムは、W3C推奨のW3C Exclusive XML Canonicalization Version 1.0 Specification (参考文献参照) を実装したもので、文書を、その基本的正規化形式に変換します。こうすることで、正しく比較でき、したがって正しい結果を導く首尾一貫したバイナリー表現が得られることになります。

6行目の<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> は、署名方法のアルゴリズム (Signature Method Algorithm) を指示しています。これは、正規化アルゴリズムの出力を署名値 (Signature Value) に変換するためのアルゴリズムです。われわれが使用しているのは、キーに依存するアルゴリズム (RSA) とハッシュ・アルゴリズム (SHA1) を組み合わせた署名アルゴリズムです。このアルゴリズムは、W3C RFC 2437に規定されているRSASSA-PKCS1-v1_5仕様を実装したものです (参考文献参照)。

7行目の<Reference URI="#sign_content_1043176028580"> は、参照エレメントを表しています。Referenceの オプションのURI属性は、署名されたデータ・オブジェクトを特定します。Referenceブロックには、ダイジェストを計算するためのアルゴリズム、計算されたダイジェスト値、およびダイジェスト値を計算する前に実行される最終的な変換方法が指定されます。8行目から10行目までの<Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> は、変換アルゴリズムを指定し、11行目、12行目の<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>FLuQTa/LqDIZ5F2JSaMRHSRuaiQ=</DigestValue> は、ダイジェスト・アルゴリズムと計算されたダイジェスト値を示しています。

今回のアプリケーションの場合、Transformアルゴリズムにも、上で挙げたW3C Exclusive XML Canonicalizationアルゴリズムを使用しています。ダイジェストを計算するための方法Secure Hash Algorithmは、米国商務省標準技術局 (U.S. Department of Commerce/National Institute of Standards and Technology) のSecure Hash標準からのものです。

15~19行目の<SignatureValue>kGlrrXjKku/WXKxID+JJkEXY+aGNYHc5dy8GwbLFtB5Msll2/MhwdnO9wastJ0gLPzLy3oHL
7A8ggkMkjgAqnLg6PTzM7MdKoIAhe+xRHdOysamGucFJQRMrU+JQ4WATJt0bpdClwJy6mexT
Su48mq1q5rM9YZh61P7UEUKt+EQ=</SignatureValue>
は、署名値を示すもので、ダイジェスト値を暗号化したものです。これは、6行目で指定されたSignature Method Algorithmが出力した値です。

20行目から48行目までは、キーの概念を導入しています。鍵 (key) は、普通に読むことのできるテキスト・メッセージを、インターネット経由で伝送できるように、判読できないメッセージに数学的に変換するために使用されます。われわれのWebサービスでは、公開鍵/私有鍵 (数学的に関連付けられた1対の鍵)、すなわち非対称鍵暗号方式を使用します。これら2個の鍵のうち、1個は秘密にされます。それが私有鍵です。われわれのアプリケーションでは、Webサービスの要求者は、サービス・プロバイダーに文書を送信する前に、自分の私有鍵でダイジェストに署名します。

20行目の<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> は、Key Valueブロックを開始するとともに、われわれが使用する名前空間を指定しています。Key Valueブロックの<KeyValue> <RSAKeyValue> </RSAKeyValue> </KeyValue> では、Webサービスの要求者が、署名の妥当性を検査するのに必要な鍵を取得するために必要とする情報を、Webサービス・プロバイダーに対して指定します。上のメッセージでは、KeyValue エレメントに要求者の公開鍵が含まれており、それを使って署名の妥当性が検査されます。われわれは、否認防止の要件を満たすために、非対称RSA鍵方式を使用することにしました (RSAという名称は、3人の考案者Rivest、Shamir、Adlemanに因んでいます)。

RSA鍵方式を使用することで、そのメッセージが、Webサービス・プロバイダーが受信したものと同じ形式であったこと、およびそのメッセージが、抽出されるデジタル証明書の所有者によって署名されたものであることを、Webサービス・プロバイダーに対して保証します。再計算されたダイジェストが、SOAPメッセージから復号化されたダイジェストと一致するなら、サービス・プロバイダーは、そのメッセージの完全性を検証することができます。処理を加える前にメッセージのログをとることで (ログは、ハンドラー・チェーンの中の1番目のApache Axisのハンドラーとして実装されている)、Webサービス・プロバイダーは、当該メッセージが、そのメッセージに署名した者によって送信され、そのメッセージが送信されたときの形式に変更を加えることなく受信されたことを証明することができます。

RSAKeyValue エレメントには、以下の2つのフィールドが含まれています。

Modulus
<Modulus>
2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8ARepOA1ABFK2OMy
pzb+Rb+nWQeo//yFz/28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGpFIRH
18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492k=</Modulus>
Exponent
<Exponent>AQAB</Exponent>

RSA方式は、大きな素数を使って鍵の対を作成します。Modulusは、2つの大きな素数の積です。それぞれの対は、Modulusを共有しますが、固有のべき乗数 (exponent) も備えています。RSA LaboratoriesのFrequently Asked Questions About Today's Cryptography, Version 4.1という文書 (参考文献参照) には、ModulusとExponentの作成方法が、以下のように説明されています。

「2個の大きな素数pとqを使い、その積n = pqを計算します。このときのnが法 (modulus) です。次に、nよりも小さく (p - 1)(q - 1) と互いに素な数eを選びます。すなわち、eと (p - 1)(q - 1) とは1以外に公約数がないようにします。さらに (ed - 1) が (p - 1)(q - 1) で割り切れるような数dをもってきます。値eとdは、それぞれ、公開べき乗数 (public exponent) 、私有べき乗数 (private exponent) といいます。このとき、公開鍵を (n, e) の対とし、私有鍵を (n, d) の対とします」

サービス要求者は、その私有鍵を使って、デジタル的にメッセージに署名します。サービス・プロバイダー側では、要求者の公開鍵を使って、署名を照合します。サービス要求者は私有の非対称鍵を使ってメッセージに署名しますので、サービス・プロバイダーは、そのメッセージに署名した組織だけがその私有鍵の保有者であると断定できます。

デジタル証明書

Key Infoブロックの次のセクションは、<X509Data> エレメントで指定されるデジタル証明書そのものです。デジタル証明書は、ユーザーIDを使ってWebアプリケーションやエンタープライズ・アプリケーションのユーザーを識別するのと同じやり方で、メッセージの送信者を識別するために使われます。このデータ・ブロックの最初のエレメントには、証明書に署名した組織が指定されます。これは、通常、認証局 (certificate authority) となります。今回の場合、この情報は、一般的な情報 (<X509IssuerSerial> <X509IssuerName>OU=Java,O=IBM,L=Unknown,ST=Oklahoma,C=US</X509IssuerName> <X509SerialNumber>0</X509SerialNumber></X509IssuerSerial>) で置き換えてあります。

その次には、<X509SubjectName>CN=John Doe</X509SubjectName> というエレメントがきます。ここには、サービス要求者の識別名 (上の例ではJohn Doe) が指定されます。そして最後に、以下のX.509証明書そのものがきます。

<X509Certificate>
MIIB0TCCAToCAQAwDQYJKoZIhvcNAQEEBQAwTzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE9rbGFo
b21hMRAwDgYDVQQHEwdVbmsam3duMQwwCgYDVQQKEwNJQk0xDTALBgNVBAsTBEphdmEwHhcNMDIw
OTI1MTAxMTQ4WhcNMDMwOTI1MTAxMTQ4WjATMREwDwYDVQQDEwhKb2huIERvZTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEA2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8A
RepOA1ABFK2OMypzb+Rb+nWQeo//yFz/28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGp
FIRH18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492kCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCs
OD02WMoYcMR7Sqdb9oQyk7Nn4rQ5DBgZ5mxGGVzWxBZW/QON+Ir2j4KUjX1jalMvbHa9lnhPQmJi
Ued923rza7fvdRG2CDalbW0R3aPd5q0u3akP0/Ejb7z5o88heajCSgfRruvU+ZdOTT3Oe+RBQgw8
VuzbLApPnXiehowYuA==
</X509Certificate>

WS-Securityの処理の最終段階は、Webサービス要求者のデジタル証明書の妥当性を検査することです。デジタル証明書の手法を使用する場合、各Webサービス要求者は、信頼できる認証局 (CA) が署名したデジタル証明書を取得している必要があります。信頼できる認証局の定義は、この記事の範囲を越えていますが、通常は、業界から認められた第3者の認証局 (VeriSignのような会社) がこの役割を果たすか、Webサービス・プロバイダーが、それ自身のアプリケーションで使用する証明書に関して、認証局の役割を引き受けるかです。後者の方法が採られる場合、Apacheのオープン・ソースのOpenSSLツールキットを使用するか、WebSphere Application ServerのIKEYMANユーティリティーでサポートされる基本的なデジタル証明書を利用することが推奨されます。

今回のアプリケーションの立ち上げでは、最初は、カスタマーが認証局の役割を果たすことにしました。そういうわけで、カスタマーが、自ら署名した独自のCA証明書を作成しました。Webサービスのやりとりを開始する前に、Webサービス要求者は、Webサービス・プロバイダーに対して、アプリケーションで使用する証明書を提出しておく必要があります。Webサービス・プロバイダーは、認証局の役割を果たす場合、その証明書に署名し、それをWebサービス要求者に返します。

上記のように、Webサービス要求者は、CAが署名したデジタル証明書をSOAPメッセージに含めます。デジタル署名によって、メッセージの完全性が検証されると、証明書がメッセージから抽出され、CAの公開鍵を使って、その妥当性が検査されます。証明書の妥当性の検査が完了すると、Webサービス要求者は認証されたことになり、そのメッセージのWS-Securityの部分の処理は完了します。所有者は、無事、受信者に認証してもらうことができたというわけです。

もし後に、今回のサービス・プロバイダーが認証局の役割をやめて、業界から認められた信頼できる第3者の認証局を使用することにした場合でも、今使用している妥当性検査コードのロジックを変更する必要はありません。そのようなことになった場合、Webサービス要求者は、Webサービスを使用する前に、信頼できる認証局から証明書を発行してもらう必要があります。サービス要求者は、第3者の証明書をSOAPメッセージに含めるようにします。サービス・プロバイダーがデジタル証明書の妥当性を検査するときには、自ら署名したCAの鍵を使う代わりに、第3者のCAの公開鍵が使用されることになります。このような展開の場合、サービス・プロバイダーは、第3者の認証局との間に信頼関係を確立しておき、ユーザーに証明書を発行する前に、しっかりとユーザーの認証を行うことがCAにされます。


WS-Security と WSDL

Webサービスによって約束されていることに、エンド・ポイント間の疎な結合を実現でき、実行時に動的に発見し、起動することのできるサービスをUDDIディレクトリーにパブリッシュできるようにしているということがあります。残念ながら、現在のテクノロジーの発展段階では、SOAPメッセージのヘッダーにWS-Securityを使用すると、こうしたことは実現できなくなります。現在のJavaからWSDLを生成するツール (Java to WSDL emitters) は、まだ、WS-Securityの要件を適切に記述したWSDL文書を作成できるまでには至っていません。それに、仮に現時点でそれが可能だったとしても、WebSphere Studio Application DeveloperやVisual Studio .Netなどの開発ツールでは、サービスのWS-Security関連の指定を行うプロキシーを生成することはできません。

したがって、2003年初期の段階でのWebサービスの開発者は、こうした点を意識して妥協点を見出さなければなりません。WS-Securityを使用する場合、サービス・プロバイダーは、メッセージの中のWS-Securityの部分を処理するためのスタブ/プロキシーを提供して、それをパートナーの側で起動できるようにするか、WebサービスのWS-Securityの要件を、取引の可能性のあるビジネス・パートナーやカスタマーに手動通信で知らせる必要があります。本稿で紹介したWS-Securityベースのプロジェクトの場合、メッセージに正しく署名を行い、SOAPデータ・ストリームにWS-Securityエレメントを挿入するプロキシーが、Javaテクノロジー、COMおよび .Netのクライアント向けに作成されました。IBMその他のメーカーから提供される次世代のWebサービス開発ツールでは、WebサービスのWS-Securityエレメントを処理できるようになるはずですが、開発者は、現時点では、そうした処理が可能ではあるが、手作業を行う必要があるということを理解しておく必要があります。


まとめ

本稿では、2002年に開発され、配備されたインターネット・ベースのWebサービス・アプリケーションについて説明しました。WebSphere Application Server上に配備され、われわれのカスタマーのビジネス・パートナーが利用できるようにしたアプリケーションです。今回のアプリケーションは、セキュリティーのしっかりしたミッション・クリティカルなWebサービス・アプリケーションが、現在の開発ツールや配備プラットフォームを使って有効に機能することを証明することで、WS-Securityの仕様案が問題なく動作し、全体として有効であることを実証しています。われわれのカスタマーの事例では、確かに、SOAPメッセージのWS-Securityエレメントを自動化できずに、手作業で処理しなければならない面もありましたが、WSDL仕様の今後の展開の中にWS-Securityのサポートも組み込まれ、いろいろなベンダーのWebサービス開発ツールでもサポートされるようになることから、環境はよくなる一方です。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=294435
ArticleTitle=WS-Security を実装する
publish-date=04012003