開発中のシステムでクレーム対応セキュリティを使用する可能性を調査しようとしています。これらすべてについて読むほど、混乱します。それで、私は私がすでに知っていることを説明することに決めました、そして私はあなたに私の声明を訂正するように頼むでしょう。使用されているすべてのプロトコルとテクノロジーに迷いました。
以下は私のシステムの簡単な図です。2つのサービスがあります。WCFを使用して実装されたRESTサービスとASPMVCWebアプリケーションです。両方のサービスで信頼できるID発行者となるSTSを取得する必要があることはわかっています。特定のレベルのアクセスを区別するためにロールを使用します。
STS機能は、ADFS（またはそれに加えてさらに必要なものがある）またはWSO2IdentityServerを使用して実現される場合があります。STSとは、認証を希望するクライアントから資格情報を取得し、一連のクレームを返すサービスを意味します（他の情報の横にユーザーに割り当てられた役割が含まれます）。この一連のクレームは、トークンの形式になります。
この図では、さまざまなクライアントタイプをさまざまな色でマークしています。いいえ、使用されると思われるプロトコル/フォーマットについて説明します。フォーマットとは何か、プロトコルとは何かについて、私はかなり混乱しています。しかし、試してみましょう：
赤いシナリオ：リッチWCFクライアントがRESTサービスに対して認証する
STSへの要求は、WS-trustを使用して送信されます（ADFSまたはWSO2に他の可能性はありますか？）。クレデンシャルは、X.509証明書、パスワードダイジェスト、Kerberos、Windows認証、SAMLトークン（これはフェデレーションシナリオで使用されます）など、いくつかの形式のいずれかである可能性があります。
クライアントへの回答は、OAuthプロトコルを介して送信されるSWTトークンの形式になります。これは、RESTサービスに対して認証を試みるときに行う方法だからです。
- ADFSはSWTとOAuthをサポートしていますか？情報が見つかりませんでした。
次に、クライアントはSTSから受信したトークンをRESTサービスに送信します。繰り返しますが、これはOAuthのSWTトークンです。
クライアントコードに関しては、すべてWindowsIdentityFrameworkを使用して簡単に実装できると思います。
グリーンシナリオ：リッチAndroidクライアントがRESTサービスに対して認証
すべてのプロトコル/フォーマットは前のシナリオと同じです。これを簡単に実装できるフレームワークはありますか？
青いシナリオ：WebブラウザーのユーザーがASPMVCWebアプリケーションに対して認証します
ユーザーはWebアプリのメインページに移動します。Webアプリは、彼がまだ認証されていないことを検出したため、STSのサインオンページにリダイレクトします（サインオンページはSTSにありますよね？）。
3. STSはユーザーを認証し、SAMLトークンとリダイレクトを含むHTTP応答をwebappに送信します。したがって、ここではWS-TrustsではなくHTTPが使用されます。
別の質問。このWebブラウザーのシナリオでは、クライアントのマシンにCookieが書き込まれます。したがって、クライアントがもう一度認証を試みるときはいつでも、トークンを取得するためにCookieをstsに送信するだけです。資格情報を送信する必要はありません。STSは、実際の認証ロジックを使用せずに、Cookieに基づいてトークンを発行します。その声明は正しいですか？