web-dev-qa-db-ja.com

SOAP WS-UsernameTokenで認証されたリクエストの例

WS-UsernameToken仕様を使用してSOAPリクエストを認証しようとしていますが、ターゲットデバイスは常にアクセスを拒否しています。機能していないリクエストは次のようになります。ハッシュは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アプリケーションがあり、リクエストを生成してここに結果を投稿できる場合は、非常に感謝しています。

web-servicessoapws-securitydigestusernametoken
21
che

中核となるのは、名前空間のプレフィックスを定義し、それらを使用して各タグを強化することです。3つの名前空間を混在させ、デフォルトをハッキングしようとしても飛びません。 standard do cで使用されているプレフィックスを正確に使用することも良いことです-反対側が少しずさんな場合に備えて。

最後に大事なことを言い忘れましたが、できる限りフィールドにデフォルトの型を使用する方がはるかに良いです。したがって、パスワードについては、Nonceの場合はすでにBase64であるため、型をリストする必要があります。

XML経由で送信する前に、生成されたトークンが正しいことを確認し、wsse：PasswordのコンテンツがBase64（SHA-1（nonce + created + password））およびwsuの日時であることを忘れないでください： Createdは簡単に台無しにできます。したがって、プレフィックスと名前空間を修正し、XMLなしでSHA-1が正常に機能することを確認したら（リクエストを検証し、SHA-1計算のサーバー側を実行することを想像してください）、作成されたノンスなしでも真実の操作を行うことができます。 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>
19
ZXX

Metro 1.2のハッシュパスワードサポートとトークンアサーションパラメータ は、ダイジェストパスワードを持つUsernameTokenがどのように見えるかを非常にうまく説明しています。

ダイジェストパスワードのサポート

WSS 1.1 Username Token Profile を使用すると、ダイジェストパスワードをwsse:UsernameToken of a SOAPメッセージ。さらに2つのオプション要素がwsse:UsernameToken この場合： wsse:Nonceおよびwsse:Created。ノンスは、送信する各UsernameTokenに含めるために送信者が作成するランダムな値です。ナンスを「フレッシュネス」期間に結合するために、作成時間が追加されます。この場合のパスワードダイジェストは、次のように計算されます。

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>
9
Pascal Thivent

これを確認してください（パスワードはパスワードでなければなりません）：

<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>
4
Ladislav Mrnka

この投稿の可能性があります（ 署名、暗号化、TLS（SSL）を使用したSecure Metro JAX-WS UsernameToken Webサービス ）は、より多くの洞察を提供します。彼らが言及したように、「パスワードテキストまたはダイジェストパスワードがセキュリティで保護されたチャネルで送信されるか、トークンが暗号化されない限り、パスワードダイジェストもクリアテキストパスワードも実際の追加セキュリティを提供しない」

1
James Matt