特集
次世代XML Webサービスを試す Part 2

3.セキュリティ・トークンとしてのX.509v3証明書

インフォテリア株式会社
吉松 史彰
2003/01/29

Page1 Page2 Page3 Page4 Page5

X.509v3証明書のセキュリティ・トークンとしての利用

 UsernameToken以外に、当初のWS-SecurityにはKerberosのチケットとX.509v3証明書がBinarySecurityTokenとして例示されている。また、その後同じ3社からXMLをセキュリティ・トークンとして利用する手順が示された。これによって、SAML(Security Assertion Markup Language)やXrML(eXtensible rights Markup Language)をWS-Securityのセキュリティ・トークンとして利用する道が開かれた。現在OASISのWebサイトでは、当初の仕様、補遺、XMLベースのトークンの利用手順を1つにまとめたドラフトが「Web Services Security Core Specification」として公開されている。また、具体的なセキュリティ・トークンとして、Kerberosチケット、X.509v3証明書、SAML、XrMLをそれぞれ利用する方法がやはりドラフトとして公開されている(UsernameTokenはCoreに含まれている)。現状のWSEでは、Microsoft.Web.Services.Security.X509SecurityTokenクラスを通じて、X.509v3証明書をセキュリティ・トークンとして扱うことができるようになっている。

 クライアント側でのMicrosoft.Web.Services.Security.X509SecurityTokenクラスの使い方は、UsernameTokenとほぼ同じだ。公開鍵を含むX.509v3証明書があらかじめC:\Temp\Certificate.cerというファイルに保存されているとすると、次のようなコードでその証明書をWS-Security仕様に従ってSOAPヘッダに添付できる。

localhost.Service1 svc = new localhost.Service1();

Microsoft.Web.Services.SoapContext ctx = svc.RequestSoapContext;
Microsoft.Web.Services.Security.X509.X509Certificate cert =
Microsoft.Web.Services.Security.X509.X509Certificate.
    CreateCertFromFile(@"C:\Temp\Certificate.cer");
Microsoft.Web.Services.Security.X509SecurityToken x509 =
    new Microsoft.Web.Services.Security.X509SecurityToken(cert);
ctx.Security.Tokens.Add(x509);
Webサービス呼び出し時に、SOAPヘッダにX.509v3証明書を添付するためのコード例
は、実際のコードでは改行しないで次行に続いていることを示しています)

 このコードを実行すると、次のようなSOAPヘッダがメッセージに付加される。これはWS-Security仕様で規定されているBinarySecurityTokenとしてX.509v3証明書を利用している例だ。<wsse:BinarySecurityToken>要素の内容の文字列は、証明書をBase64でエンコードしたものである。

<wsse:BinarySecurityToken
    ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"
    xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
    wsu:Id="SecurityToken-d4b13ef4-a21e-4586-af8a-e85d279d1445">
  MIIFCjCCA/KgAwIBAgIKYQZBywAAAA…(省略)…I1c+DA==
</wsse:BinarySecurityToken>
上記コードを使用した場合に、SOAPヘッダに付加されるX.509v3証明書の例

 X.509v3証明書をセキュリティ・トークンとして利用する場合、そこに含まれる申告は主にUsernameTokenと同じ「身元」に関するものになる。X.509v3証明書は、UsernameTokenとは違い、その証明書を発行した第三者機関から保証されている申告だ。ただし、保証されているということと、信頼できるということとはまったく異なる概念であることに注意してほしい。保証されていなくても信頼できる申告表明がある一方で、保証されていても信頼できない申告表明もあり得るのだ。保証されているか、されていないかの違いは、単に身元の照会を依頼できる先が存在するかどうかの違いだけだ。照会の結果がどうであれ、その内容を信頼するかどうかの判断はその表明を受け付けた側(Webサービス側)に委ねられている。つまり、SOAPヘッダに付加されている証明書の内容は、やはり「認証」されなければならない。

 X.509v3証明書をセキュリティ・トークンとして利用するには、もう1つ注意しなければならないことがある。通常、X.509v3証明書は外部に自由に公開されている情報である。従って、その証明書が添付されているというだけでは、その証明書の正当な持ち主から送られてきたメッセージかどうかは分からないのだ。証明書とそれに含まれる公開鍵はネットワークをのぞき見なくても普通に取得できるので、ある意味で平文のパスワードよりももっと利用価値の低いセキュリティ・トークンなのだ。つまり、証明書にもその所有の証明が必要になるのだ。

 WS-Security仕様には、所有の証明を行う方法に関して次のような記述がある。

 「所有の証明の申告が、別のセキュリティ トークンと組み合わされ、送信者の申告を証明する場合もあります。メッセージの完全性に使用されるデジタル署名は所有の証明の申告としても使用できますが、本仕様では、このようなデジタル署名をセキュリティ トークンの一種とは考えていません。」(WS-Security仕様書から引用)

 この文章自体には否定的なニュアンスが漂っているが、重要なヒントを示唆している。X.509v3証明書には、秘密鍵と公開鍵のキーペアの情報を格納できる。そのキーペアを使ってデジタル署名の仕組みを利用すれば、送信側が秘密鍵を所有していることの証明になる。この所有の証明を検証するには、添付された証明書に含まれる公開鍵を使ってデジタル署名を検証すればよい。キーペアの仕組み上、秘密鍵を持っていなければ公開鍵で解読できる暗号は生成できない。公開鍵で解読できるということは、送信側が暗号に使ったのが正しい秘密鍵であることの証明になる。つまり、送信側が秘密鍵を所有していることを証明できたことになる(下図)。

秘密鍵と公開鍵のキーペアを利用し、X.509v3証明書に対する所有の証明を行う方法

 WSEでこの方法を使って、X.509v3証明書からユーザーを認証する手順については後述する。


 INDEX
  特集 次世代XML Webサービスを試す Part 2
  WS-Security詳細解説
    1.WS-SecurityとWeb Services Enhancements
    2.セキュリティ・トークンと認証
  3.セキュリティ・トークンとしてのX.509v3証明書
    4.SOAPメッセージの完全性
    5.SOAPメッセージの秘匿性
 
 「特集:次世代XML Webサービスを試す」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間