私は現在、Azure ACS とクレームベースの認証の組み合わせと、カスタム STS を使用するオプションを理解しようとしていますが、(残念ながら少数の) 情報ソースをゆっくりとしか理解していません。これにさらに時間を費やす前に、私の計画が可能かどうかを確認したいと思います. 従業員と顧客の両方がインターネット経由でアクセスしている複数の Azure ロール (Web + ワーカー) があります。さらに、従業員はローカル ネットワーク内からこれらの役割とデスクトップ アプリにアクセスします。
ユーザー データは 2 つのソースから取得されます。私たちの Azure アプリには、顧客と従業員に関するユーザー データがあり、従業員からの (ローカル) AD のみがあります。
ログイン エクスペリエンスを可能な限り効率的 (かつ人間工学的) にするために、ローカル ネットワーク経由でアクセスした場合、従業員はデスクトップ アプリ (Windows ユーザー プロファイル コンテキストにより自動的に) と azure の両方で自動的に認証 (Windows 統合認証?) される必要があります。アプリ（できればログインページなし）。一方、顧客は、Azure アプリにアクセスするときにユーザー資格情報を入力する必要がありますが、異なる "資格情報ソース" を決定する必要はなく、ユーザー名とパスワードの形式を取得するだけです。言い換えると
- 従業員がローカル ネットワークから Azure アプリにアクセス -> 統合認証 / AD データによる自動ログイン
- 従業員がインターネットから Azure アプリにアクセス -> ユーザー名とパスワードのフォーム
- 顧客がインターネットから Azure アプリにアクセス -> ユーザー名とパスワードのフォーム
この質問を書いているときに、さらに 2 つのことが頭に浮かびました。
1）ソース/クッキー/ウィザードリに基づいて自動ログインすることさえ可能ですか、それとも「資格情報ソース」を選択するためにユーザーが手動で選択する必要がありますか?
2) Azure ACS が、ユーザー名 X の AD アカウントが Azure アプリ ユーザー Y と同じであることを「認識」している場合、どちらがログインするかは重要ですか? アプリはどちらのログイン ルートでも同じクレーム データにアクセスできますか?