短い答えは一般的に「はい」ですが、もちろんもっと長い答えもあります:-)。
ユーザー情報 (nameidentifier 以外) を ACS とローカル データベース テーブルに格納することは理にかなっていますか?
はい、それは理にかなっています。ただし、最適化のために、一部のユーザー プロファイル情報のコピーを別の場所 (アプリのローカル) に保持する場合があります。ACS ルール情報は、トークンを取得するたびにローカル ストアの値を更新し、変更があったかどうかを確認する「マスター レコード」になります。
無制限のルール グループとその中にルールを作成できるように思えました。あれは正しいですか？
いいえ、「無制限」は大きな数字です。名前空間、証明書利用者、ルールの数には制限があります。ドキュメントを確認してください。ACS は、ルールの数を減らすのに役立つ「カスケード」変換もサポートしています。
例えば：
- 電子メール: eugeniop@mail.com -> 会社:Contoso
- 会社: Contoso -> 言語: 英語
2 番目のルールは、タイプ "Company"、値 "Contoso" のクレームが発行されるたびにトリガーされます。
次に、次のことができます。
- 電子メール: rob@othermail.com -> 会社: Contoso
"language" クレームは自動的に追加されます。
社内のさまざまな企業やユーザーとやり取りすることになります。会社ごとにルール グループを作成し、ユーザーごとにルールを作成することは賢明な選択でしょうか。
マルチテナント環境では、テナントごとに Relying Party を設定した方がよい場合があります。これは、http: //claimsid.codeplex.comで入手できるサンプル 7 (複数のパートナーとのフェデレーション) で行っていることです。
API は非常に堅牢で、サインアップ ページなどの結果としてこれを自動的に行うことができるようです。正しいですか、間違っていますか?
はい
ユーザーに関する情報を返すために ACS に対してクエリを実行することは実行可能であり、推奨されますか (たとえば、ユーザーがオフラインのときに電子メール アドレスをクエリして、何かについてのメッセージを送信するなど)
可能です。ただし、ACS には「ユーザー」という概念はありません。したがって、ルールからそれを解読する必要があります。「GetUserprofile(string user)」のような呼び出しはできません
レポート目的で ACS から大量の情報を取得できますか?
API は大量の情報をサポートしていますが、レポートを作成するには、独自のデータベースに情報を複製した方がよい場合があります。
最後に 1 つ: 現在の ACS ルール エンジンは非常に単純で、単純な変換 (およびカスケード) のみを行いますが、ルールが非常に複雑になる可能性がある今日の ADFS に比べれば何もありません (例: データベース ルックアップなど)。