3

Java、.NET などのさまざまなテクノロジを使用する多数のクライアント アプリケーションで使用される Web API Web サービスがあります。したがって、ユーザー資格情報は別のデータベースに保存されます。

私の Web サービスはIIS内でホストされており、サーバー側でSSLを構成して有効にしました。これにより、要求/応答メッセージが暗号化され、署名されていることが保証されます。

また、少数の既知の IP アドレスからの要求を許可するように、IIS の IP アドレス制限機能を構成しました。

メッセージはSSLを使用して暗号化されていますが、すべてのメッセージで資格情報をプレーンテキストで送信するため、基本認証を使用したくありません。

ユーザーがサーバーと同じドメインにないため、明らかに統合 Windows 認証を使用できません。

クライアントがブラウザーベースではないため、フォーム認証を使用できません。

では、Web サービスに認証と承認を実装する最良の方法は何でしょうか?

1 つのアプローチは、 Identity Provider/Security-token-service のように動作し、一定時間後に有効期限が切れるそのユーザー固有のトークンを生成するAuthenticate(username, password) Web メソッドを提供することだと考えていました。次に、クライアントは各 Web メソッド要求で認証トークンを送信する必要があり、コントローラー用のカスタム承認フィルターを作成して確認します。

このアプローチの利点は、ユーザーが各リクエストでユーザー名/パスワードを送信する必要がなく、一時的なトークンのみを送信する必要があることです。欠点は明らかにトークンの寿命を管理することです。いつ期限切れになりますか？たとえば、1 時間以内にリクエストが行われなかった場合。

Web サービスの認証と承認を実装する最良の方法は何ですか?

4

4 に答える 4

4

SOAP サービスに関する私のコメントでは、認証のオプションについて説明します。承認はサーバー アプリケーション内に実装され、選択した認証タイプとはほとんど関係ありません。Web サービスには、次の 3 つの分類があります。 -プライベート -コミュニティ -パブリック

あなたが提供している Web サービスは、信頼できるパートナーのみが利用できるコミュニティ サービスのようです。IISでIPアドレス制限が設定されていると説明したので、これを知っています。IP アドレス制限を含めることは、安全な Web サービスを実装するための多くの優れた手段の 1 つです。セキュリティは単一のものではありません。数々の防御の積み重ねです。IP アドレスの制限は良い出発点です。

Web サービスは本質的にステートレスです。したがって、Web サービスを呼び出すときは、すべての要求に資格情報 (ユーザー名とパスワード) を含める必要があるのが一般的です。したがって、それは問題でも懸念でもありません。

HTTP 基本認証は悪い選択ではありません。すべてのクライアントおよびサーバー アプリケーションでサポートされており、実装も簡単です。私は、HTTP 基本認証を最小公分母と考えるのが好きです。私はそれを除外しません。HTTP 基本認証にはプレーン テキストの http ヘッダーに資格情報が含まれているため、トランスポート チャネルを暗号化するために SSL (HTTPS) を含めることを常にお勧めします。

WS-Security は、Web サービスの非常に一般的な承認標準です。これは Web サービスの業界標準であり、仕様は構造化情報標準化推進機構 (OASIS) 組織によって公開されています。WS-Security には、ユーザー名/パスワードを含めるための UsernameToken プロファイルが含まれています。WS-Security ブロックが SOAP メッセージのヘッダーに追加されます。対照的に、HTTP 基本認証は HTTP ヘッダーに追加されます。HTTP 基本認証は、トランスポート プロトコルに添付されます。対照的に、WS-Security は SOAP メッセージに添付されます。WS-Security UsernameToken はプレーン テキストであるため、常に SSL (HTTPS) を含めることをお勧めします。

もう 1 つのオプションは、クライアント証明書認証です。このオプションは、ユーザー名/パスワードの代わりにデジタル証明書を認証トークンとして使用します。この方法はうまく機能しますが、前提条件として、Web サービス チームのメンバーとクライアント アプリケーション チームのメンバーの両方が SSL デジタル証明書に精通している必要があります。この方法の学習曲線は、他の方法よりも高くなります。

説明したカスタム ソリューションは必要ありません。求めるソリューションを実装して解決するための業界標準が多数存在するためです。たとえば、Web サービスに WS-Security を実装する場合、クライアント アプリケーション チームにドキュメントを提供し、クライアント アプリケーションに実装する方法を説明する必要はありません。WS-Security は、今日のほとんどの最新の SOAP サーバーと SOAP クライアントで十分に文書化され、サポートされている業界標準です。同じことが HTTP 基本認証にも当てはまります。

これが役立つことを願っています。乾杯、DCova

于 2013-04-07T20:18:02.447 に答える
1

IP アドレスは非常に簡単に偽装される可能性があるため、サービスを保護するために IP アドレスに依存しないでください。

HTTPS 経由のアクセスのみを許可し、さらにセキュリティを確保するために、リクエストが署名された証明書を確認することをお勧めします。さらに良いのは、独自の証明書サーバーを用意し、この目的のために独自の証明書を発行することです。

于 2013-04-06T18:48:07.133 に答える
0

Facebook では、パスワードが変更された場合、またはユーザーがアプリケーションの認証を明確に解除した場合にのみ変更されるアクセス トークンをアプリケーションに提供します。多くの人がこのアプローチを検討しています。これは、Google の Map API でも同様に行われます。私が考えることができる唯一の安全な方法は、リクエストの送信元 (リクエストの IP アドレス) を確認し、apikey を確認してから応答することです。

于 2013-04-06T18:10:17.393 に答える
0

私の Web サービスは IIS 内でホストされており、サーバー側で SSL を構成して有効にしました。これにより、要求/応答メッセージが暗号化され、署名されていることが保証されます。

SSL はトランスポート セキュリティであり、メッセージ セキュリティではありません。メッセージに署名するわけではありません。チャネルを暗号化します。

事前共有キーまたは API キーのアプローチがあなたのケースに最適だと思います。ユーザーはユーザー ID とパスワードを持っているので、どこかに登録していると思います。プロセスの一部として、共有対称鍵にすることができる鍵を生成します。つまり、両方の当事者 (クライアントとサーバー) が同じ鍵を持ちます。クライアントは、いくつかのカスタム スキームの認証ヘッダーでユーザー ID を送信し、要求メッセージの特定の部分の SHA256 ハッシュを送信します。サーバーはユーザー ID を取得し、キーを取得し、メッセージの同じ部分のハッシュを計算し、ハッシュが一致する場合、クライアントは参加します。

私の著書Pro ASP.NET Web API Security をご覧ください。

于 2013-04-09T03:26:02.390 に答える