Пример запроса SOAP, аутентифицированного с помощью WS-UsernameToken - PullRequest
Новая
       101

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

21 голосов
/ 10 августа 2010

Я пытаюсь аутентифицировать запрос 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, которое использует эти токены и может сгенерировать запрос и опубликовать результат здесь, я был бы очень признателен.

Ответы [ 4 ]

19 голосов
/ 24 августа 2010

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

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

Убедитесь, что вы проверяете, что сгенерированный токен является правильным, прежде чем отправлять его через XML и не 'Не стоит забывать, что содержимое wsse: Password - Base64 (SHA-1 (nonce + made + password)), а дата-время в wsu: Created может легко вас испортить.Поэтому, как только вы исправите префиксы и пространства имен и убедитесь, что ваш 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>
9 голосов
/ 23 августа 2010

Параметры поддержки хэш-пароля и подтверждения токена в Metro 1.2 очень хорошо объясняют, как выглядит имя пользователя с паролем дайджеста:

Поддержка паролей Digest

Токен пользователя WSS 1.1 Профиль позволяет переваривать пароли к быть отправлено в wsse:UsernameToken из SOAP сообщение. Два дополнительных элементы включены в wsse:UsernameToken в этом случае: wsse:Nonce и wsse:Created. одноразовый номер является случайным значением, которое отправитель создает для включения в каждый Имя пользователя взято, что оно отправляет. время создания добавляется для объединения одноразовый период времени "свежести". Дайджест пароля в этом случае рассчитывается как: 

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

Вот как взяли имя пользователя Дайджест пароля выглядит так: 

<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>
4 голосов
/ 18 августа 2010

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

<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>
1 голос
/ 23 мая 2013

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

...