web-dev-qa-db-ja.com

RESTサービスの認証/承認

複数のクライアントで使用されるWCFレストサービスがあります。クライアントから返された情報は、それらが誰であるかを知る必要があるため、クライアントに固有の情報を返すことができます。

このタイプの設計にアプローチして認証し、セッションのトークンを返し、このトークンをすべてのリクエストとともに渡すには、どうすればよいですか？

ありがとう。

restwcfauthenticationauthorization
4
Brian Mains

REST Webサービスのセキュリティに関するアイデアを探している場合は、「ハンドシェイク」について説明しているOpenAuth仕様の付録をご覧ください。

http://oauth.net/core/1.0/#anchor27

OpenAuth標準に準拠するWebサービスを作成することは、おそらくこれを行うことができるより安全な方法の1つです。認証、承認戦略についてのアイデアを提供します。

以下は、GETまたはPOSTのAuthorizationヘッダーから取得した例です。

Authorization: OAuth
    oauth_consumer_key="xxxxxxxxxxxx",
    oauth_token="xxxxxxxxxxxx",
    oauth_nonce="xxxxxxxxxxxx",
    oauth_timestamp="1184242096",
    oauth_signature_method="HMAC-SHA1",
    oauth_version="1.0",
    oauth_signature="xxxxxxxxxxxxxxxxxx"

OpenAuthの詳細については詳しく説明しませんが、本質的には、クライアントがクライアントを識別するコンシューマーキー、ユーザーを識別するトークン、および検証する暗号化された署名のBase64エンコードバイトを表す署名を提供できるようにしますリクエストがトランスポートで改ざんまたは変更されていないこと。

署名文字列の作成には、通常、リクエスト全体、パラメーター、コンシューマーキー、トークン、ノンス、およびクライアントが安全に保持する必要があるコンシューマーシークレットのエンコードされたパーセントの組み合わせが含まれます。この署名文字列が作成され、パーセントエンコードされると、暗号化でき、それらの暗号化されたバイトは、Authorizationヘッダーに含まれるBase64エンコード文字列に構築できます。

これをSSL経由で実行する場合、これは間違いなくRESTベースのWebサービスの認証/承認を処理する最も安全な方法の1つです。

4
maple_shaft

証明書やOpenIDを使用するのではなく、トークンベースのアプローチが最も簡単なソリューションであることがわかりました。私が取り組んだ1つのエンタープライズサービスアプリでは、認証のためにRESTエンドポイントを公開し、その後他のエンドポイントへの後続のすべてのリクエストと共にヘッダーで渡されるトークンで応答した認証サービスがありました。各操作は、トークンのヘッダーを検査し、そこにあるかどうか、および存在する場合は、トークンが必要な承認を持つユーザーを表すかどうかに基づいて適切なアクションを実行します。

私の提案は、クレームベースのセキュリティモデルを検討することです。第1に、トークン内にすべてのユーザーのクレーム情報をカプセル化することでサーバーをステートレスに保つことができるため、この方法の実装がはるかに簡単になります。そして、第二に、それはマイクロソフトと他の多くの人々が参入しているモデルです。 .NET開発を行っている場合は、Windows Identity Foundationを調べてください。これは現在.NETフレームワークのアドオンですが、Windows 8に組み込まれます（実際、.NET 4.5のデフォルトのセキュリティモデルです）。

2
jpm70

これを行う1つの可能な方法は、あなたが提案するように、Cookieベース（またはURLパラメータベース）のセッショントークンを使用することです。ただし、そのようなセッショントークンを渡すと、 [〜＃〜] hateoas [〜＃〜] の原則に違反します。 「真の」RESTフルサービスの場合、サーバーの状態を維持することは避けてください。

HTTPSを使用している場合は、HTTPで組み込みの authorization/authentication （セクション14.8）メカニズムの使用を検討することをお勧めします。つまり、WWW-AuthenticateおよびAuthorizationヘッダーを渡す Basic Auth 情報をリクエストごとにサーバーに返します。これにより、ステートレスを維持できますが、HTTPSを使用しているため、安全です。 HTTPSを使用していない場合は、多分:).

HTTPメカニズムでOAuthを使用することは、基本認証のもう1つの代替手段ですが、すでにHTTPSでチャネルを暗号化している場合は、複雑にする必要はありません。OAuthリクエストは再生できず、キーも公開されません。ベーシック認証はそうではありませんが、それらは普通のHTTPでは受け入れられます。

つまり、要約すると：

  • HTTPSでのみ通信している場合は、ほとんどのHTTPクライアントライブラリに組み込まれているシンプルな基本認証を使用できます。基本認証は一般的に実装がはるかに簡単です。
  • HTTPを使用していない場合は、基本認証を使用するしない必要があります。代わりに、2-legged OAuthを使用してください。
  • どちらの場合でも、WWW-AuthenticateおよびAuthorizationヘッダーで認証情報を共有
1
Jonathan

Webクライアントのサポートは至る所にあるため、私はHTTPSと基本認証に傾いています。また、必要がない場合は、セッションを実装しないことも好みます。それは不必要な複雑さであり、実際にはRESTfulではありません。 RESTリクエストはスタンドアロンである必要があるため、リクエストの作成に必要な認証情報やその他の情報を送信します。ただし、OAuth HTTPSおよび基本認証ではありません。

リソースには、アクセスできるユーザーとアクセスできないユーザーを制御する適切なACLが設定されている必要があります。認証されたユーザーからリクエストを受信すると、ユーザーがリソースにアクセスできる場合にのみ、リクエストは正常に処理されます。

0
dietbuddha