WS-Securityについて

Scott Seely
Microsoft Corporation

2002 年 10 月

適用対象:
Web サービスの仕様 (WS-Security、WS-Security補遺)

概要： この記事では、WS-Securityを使用して SOAP メッセージ自体にセキュリティを埋め込む方法について説明し、WS-Securityアドレス (認証、署名、暗号化) に関する懸念事項について説明します。 (14ページ印刷)

内容

はじめに
日常生活における平行線
SOAP メッセージへの既存の概念の適用
WS-Security SOAP ヘッダー
まとめ
リソース

はじめに

WS-Securityを説明する前に、なぜWS-Securityが存在するのかを理解することが重要だと思います。 Web サービスを初めて使用する多くのユーザーは、HTTP 経由で 2 つのエンドポイント間でメッセージを交換する方法として SOAP を使用しています。 HTTP 経由では、呼び出し元を認証し、メッセージに署名し、メッセージの内容を暗号化できます。これにより、メッセージは複数のディメンションでセキュリティで保護されます。呼び出し元はわかっており、メッセージの受信者はメッセージが転送中に変更されていないことを確認でき、ネットワークトラフィックを監視しているエンティティは、交換されているデータを把握できません。しかし、より大きな問題を解決するために SOAP メッセージングを見ている人にとっては、HTTP ベースのセキュリティだけでは不十分です。大きな問題の多くは、要求/応答よりも複雑なパスに沿って、または HTTP を含まないトランスポート経由でメッセージを送信することです。メッセージと呼び出し元の ID、整合性、およびセキュリティは、複数のホップで保持する必要があります。ルートに沿って複数の暗号化キーを使用できます。信頼ドメインが交差します。 HTTP とそのセキュリティメカニズムは、ポイントツーポイントのセキュリティのみをアドレス指定します。より複雑なソリューションでは、エンドツーエンドのセキュリティを組み込む必要があります。 WS-Securityでは、マルチポイントメッセージパスを介してセキュリティで保護されたコンテキストを維持する方法について説明します。

メモこの記事では、 XML 正規化、XML 署名、および XML 暗号化について既に理解していることを前提としています。

WS-Securityは、既存の標準と仕様を活用してセキュリティに対応します。これにより、WS-Security 内で完全なセキュリティソリューションを定義する必要がなくなります。業界はこれらの問題の多くを解決しています。 Kerberos と X.509 アドレス認証。 X.509 では、キー管理に既存の PKI も使用されます。 XML 暗号化と XML 署名では、XML メッセージの内容を暗号化および署名する方法について説明します。 XML 正規化では、XML を署名および暗号化する準備を整える方法について説明します。既存の仕様に追加WS-Securityは、これらのメカニズムを SOAP メッセージに埋め込むフレームワークです。これは、トランスポートに依存しない方法で行われます。

WS-Securityは、セキュリティ関連のデータを保持する SOAP Header 要素を定義します。 XML 署名を使用する場合、このヘッダーには、メッセージの署名方法、使用されたキー、および結果の署名値を伝える XML 署名によって定義された情報を含めることができます。同様に、メッセージ内の要素が暗号化されている場合は、XML 暗号化によって伝達されるなどの暗号化情報を、WS-Security ヘッダー内に含めることができます。 WS-Securityでは、署名または暗号化の形式は指定されません。代わりに、他の仕様によってレイアウトされたセキュリティ情報を SOAP メッセージ内に埋め込む方法を指定します。 WS-Securityは、主に XML ベースのセキュリティメタデータコンテナーの仕様です。

メッセージ認証、整合性、プライバシーのために他の既存のプロトコルを活用するだけでなく、WS-Securityは何を行いますか? UsernameToken 要素を介して単純なユーザー資格情報を転送するメカニズムを指定します。暗号化またはメッセージの署名に使用されたバイナリトークンを送信するために、 BinarySecurityToken も定義されます。このヘッダー内には、メッセージには、呼び出し元、メッセージの署名方法、メッセージの暗号化方法に関する情報を格納できます。 WS-Securityは、すべてのセキュリティ情報をメッセージの SOAP 部分に保持することで、Web サービスのセキュリティに関するエンドツーエンドのソリューションを提供します。

この記事では、WS-Securityや友人を使用して SOAP メッセージ自体にセキュリティを埋め込む方法について説明します。私たちは、WS-Securityの懸念事項を見ていきます:

認証
シグネチャ
暗号化

このトライアドは、セキュリティに関するメインの懸念事項に対処し、次の質問に回答します。

誰を承認していますか?
ホップ間でメッセージが変更されましたか?
このメッセージは、私はそれがどこから来たと思いますか?
操作方法、特定の関係者にのみ見せたいものを非表示にしますか?

まず、毎日の生活の中で見られるいくつかの類推を見てみましょう。

日常生活における平行線

WS-Securityが何をしようとしているのかを理解するために、まず現実世界の並列を見てみたいと思います。具体的には、日常生活で資格情報を使用するタイミングと方法は何ですか? 結局のところ、日々の生活では、資格情報を常に使用します。誰かがあなたの年齢を証明するように求められた場合は、財布を掘り下げて運転免許証を引き出します。通貨を使用せずに品目の支払いに移動すると、クレジットカードを使用して、クレジットエージェンシーに対してユーザーを識別します。国の国境を越える場合、または外国にいる間、パスポートはあなたの身元を保証します。これらの項目はすべて資格情報です。彼らは、クレジットカード、運転免許証、またはパスポートの所有者がドキュメントに名前が付けられた人物であることを主張します。ただし、ID は認証されません。認証は、ドキュメントで実行できないアクションです。紙文書の世界では、人々は認証を行います。認証のその側はどのように機能しますか?

運転免許証またはパスポートを提示すると、ドキュメントを読んでいる人が、ドキュメントが本物であることと、それらのドキュメントの正当な所有者であることを確認するために、いくつかの異なるアクションを実行します。

両方のドキュメントには、ドキュメントの登録済み所有者の画像と、その他の識別特性 (高さ、重量、目の色) が含まれています。ドキュメントを読んでいるユーザーは、ドキュメントに表示され、説明されているユーザーのように見えるようになります。
ドキュメントは定期的に期限切れになります。これは、最新の説明データがドキュメント上に存在するように行われます。
ドキュメントには、ドキュメントを提示するユーザーの署名と比較できる署名が含まれています。他の人の署名を正確に再現することは困難であるため、ユーザーの説明と組み合わせて使用する場合に、ID をチェックする合理的な方法になります。

これらのドキュメントには、他にも重要なプロパティがあります。誰かがドキュメントが本物であることをすぐに確認できるようにするマーキングがあります。ドキュメント自体は、有効な ID 情報を提供するために信頼できる組織によって付与されます:地方自治体と国の政府機関。私もクレジットカードを言及しました。これらは運転免許証やパスポートとは異なります。

これらは、政府ではなく銀行によって発行されます。
カード所有者を識別するための署名と名前のみが含まれます。
これらは、政府発行の ID などの別のサポートドキュメントが存在する場合にのみ、ID を確認するために使用できます。

クレジットカードのようなものは何をしますか?

通常、クレジットカードは認証に署名のみを使用します。一部のカードには、認証を少し強固にするために写真が含まれています。クレジットカードによって提供される認証が弱いため、多くの事業所では、クレジットカードを使用して政府発行の ID を確認するように求められます。セキュリティ面では、クレジットカードを提示すると、商品やサービスを請求する権利があり、クレジットカードを与えたorganizationが販売者に支払うことを主張します。マーチャントは、政府発行の写真付き身分証明書を実際の人物と比較することで、有効なカード所有者としての身元を検証できます。 (もちろん、電話またはインターネットを介してトランザクションを実行する場合、私の引数のこの部分はバラバラになりますが、これらのアリーナでもあなたを保護するための他のメカニズムが存在することを示すので十分です)。

SOAP メッセージへの既存の概念の適用

WS-Securityは、識別と承認に関するこれらの概念の多くを SOAP メッセージングの世界に移行することを目指しています。 SOAP メッセージで意味のある処理を行うには、そのメッセージに次のことを行う情報が含まれている必要があります。

メッセージに関連するエンティティを特定します。
エンティティが正しいグループメンバーシップを持っていることを証明します。
エンティティに正しいアクセス権のセットがあることを証明します。
メッセージが変更されていないことを証明します。

最後に、承認されていない関係者から情報を隠すメカニズムも必要です。身分証明の世界では、私は運転免許証またはパスポートを持っている人を証明します。私はメンバーシップカードを通じて特定の権利を持っていることを証明します。私の財布には、商品やサービスを請求したり、図書館から書籍をチェックしたり、保険会社に医療請求書を送り、地元の食料品店で割引を受けることができるようにするカードがあります。 WS-Securityでは、同じ概念を SOAP メッセージに適用できます。セキュリティトークンを使用して呼び出し元を識別し、その権限をアサートすると、次の情報を伝えるメッセージが表示される場合があります。

発信者 ID: 私は Joe User です。
グループメンバーシップ: ColdRooster.com 開発者です。
権利アサーション: 私は ColdRooster.com 開発者なので、データベースを作成し、ColdRooster.com マシンに Web アプリケーションを追加できます。

Kerberos などの認証テクノロジを使用して ColdRooster.com サーバー上に新しいデータベースを作成できるメッセージを作成するには、アプリケーションでいくつかのセキュリティトークンを取得する必要があります。最初に、メッセージを作成するアプリケーションは、Joe User に代わって動作していることを識別するセキュリティトークンを取得する必要があります。 Joe User は、ユーザー名/パスワードまたはスマートカードを使用してログインするときに、そのトークンを提供します。セキュリティインフラストラクチャで Kerberos が使用されていると仮定すると、Joe が使用している環境には、Joe にログイン時にチケット付与チケット (TGT) を付与するキー配布センターがあります。 Joe が ColdRooster.com で新しいデータベースを作成することを決定すると、環境はチケット付与サービスに移動し、Joe が ColdRooster.com に新しいデータベースを作成する権限があることを示すサービスチケットを要求します。環境では、そのサービスチケット (ST) を受け取り、ColdRooster.com でデータベースサーバーに提示します。そのデータベースサーバーはチケットを検証し、Joe が新しいプロセスを作成できるようにします。

WS-Securityは、前述のセキュリティ相互作用を SOAP ヘッダーのセット内にカプセル化することを目指しています。 WS-Securityは、2 つの方法で資格情報の管理を処理します。 Web サービスがカスタム認証を使用している場合にユーザー名とパスワードを渡す特別な要素 UsernameToken を定義します。 WS-Securityには、Kerberos Tickets や X.509 Certifications: BinarySecurityToken などのバイナリ認証トークンを提供する場所も用意されています。

図 1 は、かなり一般的なメッセージフローになるものを示しています。

図 1. 一般的なメッセージフロー。

セキュリティトークンサービスは、Kerberos、PKI、またはユーザー名/パスワード検証サービスである可能性があります。このサービスは Web サービスベースではない可能性があります。実際、Kerberos サービスチケット付与サービスには、オペレーティングシステムのセキュリティ機能を使用して Kerberos プロトコルを介してアクセスできます。クライアントがメッセージで使用するトークンを取得すると、クライアントはそれらのトークンをメッセージ内に埋め込みます。クライアントは、自分だけが知っているデータでメッセージに署名する必要があります。サーバーは、さまざまな方法で署名を推測できます。クライアントが認証に UsernameToken を 使用している場合、クライアントはハッシュされたパスワードを送信し、そのパスワードを使用してメッセージに署名する必要があります。サーバーは、メッセージに対して生成された署名がメッセージに含まれる署名と一致する場合に、クライアントがメッセージを送信したことを確認できます。

X.509 証明書を使用する場合、秘密キーを使用してメッセージに署名できます。メッセージには、 BinarySecurityToken に証明書が含まれている必要があります。 X.509 を使用する場合、X.509 公開キーを知っているすべてのユーザーが署名を検証できます。最後に、Kerberos を使用する場合、メッセージは Kerberos チケットに埋め込まれたセッションキーで署名または暗号化できます。 Kerberos チケットはトークンの受信者にキーを設定するため、受信者のみがチケットの暗号化を解除し、セッションキーを検出し、署名を確認できます。

認証が重要な場合は、SOAP メッセージに署名または暗号化することが重要です。なぜでしょうか。有効な ID トークンがメッセージに追加されるだけでは不十分です。これらのトークンは、有効なメッセージから解除し、攻撃者が使用するメッセージに追加できます。メッセージで使用される ID によってメッセージが作成されたことを示す証拠が必要です。 XML 署名を使用してメッセージに署名しないと、メッセージが変更されていないか、ID トークンが不正使用されていないことを通知できません。

この時点で、私はあなたがWS-Securityが何をするのかを理解していると思います。もう少し深く掘り下げて、その方法を見てみましょう。

WS-Security SOAP ヘッダー

このセクションから始めて、記事の残りの部分で続けて、XML スニペットを使用します。 XML 名前空間宣言をスニペット全体に表示し、混乱させる必要がないように、次の XML 名前空間を使用します。

表 1: XML 名前空間

名前空間	説明	名前空間 URI
Xs	XML スキーマ	http://www.w3.org/2001/XMLSchema
Wsse	WS-Security	https://schemas.xmlsoap.org/ws/2002/07/secext
Wsu	Utility 要素	https://schemas.xmlsoap.org/ws/2002/07/utility
Soap	SOAP 要素	https://schemas.xmlsoap.org/soap/envelope/

WS-Security仕様では、新しい SOAP ヘッダーが定義されています。 WS-Security SOAP ヘッダーに含まれている内容を理解するには、まず要素のスキーマフラグメントを調べた方が便利だと思います。

<xs:element name="Security">
    <xs:complexType>
        <xs:sequence>
        <xs:any processContents="lax" 
            minOccurs="0" maxOccurs="unbounded">
        </xs:any>
        </xs:sequence>
        <xs:anyAttribute processContents="lax"/>
    </xs:complexType>
</xs:element>

ご覧のように、Security ヘッダー要素を使用すると、XML 要素または属性をその中に存在させることができます。これにより、ヘッダーは、アプリケーションで必要なセキュリティメカニズムに適応できます。これが少し奇妙に聞こえる場合は、SOAP ヘッダーと本文のしくみについて考えてください。ヘッダーと本文の両方に XML 要素のコレクションを含めることができます。 SOAP 仕様では、XML 処理命令を含めることができないという事実以外に、これらの要素の内容に関するクレームはほとんどありません。

WS-Securityヘッダーで行う必要があるため、この種類の構造体が必要です。呼び出し元の権限と ID を識別するために、複数のセキュリティトークンを実行できる必要があります。メッセージが署名されている場合、ヘッダーには、署名方法とキーに関する情報の格納場所に関する情報が含まれている必要があります。キーは、メッセージ内にあるか、他の場所に格納され、単に参照されている場合があります。最後に、暗号化に関する情報もこのヘッダーで伝達できる必要があります。

では、中間者は、それが所有するヘッダーWS-Security知る方法を教えてください。 SOAP メッセージには、複数のWS-Securityヘッダーが含まれる場合があります。各ヘッダーは、一意のアクターによって識別されます。 2 つのWS-Security ヘッダーで同じアクターを使用したり、アクターを省略したりすることはできません。これにより、仲介者は、必要な情報を含むWS-Securityヘッダーを簡単に識別できます。もちろん、中継局は、処理するアクター URI を把握する必要があります。 URI をアクターに関連付け、仲介者が何をすべきかを確実に把握することは、プログラミングを介して処理する必要があるものです。任意の SOAP ヘッダーのアクター属性は、"このヘッダーは、アクター URI によって示される容量で動作するすべてのエンドポイントを対象とします" という意味です。その URI の意味は何ですか? Web サービスを設計するチームは、URI に意味を与えます。これは、仲介者がさまざまな容量で行動する可能性があることを意味します。その結果、中間者は 0 個、1 つ以上のヘッダーを消費する可能性があります。はい。複数のセキュリティヘッダーを使用する場合もあります。

WS-Security補遺

WS-Securityを少し評価した後、特にセキュリティを明確にする必要がある項目が多数出てきました。また、Web サービスに対して一般的に追加の項目を指定する必要があります。セキュリティに適用される補遺の部分については、記事全体で説明します。このセクションでは、セキュリティに固有ではない 2 つの項目 (wsu:Id と wsu:Timestamp) を見てみましょう。補遺は、これら 2 つの項目の動作と使用方法を正確に指定します。

wsu:Id

Id 属性は XML スキーマ ID 型を使用します。この要素は、Web サービスの中継局と受信側の処理を簡略化するために追加されました。この属性の値は、ドキュメント内の他の場所で重複してはなりません。補遺は、GXA 仕様の一意識別子として以外に要素を使用する方法の詳細については説明しません。ドアは大きく開いたままにして、他の仕様で ID の使用を制限 できるようにします。

wsu:Timestamp

メッセージ指向システムの一般的な懸念事項は、データのタイムラインに関連しています。データが古すぎると、データがスローされる可能性があります。2 つの矛盾するメッセージが到着した場合、関連するタイムスタンプを使用して、実行されるメッセージと無視されるメッセージを決定できます。 WS-Securityに表示され、他の GXA 仕様に表示される時間関連の問題を処理するために、 wsu:Timestamp 要素といくつかのヘルパー要素が定義されました。

メッセージの有効期間内の興味深いイベントは、メッセージが作成された時刻、送信者がメッセージの有効期限を切らしたい時刻、メッセージが受信された時刻です。受信側は、作成と有効期限を知ることで、データが独自に使用できるほど新しいかどうか、またはデータが古くなり、メッセージを破棄する必要があるかどうかを判断できます。このデータを伝達する要素は次のとおりです。

wsu:Created: メッセージが作成された時刻が含まれます。
wsu:Expires: 送信者または中継局によって設定され、メッセージの有効期限がいつ切れるかが識別されます。
wsu:Received: メッセージが特定の中継局によって受信されたタイミングを説明します。

上記のすべての要素は、独立して、または wsu:Timestamp 要素の一部として表示される場合があります。各には、アイテムを一意に識別するための wsu:Id 属性が含まれている場合があります。既定では、これらのタイムスタンプは時刻を xs:dateTime 型として表します。他の問題ドメインで意味を持つ可能性がある他の標準以外のタイムスタンプの柔軟性を確保するために、これらの各項目には ValueType という名前の属性も含まれています。時刻が xs:dateTime として表される場合、この属性を表示する必要はありません。

wsu:Received 要素を使用すると、wsu:Created または wsu:Expires で見つからない 2 つの追加属性を使用できます。要素は、Actor 属性を使用して、関連するアクターの URI と、 アクター が Delay 属性を使用することによって引き起こされる遅延の量をミリ秒単位で表すことができます。

前述のように、他の構造体内で wsu:Received、 wsu:Created、 および wsu:Expires 要素を 使用できます。たとえば、特定の要素がメッセージに追加されたタイミングを示す wsu:Created 要素が表示されるのが一般的な場合があります。メッセージに関する詳細情報を示し、一度に複数の要素を使用する場合、要素は wsu:Timestamp 要素内でラップできます。 3 つの要素はそれぞれ、タイムスタンプ内で 1 回だけ表示できます。タイムスタンプはメッセージ全体で使用できます。その場合、 soap:Header ノードの子として表示されます。たとえば、次の wsu:Timestamp ヘッダーを使用して、メッセージが次の 5 分間有効であることを示す可能性があります。

<wsu:Timestamp>
    <wsu:Created wsu:Id=
        "Id-2af5d5bd-1f0c-4365-b7ff-010629a1256c">
            2002-08-19T16:15:31Z
    </wsu:Created>
    <wsu:Expires wsu:Id=
        "Id-4c337c65-8ae7-439f-b4f0-d18d7823e240">
            2002-08-19T16:20:31Z
    </wsu:Expires>
</wsu:Timestamp>

この時点で、認証、署名、暗号化が WS-Security でどのように機能するかを調するのに十分な背景情報があると思います。

認証

WS-Securityは、ユーザーを検証する無限の方法を提供します。この仕様では、その無限数の 3 つのメソッドに対応しています。

ユーザー名/パスワード
PKI から X.509 証明書
Kerberos

このセクションでは、これらの各認証方法がどのように機能し、その情報が SOAP メッセージにエンコードされるかについて説明します。

ユーザー名/パスワード

呼び出し元の資格情報を渡す最も一般的な方法の 1 つは、ユーザー名とパスワードの組み合わせを使用することです。これは、HTTP 基本認証とダイジェスト認証で使用される手法です。実際のところ、HTTP ダイジェスト認証のしくみに精通している場合は、この認証メカニズムを使用して自宅にいるように感じるでしょう。この方法でユーザー資格情報を渡すために、WS-Securityは UsernameToken 要素を定義しています。要素のスキーマは次のとおりです。

<xs:element name="UsernameToken">
    <xs:complexType>
        <xs:sequence>
            <xs:element ref="Username"/>
            <xs:element ref="Password" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="Id" type="xs:ID"/>
        <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
</xs:element>

このスキーマフラグメントは、 ユーザー名 とパスワードの 2 種類を参照 します。これら 2 つの型は、基本的に必要に応じて追加の属性を含む可能性がある文字列です。 Password には、パスワードの受け渡し方法を示す Type という名前の属性が含まれています。パスワードはプレーンテキストまたはダイジェスト形式で渡すことができます。 SOAP メッセージで UsernameToken を 渡すと、XML が次のように表示されることがあります。

<wsse:UsernameToken>
    <wsse:Username>scott</wsse:Username>
    <wsse:Password Type="wsse:PasswordText">password</wsse:Password>
</wsse:UsernameToken>

ここに表示されるのは、プレーンテキストとして送信されるパスワードの例です。この特定のソリューションは、非常に簡単に中断するように見えます。パスワードをより安全な方法で送信する場合は、ダイジェストハッシュとして送信できます。

<wsse:UsernameToken>
    <wsse:Username>scott</wsse:Username>
    <wsse:Password Type="wsse:PasswordDigest">
        KE6QugOpkPyT3Eo0SEgT30W4Keg=</wsse:Password>
    <wsse:Nonce>5uW4ABku/m6/S5rnE+L7vg==</wsse:Nonce>
    <wsu:Created xmlns:wsu=
        "https://schemas.xmlsoap.org/ws/2002/07/utility">
            2002-08-19T00:44:02Z
    </wsu:Created>
</wsse:UsernameToken>

これにより、SHA1 ハッシュを使用してパスワードが隠されるようになったため、もう少しセキュリティが強化されます。パスワードダイジェストは、nonce と作成時間とパスワードの連結です。 nonce の長さは 16 バイトで、base64 でエンコードされた値として渡されます。これが機能する方法は、クライアントが、このすべての情報とパスワードを使用してパスワードハッシュを作成することです。受信者は、プレーンパスワードを取得し、ハッシュをもう一度作成することで、データを検証します。結果が一致する場合は、パスワードが正しい必要があります。この保護は、再生攻撃から保護されません。これを使用する場合は、作成された値と期限切れの値に対して十分な時間枠が小さい wsu:Timestamp ヘッダーも含めるようにしてください。次に、メッセージ内の wsu:Timestamp 要素に署名して、タイムスタンプの改ざんを検出できるようにします。そうしないと、攻撃者が完全な UsernameToken を 使用して Web サービスを攻撃する可能性があります。リプレイ攻撃から防御するには、受信メッセージの一意の特性を追跡するメカニズムも含める必要があります。このメカニズムでは、少なくともメッセージのタイムアウト期間のために、この特性をキャッシュに保存する必要があります。

X.509 証明書

ユーザーを認証するときに使用するもう 1 つのオプションは、単に X.509 証明書を送信することです。 X.509 証明書は、ユーザーが誰であるかを正確に示します。 PKI を使用すると、アプリケーション内の既存のユーザーに証明書をマップできます。証明書を単独で使用すると、非常に簡単なリプレイ攻撃が行われます。その結果、メッセージ送信者に秘密キーを使用してメッセージに署名するように強制することをお勧めします。そうすることで、メッセージが復号化されると、それが実際にユーザーであることがわかります。

メッセージが X.509 証明書に沿って送信されると、 BinarySecurityToken という名前のWS-Security トークンで証明書のパブリックバージョンが渡されます。証明書自体は、base64 でエンコードされたデータとして送信されます。 BinarySecurityToken には、次のスキーマがあります。

<xs:element name="BinarySecurityToken">
    <xs:complexType>
        <xs:simpleContent>
            <xs:extension base="xs:string">
                <xs:attribute name="Id" type="xs:ID" />
                <xs:attribute name="ValueType" type="xs:QName" />
                <xs:attribute name="EncodingType" type="xs:QName" />
                <xs:anyAttribute namespace="##other" 
                    processContents="strict" />
            </xs:extension>
        </xs:simpleContent>
    </xs:complexType>
</xs:element>

最も基本的な項目には、文字列、一意の識別子、および含まれる値の種類とエンコード方法を示す情報が含まれています。 ValueType には、WS-Security スキーマドキュメントの ValueTypeEnum によって定義された次のいずれかの値を指定できます。

wsse:X509v3: X.509 バージョン 3 証明書。
wsse:Kerberosv5TGT: Kerberos 仕様のセクション 5.3.1 で定義されているチケットを許可するチケット。
wsse:Kerberosv5ST: Kerberos 仕様のセクション 5.3.1 で定義されているサービスチケット。

Kerberos に関するこの情報が意味をなさない場合は、次のセクションでもう少し詳しく説明します。 EncodingType は別の列挙体です。 wsse:Base64Binary または wsse:HexBinary に設定されている場合。ご想像のとおり、この値は、使用されたエンコード方法を示すだけです。 WS-Security ヘッダーでは、X.509 証明書を渡すと、この要素は次のようになります。

<wsse:BinarySecurityToken 
    ValueType="wsse:X509v3" 
    EncodingType="wsse:Base64Binary" 
    Id="SecurityToken-f49bd662-59a0-401a-ab23-1aa12764184f"
>MIIHdjCCB...</wsse:BinarySecurityToken>

X.509 証明書を使用する場合は、メッセージの署名など、他の操作も行う必要があります。証明書の秘密キーを使用して作成された署名は、クライアントが証明書の正当な所有者であることを証明します。このようなメッセージを再生できます。再生に関する問題を軽減するために、メッセージが無視されるまでの時間を示すポリシーを作成します。時間は、メッセージ内の SOAP ヘッダーとして出荷される wsu:Timestamp 要素内を移動する必要があります。

Kerberos

Kerberos を使用するために、ユーザーはユーザー名/パスワードや X.509 証明書などの資格情報のセットを提示します。すべてがチェックアウトされた場合、セキュリティシステムはユーザーにチケット許可チケット (TGT) を付与します。 TGT は、ユーザーが読み取ることができないが、他のリソースにアクセスするために存在する必要がある不透明なデータです。ユーザーは通常、サービスチケット (ST) を取得するために TGT を提示します。システムの動作方法は次のとおりです。

クライアントはキー配布センター (KDC) に対して認証を行い、TGT が付与されます。
クライアントは TGT を受け取り、それを使用してチケット付与サービス (TGS) にアクセスします。
クライアントは、特定のネットワークリソースに対して ST を要求します。その後、TGS は ST をクライアントに発行します。
クライアントは ST をネットワークリソースに提示し、ST が示すアクセス許可を使用してリソースへのアクセスを開始します。

Kerberos には、クライアントがサービスに ID を証明し、サービスがクライアントに ID を証明するためのメカニズムが含まれているため、魅力的です。 ST は、1 つのネットワークリソースへのアクセスにのみ適しており、呼び出し元の検出に使用できます。メッセージで Kerberos チケットを提示する場合は、データをメッセージ自体に盲目的にコピーする必要があります。 WS-Securityでは、TGT または ST の取得方法については説明しません。

署名

メッセージが署名されると、メッセージを改ざんすることはほとんど不可能です。メッセージ署名は、メッセージ自体を外部の関係者がその内容を見てから保護しません。署名を使用すると、SOAP メッセージの受信側は、署名された要素が途中で変更されていないことを認識できます。可能な限り、XML 署名を使用してメッセージに署名する必要があります。なぜでしょうか。 XML シグネチャは、既にいくつかの難しい項目を処理して把握します。WS-Securityは、署名を使用してメッセージが変更されていないことを証明する方法を説明するだけです。上記の 3 つの認証メカニズムはすべて、次の 2 つのことを確認できるようにメッセージに署名する方法を提供します。

X.509 証明書、 UsernameToken、または Kerberos チケットによって識別されたユーザーがメッセージに署名しました。
メッセージは署名されてから改ざんされていません。

各メソッドは、メッセージの署名に使用できるシークレットを提供します。 X.509 では、送信者は秘密キーを使用してメッセージに署名できます。 Kerberos は、送信者がチケットで作成して送信するセッションキーを提供します。そのメッセージの目的の受信者のみがチケットを読み取り、セッションキーを検出し、署名の信頼性を確認できます。最後に、 UsernameToken はパスワードを使用して署名できます。

署名は XML 署名を使用して生成されます。 "Hello World" などの単純なメッセージに署名するには、メッセージ内のほぼすべての要素に個別に署名する必要があります。 wsu:Timestamp は、中間者が wsu:Received 要素を wsu:Timestamp に追加する可能性があるため、興味深い問題を示します。要素が変更されるたびに、署名を更新する必要があります。そうしないと、正しく表示されません。なぜでしょうか。コンテンツが変更された場合、署名は一致しません。 SOAP メッセージ内では、署名と必要な追加データによって、非常に多くの追加情報が追加されます。

暗号化

メッセージ送信者の ID を証明し、メッセージが変更されていないことを示すだけでは十分ではない場合があります。クレジットカード番号または銀行口座番号をプレーンテキストで署名された方法で送信した場合、攻撃者は実際に他の攻撃者がメッセージの内容を変更していないかどうかを確認できます。その結果、データが有効であるという信頼度が高くなります。それはあなたには良くないですね。代わりに、目的のメッセージ受信者のみがメッセージを読み取ることができるようにデータを暗号化する必要があります。ネットワーク交換を見ているすべてのユーザーは、メッセージの内容を忘れている必要があります。メッセージの署名と同様に、WS-Security仕様は正しいことを行い、既に存在し、暗号化のジョブを適切に行う標準を採用しています。正解です。XML 暗号化が組み込まれています。

データを暗号化する場合は、対称暗号化または非対称暗号化のいずれかを使用することを選択できます。対称暗号化には共有シークレットが必要です。つまり、メッセージの暗号化に使用されるキーは、メッセージの暗号化解除に使用するキーと同じです。対称暗号化は、両方のエンドポイントを制御し、キーを使用するユーザーとアプリケーションを信頼できる場合に適しています。対称暗号化には、キーの分散に問題があります。ある時点で、キーを受信側に送信する必要があります。これを行うにはどうすればよいでしょうか。必要に応じ、メールにディスクを発送するか、キーをネゴシエートしますか? どちらのオプションも機能します。

簡単に分散されたキーを使用してデータを送信する必要がある場合は、非対称暗号化に関するページを参照してください。 X.509 証明書では、これを許可します。データを受信するエンドポイントは、その証明書を公開して投稿し、公開キーを使用してすべてのユーザーが情報を暗号化できるようにします。受信者のみが秘密キーを認識します。このため、受信側のみが暗号化されたデータを受け取り、読み取り可能なデータに戻すことができます。

では、暗号化されたメッセージは次のようになります。 Triple-DES を使用している場合、送信側と受信側の両方で、何らかの安全な方法でキーを交換する必要があります。対称キーは、Kerberos チケット内で非表示にすることも、帯域外で交換することもできます。 XML 暗号化情報が埋め込まれた WS-Security ベースのメッセージは、次のようになります。

<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope 
    xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <soap:Header    
        xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/07/secext"
        xmlns:wsu="https://schemas.xmlsoap.org/ws/2002/07/utility">
        <wsu:Timestamp>
            <wsu:Created 
                wsu:Id="Id-3beeb885-16a4-4b65-b14c-0cfe6ad26800"
                >2002-08-22T00:26:15Z</wsu:Created>
            <wsu:Expires 
                wsu:Id="Id-10c46143-cb53-4a8e-9e83-ef374e40aa54"
                >2002-08-22T00:31:15Z</wsu:Expires>
        </wsu:Timestamp>
        <wsse:Security soap:mustUnderstand="1" >
            <xenc:ReferenceList>
                <xenc:DataReference 
        URI="#EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51" />
            </xenc:ReferenceList>
            <xenc:ReferenceList>
                <xenc:DataReference 
        URI="#EncryptedContent-666b184a-a388-46cc-a9e3-06583b9d43b6" />
            </xenc:ReferenceList>
        </wsse:Security>
    </soap:Header>
    <soap:Body>
        <xenc:EncryptedData 
            Id="EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51" 
            Type="http://www.w3.org/2001/04/xmlenc#Content">
            <xenc:EncryptionMethod Algorithm=
                "http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <KeyName>Symmetric Key</KeyName>
            </KeyInfo>
            <xenc:CipherData>
                <xenc:CipherValue
                >InmSSXQcBV5UiT...  Y7RVZQqnPpZYMg==</xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
    </soap:Body>
</soap:Envelope>

上記のメッセージには、暗号化されたデータと暗号化の実行方法に関する情報が含まれています。キーにアクセスできないユーザーは、 soap:Body 内の暗号テキストを復号化できません。

非対称暗号化を実行する場合、そのメッセージを復号化するには、秘密キーがメッセージの受信者に認識されている必要があります。公開キーの交換は、事前に把握しておく必要があります。

まとめ

WS-Security、SOAP メッセージで呼び出し元を識別し、メッセージに署名し、メッセージの内容を暗号化できます。可能な限り、SOAP メッセージを安全に配信するために必要な発明の量を減らすために、既存の仕様が再利用されます。すべての情報はメッセージ自体内で配信されるため、メッセージはトランスポートに依存しません。メッセージは、HTTP、電子メール、または CD-ROM で配信された場合、セキュリティで保護されます。

リソース

Last updated on 2006-06-30