2

当社の IT スタッフは、アプリケーションの IIS 6.0 Web サーバーに SiteMinder エージェントをインストールすることを拒否しています。これは、サードパーティ製ソフトウェアであるためセキュリティ上の懸念があることと、リソースの使用率が高くなりアプリケーションのパフォーマンスに影響を与える可能性があることを理由にしています。

彼らは、必要最小限の IIS、SiteMinder エージェント、およびログイン試行を認証するための「シム」のみを含む、独立した分離された Web サーバーをセットアップすることを提案しています。

この shim は、エージェントによって保護されるようにマークされた単一の ASPX ページになります。SiteMinder エージェントを使用してユーザー ID を認証し、アプリケーションのデータベースでユーザー ID を検索し、ユーザー ID とパスワードをユーザーのブラウザに返します。JavaScript 関数は、アプリケーションの既存のログイン ページにユーザー ID とパスワードを入力したかのように POST します。

彼らの懸念は正当なものですか？なぜですか、そうでないのですか？

同様のアーキテクチャを実装している人を聞いたことがありますか?

提案された解決策は、良いものですか、悪いものですか、それとも醜いものですか?

4

2 に答える 2

3

エージェントは最初のログインだけでなく、アプリケーションへの後続の呼び出し、つまり認証済みセッションも管理するため、機能しているようには見えません。エージェントは、Cookie を調べたり、検証したりします。シナリオでは、それがどのように行われるかについて説明していません。

私たちの環境では、すべてのインターネット トラフィックは IIS に到達する前に Apache リバース プロキシを通過します。IIS はファイアウォールの背後にあります。Apache リバース プロキシには SM エージェントがあり、トラフィックを IIS にリダイレクトするだけです。リバース プロキシとして機能する IIS を使用して、同様の設定を行うことは可能だと思います。

ところで、IT 担当者に、彼が提案した靴ひもとバブルガムのログイン ソリューションは、IIS に SiteMinder をインストールするよりもはるかに大きなセキュリティ上の問題であると伝えてください。

于 2013-07-16T15:30:20.580 に答える
2

apache リバース プロキシ ソリューションは確実に機能しますが、SiteMinder r12.51 には Secure Proxy Server が含まれています。

SPS を使用すると、単一のサーバーを、SiteMinder エージェントをインストールできない、またはインストールしないすべてのアプリケーションの「ゲートウェイ」として構成できます。Web エージェントは SPS に組み込まれており、独自の Java アプリが面倒な作業を行います。SPS には、r12 WAMUI のルック アンド フィールに従う GUI もあり、構成が非常に簡単です。

Secure Proxy Server にはフェデレーション ゲートウェイ機能もあるため、SAML フェデレーションを行う場合は Web エージェント オプション パックをインストールする必要はありません。すべての fcc ページも SPS によって提供できるため、SSO 環境をサポートするために必要な Web サーバーの数を減らすことができます。

于 2013-08-13T17:10:46.637 に答える