OAuthをActive Directoryで使用する方法
REST WCFサービスを作成しており、OAuthを使用して各ユーザーのリクエストを認証したいと考えています。ユーザーアカウントはActive Directoryに保存されているので、クライアントアプリケーションのADログイン名。リクエストヘッダーとともにその情報を渡すことができます。
私はoauthをFatSecretと共に使用しましたREST APIを以前に使用したので、方法認証が機能します。
基本的に、ユーザーへの秘密キーの割り当てと保存の処理方法、およびユーザーの秘密キーをADログイン名に関連付ける方法についてはわかりません。
ユーザーのADログイン名とシークレットキーのマッピングテーブルを保持している別のデータベースがあり、リクエストが来たときにそのテーブルでシークレットキーを検索するだけですか？
受信リクエストが、ログイン名が受信リクエストに含まれているユーザーから実際に送信されていることを確認するにはどうすればよいですかFiddlerを開いて別のユーザーのADログイン名でリクエストを作成することはできません？
OAuthが他の方法では実現できないことを教えてくれます。WCF+ Restは、WIFにバンドルされているクレームベースの認証で非常にうまく機能します。
WCFはASP.NETを使用していることを示唆しているため、サーバー側で Windows Identity Foundation（WIF） を使用することをお勧めします。チェックアウト 詳細はこの電子ブック
次に、ADをアプリに公開する方法が必要です。 ADFSv2を使用 は、Windows 2008 R2では無料です。セッションリプレイ攻撃から保護するSQLインストールを確認してください。
Fiddlerから資格情報をコピーして貼り付けることは、完全に止めることはできません。 HTTPSは役立ちますが、この問題を本当に調査したい場合は Stackoverflowに関するこのQ＆A を参照してください。
モバイルアプリケーションをサポートしている場合は、OAuthが最適です。このようにして、モバイルアプリは、デバイス上でユーザーパスワードを持ち歩く必要なく、アクセストークンを保存できます。基本的なシナリオは、アプリケーションがゲートウェイからトークンを要求し、ユーザーに資格情報（userid/pw）の入力を求め、ADに対して検証します。 ADが検証されると、ゲートウェイは（おそらくアクセスコードの交換を介して）アクセストークンをアプリに発行します。アプリはトークンを使用してサービスをリクエストします。サービスを提供するアプリケーションは、ゲートウェイをチェックしてトークンを確認し、アクセストークンからユーザー名へのマッピングを取得できます。このようにして、ゲートウェイはマッピングを保持しますが、アクセストークンが有効な期間のみ保持します。