問題タブ [digest-authentication]

このカスタム認証モジュールと同様のコードを拡張することで、WSSE 認証を実装すると見積もっています。

そのコードは ASP.NET でホストされ<system.web><httpModules>、サイトの web.config ファイルのセクションに登録されます。モジュールのインスタンスは、IIS 内の何らかのコードによって作成され、要求を渡し、しばらく存続してから破棄されます。

WSSE を実装するには、リプレイ アタックを防ぐために、発行されたチャレンジ (「ノンス」) を追跡する必要があります。

そのため、最近の課題をどこかに保存して、受信リクエスト間でコレクションが持続し、すべてのモジュール インスタンスからアクセスできるようにする必要があります。

最も便利で (C# から使用し、新しいサーバーに展開するという点で)、そのための最も一般的なソリューションは何ですか?

javaを使用してAPI（ http://zootool.com/api/docs/add ）を介してzootoolページにページを追加しようとしています。このために、ダイジェスト認証を使用する必要があります。

ページの取得を承認するためのphpの例を示します。

しかし、これはJavaでページを追加するためにどのように行われますか？検索したところ、apache commons HttpClientが役立つ可能性があることがわかりましたが、頭を包み込むことができないようです。

私は試した：

（api-manualに記載されているように）パスワードをsh1-hashしようとしましたが、うまくいきませんでした。私のコードは、対応すべき課題を見つけることができないようです。

APIキー、ユーザー名、パスワードは正しいです。

更新プリエンプティブダイジェスト認証を使用する必要があることは比較的確信していますが、apacheによる回避策を試してみると、401と「認証エラー：ダイジェスト認証のチャレンジが必要ですが見つかりません」-Javaからの警告が表示されます。私が使用するコードは次のとおりです。

DigestSchemeパラメーターに意味のある値を指定する必要がありますか？私も正しい方向に進んでいますか？

/アンドレ

そこで、RESTAPIにダイジェストHTTP認証を使用することにしました。私はそれをグーグルで検索し、それを行う方法の例を含むPHPマニュアルのエントリを見つけました。そのため、スクリプトをコピーしてサーバーのindex.phpに配置し、ブラウザーでページを開きます。クレデンシャルを入力した後、ブラウザーは再度クレデンシャルを要求し、クレデンシャルを入力する無限ループに陥ります。スクリプトは以下に含まれており、ここにあります。

例7ダイジェストHTTP認証の例

基本認証も試しましたが、それは完璧に機能しました。

例6基本HTTP認証の例

$_SERVER['PHP_AUTH_DIGEST']いつも空っぽのようです。

スクリプトに何か問題がありますか、それとも私の環境がファンキーですか？もしそうなら、どうすれば修正できますか？

編集：スクリプトに問題はありません。障害はサーバーにあります。何が原因であるかを誰かが知っているなら、私に知らせてください。

リモートDBを管理するために小さなRESTサーバーを実装する必要がありますが、特別なことは何もありません。このサーバーはイントラネット環境で実行する必要があるため、セキュリティは重要な問題ではありません。ユーザーをフィルタリングして適切なリソースにリダイレクトするだけです。

このコード (Microsoft のサイトから取得) はサーバー側から完全に機能し、listener.GetContext()が返されたときに、User オブジェクトからユーザー名とパスワードを確認し、リクエストの処理方法を確立できます。最初のlistener.AuthenticationSchemes = AuthenticationSchemes.Basicを変更します

期待どおりに機能しなくなり、基本認証スキーマが効果的に機能しなくなります。listener.GetContext()呼び出しは戻りません。HttpListener はすべてのリクエストをブロックするように見え、クライアント側からは引き続きユーザー名とパスワードの入力を求められます。ローカル ユーザー、ローカル管理者、ドメイン ユーザー、ドメイン管理者、約 500 のファンタジー名を試しましたが、何も機能しません。GetContext() はもう戻りません。手伝って頂けますか？

前もって感謝します。

L.

RestEasyを使用してRESTサーバーを開発し、org.jboss.resteasy.mockMockDispatcherFactory単体テストでサービスをテストするためにモックディスパッチャー（）を使用しています。私のサービスにはダイジェスト認証が必要であり、それをテストの一部にします。

私の各サービスはパラメータを受け入れ@Context SecurityContext securityContextます。

SecurityContextセキュリティメソッドが正しく機能することをテストできるように、ディスパッチャに偽物を挿入する方法はありますか？

HTTPダイジェスト認証を必要とするリクエストを送信しようとしています。

jQueryでダイジェストは可能ですか？

もしそうなら、これはそれを行う正しい方法に近いですか？現在は機能していません。

DIGEST 認証を機能させるには、助けが必要です。Apache 4.1 ライブラリを使用しています。ログインしようとすると取得します。

スレッド「メイン」の例外 javax.net.ssl.SSLPeerUnverifiedException: ピアが認証されていません

Asterisk SwitchVox Dev Extend API にログインしようとしています。xml 投稿を送信するだけで、情報が返されます。私は確かに正しいユーザー名/パスワードを持っており、これをPERLスクリプトで動作させましたが、JAVAでは取得できません.

これが私のコードです

}

Asteriskサーバーに接続して発信を試みるSIPユーザーエージェントアプリケーションを開発しています。JAINSIPAPIのNIST実装を使用しています。

アプリケーションがそれ自体を登録すると、401（Unauthorized）応答がWWW-Authenticateヘッダーでアプリケーションにチャレンジします。アプリケーションは、Authorizationヘッダーを次のREGISTERリクエストに挿入します。今回、Asteriskは200（OK）応答を返します-登録は成功します。

アプリケーションがINVITE要求を送信すると、Asteriskは407（プロキシ認証が必要）応答で応答します。今回の応答には、Proxy-Authenticateヘッダーが含まれています。私のアプリケーションは再びINVITEを送信しますが、今回はAuthorizationヘッダーを使用して、Asteriskが同じ407（プロキシ認証が必要）応答で応答します。

送信されるSIPメッセージは次のとおりです（「>>」は送信メッセージを示し、「<<」は受信メッセージを示します）。

>>

<<

<<

>>

<<

<<

>>

>>

<<

>>

>>

<<

Authorizationヘッダーは、どちらの場合もまったく同じ方法で作成されます（実行される同じコード）。「digestURI」にリクエストのリクエストURIを使用しています。Authorizationヘッダーの代わりにProxy-Authorizationヘッダーを使用しようとしましたが、結果は同じです。

誰かが私が間違っていることを見ることができますか？前もって感謝します。

私は J2ME で digest-md5 を実装しています。クライアント応答の計算では、次の手順を実行します。

1. 「username:realm:password」という形式の文字列を作成します。この文字列を X とします。
2. X の 16 オクテット MD5 ハッシュを計算します。結果を Y と呼びます。
3. 「Y:nonce:cnonce:authzid」という形式の文字列を作成します。この文字列を A1 とします。
4. 「AUTHENTICATE:digest-uri」という形式の文字列を作成します。この文字列を A2 とします。
5. A1 の 32 桁の 16 進数 MD5 ハッシュを計算します。結果を HA1 と呼びます。
6. A2 の 32 桁の 16 進数 MD5 ハッシュを計算します。結果を HA2 と呼びます。
7. 「HA1:nonce:nc:cnonce:qop:HA2」という形式の文字列を作成します。この文字列を KD と呼びます。
8. KD の 32 桁の 16 進数 MD5 ハッシュを計算します。結果を Z とします。

ステップ2の実装方法を知っている人はいますか? 16 進数の 32 桁を返す md5 関数がありますが、16 オクテットの md5 ハッシュを計算する方法がわかりません。

J2ME を使用していることを繰り返したいと思います。その場合、単純に MessageDigest を使用することはできません。

前もって感謝します。:)

私は自分のRESTアプリケーションを少し安全にする方法を検討してきました。HTTP基本認証は方法のように見えますが、要求ごとにクライアントとサーバー間でユーザー名とパスワードを転送する必要があります。を使用した場合でも正常に動作curlしますが、Javascriptファイルを使用しますか？それほどクールではありません。

私は最近、ダイジェストHTTP認証について見つけて読みました。これは、HTTP Basicが提供するセキュリティからの大きな一歩のようですが、理解するのははるかに複雑ですが、まだ完全に正直ではありません。

私はこの質問を見て、ダイジェスト方式を使用することの長所と短所について学ぶための答えですが、考えれば考えるほど、すべてが厄介になるようです。

この問題を解決するためにすでに利用可能な解決策はたくさんあるようですが、それらのほとんどは現在10歳に近づいています。

ダイジェストメソッドは、リクエストを保護する別の新しい方法のために暗闇の中で放っておくのが最善の恐竜ですか、それとも既存の優れたダイジェストライブラリがありますか？