フォームベースの認証を使用するASP.NET MVC 4アプリケーションに取り組んでいます。ユーザーは、ログインフォームでのプロバイダーの選択に基づいて、メンバーシッププロバイダーに対して検証されます。たとえば、現時点では2つのプロバイダーがあります。ActiveDirectoryと、外部Webサービスを呼び出すカスタムプロバイダーです。ユーザーが有効な場合は、最終ログオン日などのローカルユーザーテーブルの情報を更新します。ユーザーが有効であり、ローカルユーザーテーブルに存在しない場合は、ユーザーを追加します。これがすべて完了したら、Cookieを設定してメインコンテンツに進みます。すべてのコントローラーはUser.Identity.IsAuthenticatedをチェックし、テストが失敗した場合はログインページに戻ります。
現在、このアプリケーションは単一のWebアプリケーションから複数のアプリケーションソリューションに移行すると言われています。各アプリケーションは、他のアプリケーションから独立して存在し、同じルックアンドフィールを共有し、同じログイン機能を使用する必要があります。各アプリケーションでは、新しいメンバーシッププロバイダーを追加する必要があります。アプリケーションへのアクセスを制限するためのデータも追加します。1人のユーザーは1つのアプリケーションにしかアクセスできず、別のユーザーはすべてのアプリケーションにアクセスできます。
データストレージの設定は問題ありません。あるアプリケーションのレイアウトを他のアプリケーションで使用するために共有することも問題ではありません。私が問題を抱えているのは、ログイン機能を「リファクタリング」して、新しいメンバーシッププロバイダーとアプリケーションを「すぐに」追加しても既存のアプリケーションを再公開する必要がないようにする方法を決定することです。現時点では、アプリケーションのシングルサインオン起動ページも必要ありません。彼らは、ユーザーがアプリケーションに直接アクセスしてログインし、そこにやってきたことを実行することを望んでいます。このように、私はに行くことhttp://site1.mysites.com、ログインして私の隣に男がに行く間、私の仕事をするhttp://site2.mysites.comで、ログおよび彼の作業を行います。
これを行う最善の方法に頭を抱えるのに苦労しています。私が最初に思ったのは、ログイン用のWCF Webサービスです。ログイン認証情報を渡して、コントローラーアクションでWebサービスを呼び出します。ログインが成功した場合、ローカルストレージからユーザーのアプリケーションのリストを取得できます。アプリケーションを追加しても、既存のアプリケーションのWebサービスに変更がないため、それらのアプリケーションを再公開する必要はありません。
また、このASP.NET Web APIについても耳にします。代わりにそのルートに行くべきですか？ローカルユーザーデータベースの管理を中心にサイトを構築して、Web APIをホストするサイトを用意することもできます。
この状況でWeb APIの問題は間違っていますか？そうでない場合は、WCF Webサービスよりも優れていますか？私の最終結果を達成する別の方法はありますか？