WCFセッションWindows Azure

Question

アプリケーションアーキテクチャは次のとおりです。 1）WCFサービスはファサードレイヤーとして機能し、サービス、ビジネスロジック、データアクセスレイヤーの上に位置します。 2）各クライアントはMVC/ASP .NET、または他のタイプのアプリケーションには、最初に認証され、「アクセストークン」を発行する必要があるClientTagがあります。このトークンは、システムは、Windows Azureの上でホストされるファサード層 3）へのすべてのメッセージで、クライアントによって渡され

はこれがそうのようなWCFのセッションを実装するのは簡単だっただろう

： 1）クライアントが呼び出しを開始します 2）WCFがClientTagを認証し、トークンを発行し、それをローカル変数として格納します 3）クライアント（クライアントからWCFセッションが確立され、以降のすべての通信が同じ「会話」の一部です）それ自身のSessionにトークンを格納し、それをすべての要求と共にWCFに渡します。

Azureが高可用性/負荷分散の性質を持つため、 WCFセッションをサポートしていません。ですから、私たちはこれをどのように実装するのですか？

解決策の1つは、AppFabricキャッシングを使用してWCFレイヤーのセッション状態を模倣することです。そこにアクセストークンを格納し、クライアントが渡したものに対して検証します。この問題は、クライアントとWCFの間に並行性がないことが原因です。だから、同じクライアントからのリクエストごとにWCFセッションのタイムアウトを進めなければならないでしょうが、すべてのリクエスト（数百/秒）でキャッシュを更新しないようにしたいと考えています。

提案がありますか？誰もAzureでこれに似た何かを実装しましたか？どんなフィードバックも高く評価されます。

P.S.サーバー上で発生する認証だけでなく、各クライアントのカスタム認証も行われます。 （一部のクライアントは、一部の機能にアクセスできる場合があり、そうでない場合もあります）。

ありがとう！

Answer 1

私はこれに直接似たものを実装する途中ですが、ACSによる認証アーキテクチャとしてOAuth 2.0を使用しています。

私が追いかけているモデルは、恥知らずに 盗まれた MSDNサンプルのコピー：https://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=35417です。これは、クライアントがユーザインタフェースを持っていることを前提としているため、ユーザは何らかの種類のユーザ名とパスワードを直接または第三者のアイデンティティプロバイダを通じて提示することができます。

このアプローチの利点は、WCFレイヤーがどのような種類のセッション状態も使用する必要がないことです。そのため、マシンキーなどでは面倒なことはありません。しかし、IPrincipalにマッピングできるものが得られますので、必要に応じてカスタムRoleProviderを作成し、通常の方法で宣言的な役割を使用することができます。

サンプルは旧式のASP.NETを使用しており、不透明な（おそらくむしろバグの多い）アセンブリMicrosoft.IdentityModel.Protocols.Oauthに依存しています。また、何かが欠落していない限り、他の場所にリリースされたことはありません（たとえば、Windows Identity Foundationの一部として）。

もう一度ACSを使用して、今度はOAuth 2.0プロトコルに従ってSAMLトークンを認証することもできます。詳細とサンプルコードはhttp://msdn.microsoft.com/en-us/library/windowsazure/hh127795.aspxです。これはUIのない​​システムに適しているかもしれません。