サービス構成を単純化すると同時に、パフォーマンスにもメリットをもたらします。メッセージ交換のブートストラップで使用することもできます。サービス・スタックを例に、対称暗号化を構成して使用する方法を説明します。パフォーマンスと比較します。サービスを専門とするコンサルタント兼トレーナーです。技術に注力しています。サービス・フレームワークのコミッターでもあります。仕様のエキスパート・グループの一員でもありました。技術が担う重大な役割の一部です。開発者にとって重要になる主要なフレームワークと技術について説明します。この連載から、現場での最新の開発情報を入手して、それらを皆さんのプログラミング・プロジェクトにどのように利用できるかを知っておいてください。証明書で公開鍵の所有権を保証することが必要となります。メッセージに署名を付けたり、メッセージを暗号化するために最も広く使われている手法であり、確かに利点もあります。厳格に検証する手段にも、リクエストに付けられた署名を強力に保証する手段にもなるという利点です。クライアント証明書には欠点もあります。それは、非対称暗号化によってパフォーマンス・オーバーヘッドがもたらされること、そしてクライアントごとに証明書を取得して維持しなければならないという管理上の悩みの種です。対称暗号化を使用することによって、クライアントとサーバーとの間で進行中のメッセージ交換のパフォーマンス・オーバーヘッドを減少させる仕組みを説明しました。両方のメッセージ交換でクライアント証明書のしがらみから抜け出る方法を紹介します。よる署名および暗号化」で説明したように、メッセージの署名には秘密鍵を使用し、メッセージの暗号化にはメッセージの受け取り側の公開鍵を使用します。アクセスできる誰もが検証することができますが、公開鍵で暗号化されたメッセージを復号できるのは、その公開鍵に対応する秘密鍵の所有者だけです。クライアントが公開鍵と秘密鍵のペアを持っていなければ、完全な非対称暗号化を使用することはできません。トークンに組み込むという方法です。使用してリクエスト・メッセージの暗号化または署名付与、あるいはその両方を行うことができます。サーバーも同じく、共有秘密鍵を使ってレスポンス・メッセージを暗号化したり、署名を付与したりすることができます。クライアントにはすでに共有秘密鍵があるため、サーバーからクライアントに共有秘密鍵を送り返す必要はありません。この記事で使用するバージョンを記載します。このポリシーは、双方向での送信メッセージ本文の暗号化に、クライアントが生成した共有秘密鍵を使用することを指定しています。アサーションが、共有秘密鍵による対称暗号化の使用法を構成します。使用することを指定しています。アサーションを使用しているところに暗黙的に示されています。それぞれの実装に合わせて定義する必要があります。この例の場合のパラメーターは単純です。クライアント・サイドはサーバー証明書が含まれるトラスト・ストアにアクセスするようにし、サーバー・サイドは証明書の公開鍵に対応する秘密鍵が含まれる鍵ストアにアクセスするようにすればよいのです。それぞれのスタックでパラメーターが渡される方法についての詳細は、この連載の以前の記事を参照してください。パフォーマンス」を参照してください)。