Совместимость с WCF Веб-служба с поддержкой Kerberos SPNego

У нас есть тестовый домен Windows Server 2012. Есть два компьютера, которые являются членами этого домена.

Один компьютер разрабатывается корпорацией Oracle и использует версию Linux на виртуальной машине. На этом компьютере размещена веб-служба с проверкой подлинности SPNego Kerberos, предположительно размещенная в IBM WebSphere.

Другой компьютер — это клиент Windows XP, размещенный на виртуальной машине Microsoft.

Мы создали SPN внутри Active Directory для аутентификации пользователей с помощью Kerberos.

Затем мы протестировали веб-службу с помощью браузера. Адрес WSDL идеально вернул данные SOAP.

Kerberos был отключен, чтобы можно было включить код клиентского прокси-сервера в клиент WCF 4.0, и снова включить его для проверки проверки подлинности.

Однако при попытке подключения к веб-службе с использованием методов, предоставляемых в прокси-сервере клиента, возникают всевозможные ошибки, связанные с безопасностью:

    The remote HTTP server did not satisfy the mutual authentication requirement.
    The remote server returned an error: (405) Method Not Allowed.

Ниже представлен клиентский файл App.config, используемый для подключения к веб-службе:

<configuration>
<system.serviceModel>
    <client>
        <endpoint address="http://oag:8080/pos/GetStoreConfigurationService"
                  binding="wsFederationHttpBinding"
                  bindingConfiguration="wsFederationHttpBinding_ESLGetStoreConfigurationBinding"
                  behaviorConfiguration="ServiceBehavior"
                  contract="ESLGetStoreConfigurationPortType"
                  name="wsFederationHttpBinding_ESLGetStoreConfigurationPort" >
            <identity>
                <servicePrincipalName value="http/oag:8080"/>
            </identity>
        </endpoint>
    </client>
    <bindings>
        <customBinding>
            <binding name="UsernameBinding">
                <binaryMessageEncoding />
                <security authenticationMode="Kerberos"  
                          requireSecurityContextCancellation ="false"
                          requireSignatureConfirmation="false" 
                          messageProtectionOrder ="EncryptBeforeSign"
                          requireDerivedKeys="false" 
                          enableUnsecuredResponse="true" 
                          allowInsecureTransport="true" 
                          securityHeaderLayout="Lax" >
                </security>
                <httpTransport authenticationScheme="Negotiate"  
                               transferMode="Buffered" 
                               maxReceivedMessageSize="67819876"/>
            </binding>
        </customBinding>
        <wsFederationHttpBinding>
            <binding name="wsFederationHttpBinding_ESLGetStoreConfigurationBinding" >
                <security mode="Message">
                    <message negotiateServiceCredential="true" 
                             establishSecurityContext="false"
                             algorithmSuite="Basic128" >
                        <issuer address="http://192.168.100.25" 
                                bindingConfiguration="UsernameBinding"
                                binding="customBinding">
                            <identity>
                                <dns value="WIN-7TN6ALB4TVK.oag-dev.sei"/>
                            </identity>
                        </issuer>
                    </message>
                </security>
            </binding>
        </wsFederationHttpBinding>
    </bindings>
    <behaviors>
        <endpointBehaviors>
            <behavior name="ServiceBehavior">
                <clientCredentials>
                    <windows allowedImpersonationLevel="Identification"/>
                </clientCredentials>
            </behavior>
        </endpointBehaviors>
    </behaviors>
</system.serviceModel>
<system.web>
    <identity impersonate="false" userName="oag-server" password="Password!"/>
</system.web>

Providing Network Credentials was also done in code; but alas, to no avail.

Спасибо.


person Hyland Computer Systems    schedule 31.08.2013    source источник


Ответы (1)


Лучше всего, если вы можете получить образец рабочей пары запрос/ответ (или несколько сообщений в случае spnego), сгенерированных одним стеком (например, клиент и сервер - это java). Тогда это будет игра по настройке WCF на одно из этих сообщений. В настоящее время слишком много неизвестного. Кроме того, AFAIK SPNEGO — это протокол, поддерживаемый только WCF (= согласование учетных данных Windows на уровне сообщений SOAP), поэтому сервер может использовать что-то еще.

Конкретная ошибка, которую вы получили, может означать, что сервер использует SOAP11, когда вы отправляете SOAP12 (например, вам может потребоваться базовая привязка http). Но любое изменение конфигурации должно быть сделано в контексте знания того, какой протокол SOAP разрешен сервером.

person Yaron Naveh    schedule 31.08.2013
comment
Спасибо за ваш быстрый и лаконичный ответ. Я свяжусь с Oracle и узнаю, какую именно версию SOAP они используют, и на самом деле укажу им на этот пост для дальнейшего размышления. - person Hyland Computer Systems; 01.09.2013