アプリに独自のユーザー名/パスワード スキームを実装する代わりに、Windows Azure ACS を検討しています。これは一般に公開されている Web サイトになります。
Google や Facebook などの SSO プロバイダーを使用するだけでなく、Windows Azure ACS を使用してユーザー名/パスワード認証をサポートできますか?
プロバイダーとして Active Directory をサポートしていることがわかります。私は常に Active Directory を「エンタープライズ」プロバイダーと考えてきたので、これが正しいことかどうかはわかりません。
Windows Azure ACS は、必要な形式でのユーザー名/パスワード認証をサポートしていません。Shahinはそれを詳細に概説しました。
あなたのオプションは実際には次のとおりです。
ドメイン コントローラー オプションを使用してデプロイされた従来のオンプレミス Active Directory は確かに非常にエンタープライズ向けですが、WAAD はクラウド内の同じものの正確なコピーではありません。実際に試してみることをお勧めします。WAAD Graph APIを使用すると、 WAAD でのユーザー管理を完全に自動化できます。
2 番目のオプションは、IdSVR に基づいています。これは、フル機能の Identity Server と Security Token Service です。セキュリティのベスト プラクティスに基づいて開発されており、非常に簡単に拡張できます。ユーザー管理 (ユーザー登録、パスワードのリセットなど) をすぐにサポートするわけではありませんが、ASP.NET MVC 4 アプリケーションです。したがって、この機能を自分で簡単に追加できます。実際には、User Management API と UI に対して計画されているオープンな拡張機能があります。
WAAD と IdSVR はどちらも ACS とうまく統合されるため、独自のログインと共にソーシャル ID をシームレスにサポートできます。
まだベータ/プレビュー段階にある別のサービスは、SocialSTS プロジェクトです。これは Azure ACS の一種の拡張機能であり、アクセス コントロール サービスにさらに多くの ID プロバイダー (LinkedIn、Twitter、GitHUB、Amazon ログインなど) を追加できるように設計されています。
サービス IDを使用して ACS で直接認証できますが、このページで説明されているように、これらはエンド ユーザー認証に使用することを意図したものではありません。
サービス ID は、エンドユーザーの資格情報として使用することを意図していません。ACS では、サービス ID は、OAuth WRAP プロトコルを介して REST Web サービス シナリオで最も一般的に使用されます。この場合、クライアントは SWT トークンを ACS から直接要求して、Web サービスに提示します。
これが ACS からトークンを直接取得する唯一の方法だと思います。