私はかなり珍しいシナリオの認証スキームを考え出しています。多対多の認証パターン
私は複数のAzure Active Directory（潜在的には数十件）と複数のWeb APIサービスを持っています。 お客様はいずれかのADにサインイン/ログインし、いずれかのサービスでリクエストを認証できるようになります。
簡単な解決方法では、私のすべてのサービスをすべてのADに関する情報で設定する必要があります。 この多対多の関係は、私が避けようとしているものです。
正規化されたトークンを発行する集中トークン交換サーバーを構築するソリューションについて考えましたが、この方法がどれほど安全であるかわからず、むしろ代わりに「すぐに使用できる」ソリューションを使用したいと思います自分自身を実装する。
どうすればこの問題を解決できますか？
multi-tenancy support of Azure ADは、お客様のシナリオを解決するために設計されています。
まず、Azure ADにマルチテナントアプリケーションとしてサービスを公開します。その後、テナントのディレクトリ管理者は、同意フローを参照してアプリケーションをサブスクライブします。
サービスでTokenValidationParametersのValidateIssuerプロパティをfalseに設定して、トークンの発行者のチェックを無効にする必要があります。
ユーザーは、のいずれかのディレクトリにサインインして、アプリケーションに同意することができます。これを指定するディレクトリに限定するには、IssuerValidatorデリゲートをTokenValidationParametersに追加することができます。
IssuerValidator = (issuer, token, params) =>
{
if (_db.FindIssuer(issuer) != null)
return issuer;
else
throw new SecurityTokenInvalidIssuerException("Not a valid issuer");
},
原則としてあなたは正しいですが、それは私のシナリオではありません。 いくつかの追加の要件があり、互いに衝突する可能性があります。 1.複数のテナントで同じ電子メールアドレスを使用できるようにしたい（問題はないかもしれませんが） - 2.私は、どのADを使用してサインインするかを選択できないようにしたい私はそれらを私が選択したものにリダイレクトしたい。 3.申し込み時に同意ページを表示したくありません。ユーザーがプロバイダに直接サインアップしているという気持ちを作りたいと思っています。 –
ユーザーがどのディレクトリにサインインしているのか、本当にわからないのです。発行されたトークンは、 'tenantid'クレームを除いて同じになります。ユーザはサインインしたディレクトリを選択せず、単にクレデンシャルを入力するだけで、Azure ADはドメインに基づいて正しいディレクトリを選択します。テナント管理者がグローバルな同意を行った場合は、すべてのユーザーに同意ページが表示されません。 – MvdD
カスタムログインページを作成し、Azure AD Graph APIを呼び出して認証トークンを取得する場合は、あなたのニーズについてもう少し詳しく説明し、デフォルトのマルチテナントがあなたの要件に合わない理由を説明するために質問を編集してください。しかし、あなたが記述しているのはマルチテナントアプリケーションです – Thomas
マルチテナントアプリケーションのようですか？ Azure ADでマルチテナントアプリケーションを構築してみましたか？ – Thomas
私はそれを調べました。問題は、ユーザーがサインインする広告を選択できないようにすることです。ユーザーがサインインするようにリダイレクトするサービスによって決定される必要があります。 –
ユーザーは選択しません。電子メールを入力し、電子メールに基づいて、組織のログインページにリダイレクトされます。 – Thomas