MachineKey Azure SDK 1.5/1.6

AzureでWCF Web APIを使用してカスタムApi Token実装を使用しています。これは、FormsAuthenticationTicketを取得するためにFormsAuthentication.Decryptを使用します。 decrpytプロセスが複数のインスタンスにわたって機能することを確認するために、私はweb.configにMachineKeyを提供しています。しかし、私は、マシンキーがAzureで動作していないように見えました。なぜなら、Azureはランダムなマシンキーを使用していて、web.configで指定したものを上書きしているからです。最新のAzure SDK 1.5または1.6？）MachineKey Azure SDK 1.5/1.6

私はこの問題をAzure SDK 1.3でよく認識しています。これは1.4で修正されたと思います。 Azure SDK1.5/1.6でこの問題が再現された可能性はありますか？

出典

2011-12-31 Anup Marwadi

ただ、この問題に関する最新情報を提供したかったです。リモートデスクトップを使用してAzure Hosted Serviceのデプロイメントにログインしましたが、物理ファイルでmachineKeyが正しいと思われます。何らかの理由で、FormsAuthentication.DecryptがFormsAuthenticationTicketを生成できないと感じます。このチケットがnullになる理由は何ですか？ –

最近のMicrosoft .Net 4.0セキュリティのアップグレードKB2656351以降、FormsAuthenticationチケットがサブドメイン全体で検証されないのと同じ問題が発生しました。

私のFormsAuthチケットは私の専用サーバーから生成され、Windows Azureのサブドメインで読み取られます。

すべてのサブドメインでチケットの復号化を行うために、すべての専用サーバーにWindows Updateによる最新の.Netアップデートが適用されていることを確認しました。その後、Azureプロジェクトをバージョン1.6にアップグレードし、展開後に最新のAzure OSを選択しました。これはトリックをするように見えました。ここで

は、問題についていくつかの記事です：

http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx

http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx

歓声フランチェスコ

出典

2012-01-04 00:49:49 Francesco

Windows Azureは、すでに展開中の同じ役割でマシンキーを同期しています。したがって、web.configのMachineKey設定を完全に無視し、Windows Azureで処理できるようにしてください（Webファームのシナリオは十分にサポートされています）。あなたのシナリオは、Windows Azure上で変更なしですぐに使用できます（Decryptを呼び出してください）。

あなたが話しているかもしれない問題は、web.configファイルがマシンキーを同期するために直接変更されていた1.3の問題でした。これは、ファイルが読み取り専用（つまりTFSソース管理）であり、デプロイメントエラーが発生したときに失敗しました。それはしばらく前に修正されました。

出典

2012-01-01 15:41:42 dunnry

こんにちは、お返事ありがとうございます。残念ながら、WebサービスとWebサイトが全く異なるインスタンスに存在し、IDの暗号化/復号化を行うため、MachineKeyを制御する必要があります。私が指定したマシンキーが実際に使用されていることを確認する方法があるかどうかを知りたい。 –

私はまだあなたがここで何かを見逃していると思います。私が言及したように、Azureはロール内のすべてのインスタンスにマシンキーを自動的に同期させます。すでにWebファームが準備されています。唯一のマシン鍵の同期は、別の*役割*（単一の役割のインスタンスではない）で暗号化と復号化を試みた場合に問題になります。 – dunnry

私は最終的に解決策を見つけたと思います。これは、AzureやMachineKeysとは関係がありませんでしたが、アプリのテスト方法とはさらに関係がありました。私のPhone Appに保存されていた暗号化された鍵は、別のWebサーバで暗号化されていました（ただし、使用されたマシン鍵は同じです）。私はちょうど私のアプリをアンインストールして再インストールして、サーバーに新しいキーを生成させた。

このキーを別のサーバーで復号化すると問題が発生したようです。これが将来問題を引き起こすかどうか少し気になります。同じマシンキーを使用しないで、暗号化/復号化がボックス間で確実に行われるようにする必要がありますか？

とにかく、ご迷惑をおかけしましたことをお詫び申し上げます。

出典

2012-01-02 05:34:39

同様の問題があるようです。 web.configファイルにmachinekey setを設定しました。数日前にDecryptがnullを返すようになるまで、問題はなかった。復号化キーと検証キーはすべてのマシンで同じです。問題が何であるか分かりません。

EDIT - Azure v1.6は、設定ファイルで設定したマシンキーを尊重しているようです。私たちは問題を解決する方法を考え出しました。おそらく、これはあなたを助けてくれるかもしれません。クッキーの解読は、Windows 7の64ビットの開発マシンでは動作しません。その後、保留中のアップデートをチェックし、セキュリティに関連した.NETアップデートがいくつかありました。私たちは更新プログラムを実行し、うわべいものが再び働き始めました。

出典

2012-01-02 06:37:04 user275157

興味深い。そうです、私は間違いなくこの問題を再現することができます。私が気になるのは、新しいホストされたサービスインスタンスを起動し、そのインスタンスが暗号化された文字列を生成しなかったためにユーザーを検証できない場合、この復号化は失敗するということです。今のところ、暗号解読はIFで動作し、指定されたサーバがデータを暗号化する場合のみです。これは間違いが間違いです。テスト環境では他のサーバーに同じサービスをインストールしましたが、それは確実に機能しているようです。これは現時点で大きな障害となっているようです –

OKだから私は3サーバのNLBグループで上記のような問題がありました。

3台のサーバーのうち2台にWindows自動更新プログラム（KB2656352、KB2656358、KB2657424）がインストールされているようです。

私は、サーバーの中にはパッチで動作しているものもあれば、動作していないものもあるからです。私は、パッチを当てたマシンは、パッチを適用していないマシンでコード化されたものをデコードするのが好きではないと思います。

とにかく残りのマシンに3つのパッチをすべてインストールし、NLBグループに戻しました。それはすべて正常に動作するようです。

出典

2012-01-03 06:48:44

MachineKey Azure SDK 1.5/1.6

答えて

関連する問題