特集 
次世代XML Webサービスを試す Part 2
3.セキュリティ・トークンとしてのX.509v3証明書 
インフォテリア株式会社 
              吉松 史彰 
2002/11/15 
 | 
  | 
      
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に含まれている)。現状のWSDKでは、Microsoft.WSDK.Security.X509SecurityTokenクラスを通じて、X.509v3証明書をセキュリティ・トークンとして扱うことができるようになっている。
 クライアント側でのMicrosoft.WSDK.Security.X509SecurityTokenクラスの使い方は、UsernameTokenとほぼ同じだ。公開鍵を含むX.509v3証明書があらかじめC:\Temp\Certificate.cerというファイルに保存されているとすると、次のようなコードでその証明書をWS-Security仕様に従ってSOAPヘッダに添付できる。
localhost.Service1 svc = new localhost.Service1(); 
 
Microsoft.WSDK.SoapContext ctx = svc.RequestSoapContext; 
Microsoft.WSDK.Security.Cryptography.X509Certificates.
X509Certificate 
  cert = Microsoft.WSDK.Security.Cryptography.X509Certificates.
X509Certificate.CreateCertFromFile(@"C:\Temp\Certificate.cer"); 
 
Microsoft.WSDK.Security.X509SecurityToken x509 = 
  new Microsoft.WSDK.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証明書に対する所有の証明を行う方法 | 
 WSDKでこの方法を使って、X.509v3証明書からユーザーを認証する手順については後編で解説する。
 
 
 
	
		Insider.NET 記事ランキング
		
		
			本日
			月間