Подробности реализации учетных данных сообщения WCF - PullRequest
Новая
       12

Подробности реализации учетных данных сообщения WCF

3 голосов
/ 28 октября 2009

Я ищу некоторые технические подробности о том, где фактическое имя пользователя + пароль (учетные данные) хранятся во время обмена сообщениями с использованием привязки WCF, как показано ниже. 

<bindings>
    <wsHttpBinding>
        <binding name="wsHttp">
            <security mode="TransportWithMessageCredential">
                <transport/>
                <message clientCredentialType="UserName" 
                         negotiateServiceCredential="false" 
                         establishSecurityContext="true" />
            </security>
        </binding>
    </wsHttpBinding>
</bindings>

Затем внутри клиентского приложения я вызываю эту услугу, передавая действительный набор кредитов, например, 

using (SupplierServiceClient client = new SupplierServiceClient()) {
            client.ClientCredentials.UserName.UserName = "admin";
            client.ClientCredentials.UserName.Password = "password";

            SupplierList = client.GetSupplierCollection();
}

Сначала я предположил, что WCF берет эти данные и помещает их в заголовок SOAP, но это не так из WSDL ... какая-нибудь помощь?

Редактировать

Ниже показано, как конфигурация безопасности для клиента выглядит в рабочей среде 

<security mode="TransportWithMessageCredential">
    <transport clientCredentialType="None" />
    <message clientCredentialType="UserName" establishSecurityContext="false" />
</security>

Ответы [ 2 ]

3 голосов
/ 29 октября 2009

Устанавливая UserNameCredentials, вы фактически используете профиль токена имени пользователя. Это приводит к добавлению токена в сообщение в виде заголовка SOAP. Заголовок SOAP будет выглядеть примерно так: 

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <env:Header>
        <wsse:UsernameToken>
            <wsse:Username>jdoe</wsse:Username>
            <wsse:Password>passw0rd</wsse:Password>
            <wsse:Nonce><!-- optional nonce here --></wsse:Nonce>
        </wsse:UsernameToken>
    </env:Header>
    <env:Body>
        <!-- body here -->
    </env:Body>
</env:Envelope>

Теперь я не совсем уверен, почему вы упоминаете WSDL. Маркер не появится в WSDL, хотя WSDL должен содержать надлежащие аннотации WS-Policy для операции. Это позволило бы потребителям WSDL обнаружить, что им действительно нужно отправить запрос имени пользователяPasswordToken.

Наконец, кто-то вызвал RequestSecurityToken (RST), но не должно быть (необходимости) вызывать RST, если вы просто используете простую аутентификацию UsernameToken. Единственный случай, когда необходимо задействовать RST, - это обмен токенами с Secure Token Server (STS) с использованием WS-Trust.

0 голосов
/ 28 октября 2009

Вот как может выглядеть пример сообщения SOAP: 

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
    <a:MessageID>urn:uuid:01d3a7d2-dc5a-42cf-acf0-3dd6bd50230e</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
    <a:To s:mustUnderstand="1">http://localhost:9999/Service1.svc</a:To>
  </s:Header>
  <s:Body>
    <t:RequestSecurityToken Context="uuid-7c240c06-c14b-42af-82dd-10f44f423928-1" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
      <t:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</t:TokenType>
      <t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType>
      <t:KeySize>256</t:KeySize>
      <t:BinaryExchange ValueType="http://schemas.xmlsoap.org/ws/2005/02/trust/spnego" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">YGsGBisGAQUFAqBhMF+gJDAiBgorBgEEAYI3AgIKBgkqhkiC9xIBAgIGCSqGSIb3EgECAqI3BDVOVExNU1NQAAEAAAC3shjiBgAGAC8AAAAHAAcAKAAAAAUBKAoAAAAPU0cyMjA1Nk1BVE1VVA==</t:BinaryExchange>
    </t:RequestSecurityToken>
  </s:Body>
</s:Envelope>
...