2012-02-25 18 views
3

私は、1つのマスター認証サイトと複数のスレーブサイトがあるSSOソリューションを開発しています。私は、誰かがスレーブに登録するときに登録をマスタに転送し、その結果ユーザをマスタにログインさせる必要がある時点にいます。ドメイン間でHTTP経由でデータを安全に送信

多くの方法がありますが、現在、必要な登録/ログインデータを暗号化し、このデータをエンドユーザに隠しiframeでリダイレクトすることで、エンドユーザはこれに悩まされませんプロセス(これはサイトT &のCでカバーされます)。今では既にSSLを使用していますが、このプロセスをできるだけ安全にしたいと考えています。現在、私はマスタとスレーブが両方の設定を保持しているキーを使ってデータを暗号化しています。私はキーが常に同じで誰かがこれを解読することができるかもしれないが、マスタが各クエリごとにスレーブから取得しなければならないキーと一緒に塩を使うことを考えているが、必要なHTTPクエリーの量

私はこれをやめようとしているのか、あまりにも慎重であるのか(なぜなら、理論的にはSSLだけで十分だろう)と思っているだけです。

アドバイスはありますか?ありがとう

答えて

2

ほとんどの場合、SSLで十分です。サーバの証明書と秘密鍵が安全に保管されている場合、証明書の失効は定期的にチェックされ、秘密鍵は弱くはないなど(...)、エンドユーザのブラウザとサーバ間のチャネルマスターとスレーブのサイト)は盗聴から保護され、他人が信任状を見るのを防ぎます。

SSLの目的は、接続の「クライアント」側を認証することです(つまり、正しいURLが接続でき、スレーブサイトを偽装し、認証/ログイントークンを取得できることを知っている人)。提供された資格情報は正しい)。これは、トークンが与えられると、マスターサーバーは、どのサイトが「特権」機能を実行しているかを区別することができないことを意味します。信任状自体はSSLによって保護されたままであり、攻撃者は攻撃を実行するためにそれらを知る必要があります。 (XSSの脆弱性や不正なCookie管理など、サイト自体に他にバグがないと仮定しています)。

つまり、キー(または文字列形式のシークレット)を使用して、スレーブサイトからマスターの1つに転送するこのネットワーク内のアクセス許可を大きなレベルで管理する必要がある場合は、詳細(特定のサイトへのログインを防止し、ユーザーの身元に基づいて他のサイトへのログインを許可する、または一部が直接コントロールされていない場合に特定のサイトへのログインを一時的に拒否し、妥協すると思われる場合など)その場合、OAuth siteを見てみることをお勧めします。これは、その目的のために設計されたプロトコルです(ログインを許可し、マスターサーバーから必要なデータを取得するAPIを書くだけです)。

すべてのサイトがあなたの直下にある場合は、SSLだけで十分です。 2つの鍵セット(SSL用と暗号化用)を管理する負担が大きすぎるため、サーバーが多すぎるリソースを使用することになります。ネットワークスニッフィングから防御するために、ブラウザーとサーバーの間でSSLが使用されていることと、サーバー間のすべての通信にSSLが使用されていることを確認してください。

+0

[oauth.net/code/](http://oauth.net/code/)にすぐに使えるライブラリのリポジトリもあります。最初からすべてをコーディングする必要はありません。 –

+0

info elgatonありがとう。私は、妄想的ではなく、SSLに対する信念を持っています。 – Naatan

+0

@Naatanよろしくお願いします。 –

関連する問題