0

RESTful サービスでユーザーを識別できる必要があります。クライアント証明書認証で HTTPS を使用することにしました。これにより、他のサービスがユーザーまたはパスワードを URL、ヘッダー、またはその他の方法で安全に渡すことができるようになります。

ここで、サービスに送り返すデータを暗号化したいと考えています。たとえば、プレーンなユーザー ID を送信する代わりに、自分のサーバー キーで暗号化して送り返すだけです。その後、サービスはこの (暗号化された) データを送信し、ローカルで復号化できるようになります。

この暗号化には、サービスから提示された SSL 証明書を使用したいと考えています。

私のサーバーにある証明書には、秘密鍵と公開鍵の両方が含まれていると思います。したがって、サーバー側の証明書の公開鍵を使用してデータを暗号化し、サーバー側の秘密鍵で安全に復号化できることを確認できます。サーバー側の証明書の公開鍵しか持たないため、サードパーティのサービスはデータを復号化できません。

ここで質問 - クライアント (HTTPS) からの X509Certificate 形式のクライアント SSL 証明書が与えられた場合、ローカル キーストアで対応する証明書を見つけるにはどうすればよいですか? その証明書の形式と、そこから秘密鍵/公開鍵を取得する方法は何ですか?

基本的なフローをUPDします。

手に入れたいもの

  • サービスは REST アプリにリクエストを送信します: http://rest.api.com/authenticate/username/password/
  • REST アプリはユーザー名/パスワードを取得し、データベースでユーザー ID を見つけます
  • REST アプリは ID をサービスと共有したくない
  • REST アプリは、サービスの SSL 証明書を認識しています
  • REST アプリは、そのサービスへの受信トラフィックを暗号化するために使用される、対応する公開鍵を見つけます。
  • REST アプリは ID "123456" を REST アプリの公開鍵で暗号化し、応答を送信します: { ok : "lybibHubJis7" }
  • サービスは REST アプリにリクエストを送信します: http://rest.api.com/lybibHubJis7/dosomething
  • REST アプリは、SSL キーチェーンの秘密鍵を使用して文字列 lybibHubJis7 を復号化し、ユーザー ID が 123456 であることがわかり、このユーザーで操作を実行します。
4

1 に答える 1

1

複数のコメントで議論の途中に飛び込もうとしている...

あまり。たとえば、サービスがリクエストを送信した場合: rest.api.com/authenticate/username/password の場合、文字列 123456 を含む JSON で何かを返信します。その後、サービスは rest.api.com/do/123456/whatever を使用します。私が欲しいのは、サービスから「123456」を隠すことです。そして、ランダムな文字列を生成してデータベースに入れ、有効期限などで「PreabEdAgIav」->「123456」の関係を維持したくありません。サービスに関連付けられた独自の公開鍵を使用して、これを暗号化します123456そして、サービスが壊すことができない何か他のものを手に入れます。

あなたが求めているのはデジタル署名であり、必ずしも暗号化ではないようです（ただし、両方を使用することもできます）。

認証サービスが何らかの認証トークン ( 123456) を提供し、それをサード パーティ サービスが後で使用するために送り返す場合、最も重要なことは、消費するサービスが、これ123456が実際にその認証サービスからのものであることを確認できる必要があるということです。誰でも受信者の公開鍵を使用して何かを暗号化できるため、ここでは公開鍵暗号化はあまり役に立ちません。

より理にかなっているのは、認証サービスに秘密鍵でこのトークンに署名123456させることです。これにより、後でそのトークンを消費するサービスは、それが認識した以前の認証ステップからのものであることを確認できます。そのトークンも隠したい場合は、結果を暗号化することもできますが、それほど必要ではないようです。

これを行うための SAML などの標準がありますが、HTTP URL バインディングを使用するとかなり長い URL になる可能性があります。

于 2012-10-05T12:41:35.833 に答える