Пример запроса SOAP, заверенного с помощью WS-UsernameToken

18

Я пытаюсь выполнить аутентификацию SOAP-запроса с использованием спецификации WS-UsernameToken, но целевое устройство всегда отказывает в доступе. Мой нерабочий запрос выглядит следующим образом. (Пароль, который я пытаюсь использовать, - system .)

<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope">
 <Header>
  <Security xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <UsernameToken>
      <Username>root</Username>
      <Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">EVpXS/7yc/vDo+ZyIg+cc0fWdMA=</Password>
      <Nonce>tKUH8ab3Rokm4t6IAlgcdg9yaEw=</Nonce>
      <Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2010-08-10T10:52:42Z</Created>
    </UsernameToken>
  </Security>
 </Header>
  <Body>
    <SomeRequest xmlns="http://example.ns.com/foo/bar" />
  </Body>
</Envelope>

То, что я ищу, является аналогичным примером запроса, но с подлинным токеном, который действительно работает. Например, если у вас есть приложение gSOAP, которое использует этот токен, и может генерировать запрос и публиковать результат здесь, я был бы очень благодарен.

    
задан che 10.08.2010 в 13:39
источник

4 ответа

16

Основная задача - определить префиксы для пространств имен и использовать их для укрепления каждого тега - вы смешиваете 3 пространства имен и просто не летаете, пытаясь взломать по умолчанию. Также полезно использовать точно префиксы, используемые в standard do c - на всякий случай, если другая сторона немного небрежно.

И последнее, но не менее важное: гораздо лучше использовать типы по умолчанию для полей всякий раз, когда вы можете - поэтому для пароля вам нужно указать тип, для Nonce это уже Base64.

Убедитесь, что вы проверили правильность сформированного токена перед отправкой через XML и не забыли, что содержимое wsse: Пароль Base64 (SHA-1 (nonce + created + password)) и дата-время в wsu: Созданный может легко повредить вам. Поэтому, как только вы исправите префиксы и пространства имен и убедитесь, что SHA-1 работает отлично без XML (просто представьте, что вы проверяете запрос и выполняете серверную часть расчета SHA-1), вы также можете выполнить правдивое создание и даже без Nonce. Oh и Nonce могут иметь разные кодировки, поэтому, если вы действительно хотите заставить другую кодировку, вам придется искать в пространстве имен wsu.

<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu= "...">
  <S11:Header>
  ...
    <wsse:Security>
      <wsse:UsernameToken>
        <wsse:Username>NNK</wsse:Username>
        <wsse:Password Type="...#PasswordDigest">weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==</wsse:Password>
        <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
        <wsu:Created>2003-07-16T01:24:32</wsu:Created>
      </wsse:UsernameToken>
    </wsse:Security>
  ...
  </S11:Header>
...
</S11:Envelope>
    
ответ дан ZXX 24.08.2010 в 14:15
  • pst, пространство имен S12 не определено: <S12: Envelop xmlns: S11="..." должно быть <S11: Envelop или xmlns: S12="..." nice answer thought, thanks –  Eli Algranti 25.02.2013 в 23:40
8

Параметры поддержки Hash Password и параметров подтверждения токена в Metro 1.2 очень хорошо объясняют, что выглядит UserToken с Digest Password как:

  

Поддержка паролей дайджеста

     

WSS 1.1 Username знак   Профиль позволяет переваривать пароли   отправляться в wsse:UsernameToken от   SOAP. Еще два дополнительных   элементы включены в    wsse:UsernameToken в этом случае:    wsse:Nonce и wsse:Created .   nonce - случайное значение, которое   отправитель создает для включения в каждый   UsernameToken, что он отправляет.   время создания добавляется для объединения   nonces к периоду «свежести».   В этом случае Password Digest   рассчитывается как:

Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )
     

Это то, как UsernameToken с   Пароль дайджеста выглядит следующим образом:

<wsse:UsernameToken wsu:Id="uuid_faf0159a-6b13-4139-a6da-cb7b4100c10c">
   <wsse:Username>Alice</wsse:Username>
   <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">6S3P2EWNP3lQf+9VC3emNoT57oQ=</wsse:Password>
   <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">YF6j8V/CAqi+1nRsGLRbuZhi</wsse:Nonce>
   <wsu:Created>2008-04-28T10:02:11Z</wsu:Created>
</wsse:UsernameToken>
    
ответ дан Pascal Thivent 23.08.2010 в 03:19
4

Проверьте это (пароль должен быть паролем):

<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-6138db82-5a4c-4bf7-915f-af7a10d9ae96">
  <wsse:Username>user</wsse:Username>
  <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">CBb7a2itQDgxVkqYnFtggUxtuqk=</wsse:Password>
  <wsse:Nonce>5ABcqPZWb6ImI2E6tob8MQ==</wsse:Nonce>
  <wsu:Created>2010-06-08T07:26:50Z</wsu:Created>
</wsse:UsernameToken>
    
ответ дан Ladislav Mrnka 17.08.2010 в 23:30
1

Может быть, это сообщение ( Secure Metro JAX-WS UsernameToken Web Service с подписью, шифрованием и TLS (SSL) ) обеспечивает более глубокое понимание. Как они упоминали «Помните, что если пароль защищен или пароль не передан по защищенному каналу, или он не зашифрован, ни пароль, ни пароль cleartext не обеспечивают реальной дополнительной безопасности».

    
ответ дан James Matt 23.05.2013 в 05:58