8

Web API (サービス) - MVC (クライアント) アーキテクチャ プロジェクトの認証/承認シナリオを実装する際に、アプローチを決定するのに苦労しています。Web APIプロジェクトでカスタムトークンベースの認証を実装しましたが、認証を正確にどこに実装する必要があるか(クライアントまたはAPI自体)が難しいと感じています。

アーキテクチャの概要:

  • プロジェクト ソリューション -
    |
    | | __ ASP.NET Web API ベースの REST サービス (M/C 1 の IIS で独立してホスト)
    |
    | | __ ASP.NET MVC ベースのクライアント (M/C 2 Consuming REST サービスで IIS で独立してホストされる)
    |
    | | __ スマートフォン クライアント アプリケーション (REST サービスを利用)

実装済みの認証:

  • Web API でのトークン ベースの認証 (メッセージ ハンドラーを使用) - 認証用のすべての http 要求ヘッダーの一部である必要がある、認証されたユーザーの SHA1 暗号化トークンを生成します。
    (トークン = ユーザー名 + ユーザー IP)

  • SSL で保護された HTTP 要求。(繰り返しますが、メッセージ ハンドラーを使用します)

現在の問題:

  1. 承認はどの層で実装する必要がありますか?
  2. クライアントでユーザー ロールをどのように保持する必要がありますか? クッキーを使用していますか? またはトークン自体にロール情報を追加する (これにより、情報を復号化するための API のオーバーヘッドと、そのロールに関連付けられたアクセス許可を取得するための追加の DB 呼び出しが追加される可能性があります)
  3. クライアント セッションで認証トークンを保持する方法は?
  4. 私のアプリケーションはSPA MVCアプリケーションであるため、APIに対して行うすべてのAJAX呼び出しの一部として認証トークンを含める最良の方法は何ですか?

認証/承認の概念全体を考慮しながら、間違ったことをしていないことを願っています。したがって、代替アプローチ/提案をいただければ幸いです。

4

2 に答える 2

3

まず第一に、独自の認証メカニズムを発明することは決して良い考えではないと思います。

現在の問題に答えるには：

1一般的に言えば、Api はデータにアクセスする場所であるため、常に認証を使用して Api を保護する必要があります。クライアント (MVC アプリ/スマートフォン) は、API へのアクセスを許可する必要があります。

2 & 3 REST Api を使用しているため、Api をステートレスに保つことをお勧めします。つまり、セッション情報を保持しないでください。トークンに必要な役割データを含めるだけです。たとえば、JSON Web Tokenを使用できます。

4 私は常に認証ヘッダーを使用して認証データを送信します。DelegatingHandler (MessageHandler MVC、DelegatingHander HTTP の違いに注意してください) では、ヘッダーを簡単に取得できます。

protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
 {
    var authorizationHeader = request.Headers.Authorization;
    // Your authorization logic.

    return base.SendAsync(request, cancellationToken);
 }

認証ヘッダーを ajax 呼び出しに含める方法の詳細については、「How to use Basic Auth with jQuery and AJAX?」を参照してください。

追加情報:

私があなただったら、Thinktecture の Identity Server も見てみたいと思います: https://github.com/thinktecture/Thinktecture.IdentityServer.v2

また、REST サービス認証に関するこの回答も役立つかもしれません: REST サービス認証

于 2013-10-29T15:39:48.107 に答える