Конечная точка WS-Trust MEX в IdentityServer 2 возвращает HTTP 400 для запросов GET

Question

Мы настроили IdentityServer 2 для обеспечения возможности объединения идентификаторов в Azure AD (для Office 365 и т. Д.). Это имеет конечную точку WS-Federation для пассивного потока запросов и WS-Trust для активных клиентов. Конечная точка MEX для WS-Trust должна возвращать WSDL для WS-Trust SOAP в ответ как на POST (при использовании Lync), так и на GET (при использовании входа в Windows 10). К сожалению, он возвращает HTTP 400: ws-trust system.servicemodel.protocolexception "Существует проблема с XML, который был получен из сети".

Как видно из источника: https://github.com/IdentityServer/IdentityServer2/blob/master/src/Libraries/Thinktecture.IdentityServer.Protocols/WSTrust/TokenServiceHostFactory.cs

var host = new WSTrustServiceHost(config, baseAddresses);

// add behavior for load balancing support
host.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());

// modify address filter mode for load balancing
var serviceBehavior = host.Description.Behaviors.Find<ServiceBehaviorAttribute>();
serviceBehavior.AddressFilterMode = AddressFilterMode.Any;
serviceBehavior.IncludeExceptionDetailInFaults = true;

Экземпляр System.ServiceModel.Security.WSTrustServiceHost используется для обработки вызовов WS-Trust и обработки его метаданных. Проверяя ServiceMetadataBehavior, который добавляется по умолчанию в WSTrustServiceHost ctor, мы видим, что он включает метаданные для GET как по HTTP, так и по HTTPS. http://referencesource.microsoft.com/#System.ServiceModel/System/ServiceModel/Security/WSTrustServiceHost.cs,8c80389f2532b060,references

Поэтому я немного запутался, почему https://myhost.com/issue/wstrust/mex возвращает метаданные при попадании в POST, но возвращает 400, когда вы отправляете GET. Исключение выдается в EnqueueMessageAsyncResult.CompleteParseAndEnqueue() в System.ServiceModel http://referencesource.microsoft.com/#System.ServiceModel/System/ServiceModel/Channels/HttpPipeline.cs,b34867references77

Любая помощь с благодарностью!

Answer 1

Для других, застрявших в том же месте, я явно настроил TokenServiceHostFactory для ответа на HTTP GET.

// added for AAD Windows 10 sign in - device requests metadata with GET
ServiceMetadataBehavior metad = host.Description.Behaviors.Find<ServiceMetadataBehavior>();
if (metad == null)
    metad = new ServiceMetadataBehavior();
for (int i = 0; i < baseAddresses.Length; i++)
{
    // there will be two bindings: one for http and one secure
    switch (baseAddresses[i].Scheme)
    {
        case "http":
            metad.HttpGetEnabled = true;
            metad.HttpGetUrl = new Uri(baseAddresses[i], "/issue/wstrust/mex");
            break;
        case "https":
            metad.HttpsGetEnabled = true;
            metad.HttpsGetUrl = new Uri(baseAddresses[i], "/issue/wstrust/mex");
            break;
    }
}

Answer 2

Я выполнил указанные выше действия, чтобы интегрировать IdentityServer2 с AzureAD. Мы провели тест с помощью средства тестирования подключения Microsoft для единого входа, получив исключение, как показано ниже. Из исключения кажется, что произошла ошибка при чтении мета-конечной точки.

Сведения об исключении: Сообщение: Ссылка на объект не установлена ​​на экземпляр объекта. Тип: System.NullReferenceException Трассировка стека: в Microsoft.M365.RCA.Services.AdfsPolicyParser.FromServiceDescription(ServiceDescription wsd, String bindingName) в Microsoft.M365.RCA.Services.AdfsMetadataClient.GetMetaData(String mexEndpointUrl365) в Microsoft.RCAndpointUrl365. ConnectivityTests.SingleSignOnTestHelper.GetAdfsMetadata(RcaTestContext parentContext, String mexUrl, IAdfsMetadataClient metadataClient, IWebExceptionAnalyzer webExAnalyzer, AdfsMexInfo и adfsMetadata) в Microsoft.M365.RCA.ConnectivityTests.SingleSignOnTopLevelTest.<>c__DisplayClass8_0.b__0() в Microsoft.M365.RCA.ConnectivityTests.Common.RcaTestContext.ExecuteSteps(TestSuccessOperator successOperator, Func 1[] stepFunctions) at Microsoft.M365.RCA.ConnectivityTests.SingleSignOnTopLevelTest.GetAndValidateAdfsMetadata(RcaTestContext parent, DomainRegistrationInfo registration) at Microsoft.M365.RCA.ConnectivityTests.Common.RcaTestContext.ExecuteSteps(TestSuccessOperator successOperator, Func1 [] stepFunctions) в Microsoft.M365.RCA.ConnectivityTests.SingleSignOnTopLevelTest.PerformTestReally () в Microsoft.M365.RCA.ConnectivityTests.Test.PerformTest () в Microsoft.M365.RCA.ConnectivityTests.TopLevelTest.PerformTest. Threading.Tasks.Task`1.InnerInvoke() в System.Threading.Tasks.Task.Execute()--- Конец трассировки стека из предыдущего места, где было сгенерировано исключение --- в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(задача задачи) в Microsoft.M365.RCA.Website.TestExecutionManager.TestCompleted(данные TestExecutionData, ITopLevelTest topLevelTestata, TestLogging

Answer 3

Для тех, кто застрял с этой проблемой, есть обходной путь: взять файл метаданных ADFS и затем изменить конечные точки WS-TRUST1.3, смешанные с именем пользователя и сертификатом, с вашей собственной реализацией WS-Trust13. Похоже, что Microsoft поддерживает только свой собственный файл метаданных ADFS. Я тоже обратился в службу поддержки Microsoft, но они еще не ответили. Хотя они признают, что синтаксический анализ метаданных может быть жестко запрограммирован в ADFS и не согласован со стандартной реализацией метаданных WS-TRUST13.

              <wsdl:port name="CertificateWSTrustBinding_IWSTrust13Async" binding="tns:CertificateWSTrustBinding_IWSTrust13Async">
        <soap12:address location="https://sts.gemalto.com/adfs/services/trust/13/certificatemixed"/>
        <wsa10:EndpointReference>
            <wsa10:Address>https://sts.gemalto.com/adfs/services/trust/13/certificatemixed</wsa10:Address>
        </wsa10:EndpointReference>
    </wsdl:port>
    <wsdl:port name="UserNameWSTrustBinding_IWSTrust13Async" binding="tns:UserNameWSTrustBinding_IWSTrust13Async">
        <soap12:address location="https://sts.gemalto.com/adfs/services/trust/13/usernamemixed"/>
        <wsa10:EndpointReference>
            <wsa10:Address>https://sts.gemalto.com/adfs/services/trust/13/usernamemixed</wsa10:Address>
        </wsa10:EndpointReference>
    </wsdl:port>