Немного предыстории:
Моя компания (действующая как поставщик услуг) в настоящее время поддерживает единый вход с нашими федеративными партнерами (IdP) через AD FS 2.0. Каждый партнер настраивается как поставщик утверждений, и создаются правила преобразования входящих заявлений, которые будут отправляться в наше веб-приложение.
После аутентификации токен, содержащий утверждения, отправляется в нашу конечную точку STS (например, https://sts.companyname.ca/adfs/ls), где утверждения преобразуются и отправляются на URL-адрес нашего веб-приложения (например, https://companyname.ca/externalsignin.aspx) и обрабатывается промежуточным программным обеспечением OWIN, которое предшествует поиску / созданию учетной записи.
Все это прекрасно работает. Теперь перед нами стоит задача интегрировать единый вход Azure AD в систему, чтобы упростить процесс адаптации.
Я дошел до создания нового каталога в Azure и создания в нем нового приложения. Я пометил приложение как мультитенантное и установил URL-адрес ответа на "https://sts.companyname.ca/adfs/ls ". В клиенте AD FS 2.0 на нашем сервере я создал нового поставщика утверждений под названием «AzureAD» и импортировал URL-адрес метаданных из раздела конечных точек приложения на консоли Azure. Тестирование входа в систему с помощью электронной почты от нашего арендатора сработало отлично. Проблема заключается в том, что при тестировании с использованием электронной почты организации от другого клиента проверка подлинности завершается ошибкой с сообщением о неверном запросе:
После некоторого исследования выяснилось, что это произошло из-за того, что форма входа была создана для login.microsoftonline.com/tenantid, тогда как login.microsoftonline.com/common следует использовать для мультитенантных приложений. Поэтому я повторно импортировал метаданные из https://login.microsoftonline.com/common/federationmetadata/2007-06/federationmetadata.xml и обновлен. 
Теперь я действительно вижу запрос на согласие, когда вхожу в систему с другой учетной записью организации, но после аутентификации сообщение на sts.companyname.ca/adfs/ls не выполняется, поскольку токен был подписан для "sts.windows.net/0000-" 000000-000000-0000 ", но поставщик утверждений в AD FS определяется заполнителем sts.windows.net/{tenantid}. 
Я понятия не имею, как заставить эту работу работать только с одним поставщиком утверждений Azure с шаблонной конечной точкой (также я могу добавить только 1 поставщика утверждений Azure, поскольку все они используют одни и те же сертификаты подписи).
Любая помощь в преодолении этого препятствия будет принята с благодарностью.
