私は一般的にSiteMinderとSSOを全く導入していません。私は午後、SOとCAのウェブサイトを午後、基本的な例として紹介したが、見つけられなかった。私は、SMやそのようなものの設定やプログラミングには関心がありません。そのすべては既に他の誰かによって行われています。私はちょうど認証のためにSMを使用するために自分のJS Webアプリを適応させたい。SiteMinder HTTPヘッダーが改ざんされていないことをどのように信頼できますか？
SMは、SM_USERなどのキーを持つHTTPヘッダーを追加し、ユーザーの身元を教えてくれます。私が得られないのは、誰もがこのヘッダー自体を追加してSMを完全にバイパスすることを妨げるのは何ですか？ SM_USERが本当にSMから来たものであることを確認するために、私はサーバ側のコードに何を入れなければなりませんか？私は、ウェブ上にインストール
SM Webエージェントを削除/すべてのトラフィックは、ユーザがこのヘッダを設定してもそうSiteMinder Webエージェントを通過しなければならないので、それは上書きされます
...セキュアなクッキーが関与していると仮定しますサーバーは、リソースの要求があるかどうかを確認するために、すべてのトラフィックをチェックを傍受するように設計されて...
ユーザーが有効なSMSEを持っている場合にSiteMinderにより保護さ
SSION（すなわち、 1及び2に該当する場合認証）
があり、その後、WAは、ユーザーが要求されたリソースにアクセスするためにを認定であるかどうかを確認するようにSiteMinderポリシーサーバーをチェックします。
SM_情報を「信頼する」ことができます。SiteMinder r12.52には、DeviceDNA™を使用したEnhanced Session Assuranceという新しい機能が含まれています。 DeviceDNAを使用すると、SiteMinderセッションクッキーが改ざんされていないことを確認できます。セッションが別のマシン、または同じマシン上の別のブラウザーインスタンスで再生される場合、DeviceDNAはこれをキャッチして要求をブロックします。
Click here to view a webcast discussing new features in CA SiteMinder r12.52
すべてのSiteMinderアーキテクチャは、実際のアプリケーションは、単に「SM_」ヘッダを信頼しているという仮定を作るのですか。
実際には、アプリケーションのアーキテクチャによっては、これでは不十分な場合があります。 基本的に、あなたは3例があります。
典型的なエンタープライズ・アーキテクチャは、Webサーバ（Siteminderのエージェント）+のAppServer（アプリケーション）
言うIPフィルタリングが有効になっていないであろう、そしてウェブ要求がウェブサーバとSSOエージェントをバイパスし、AppServerの直接許可されています。
アプリケーションがリクエストヘッダー/クッキーが改ざん/挿入されていないことをアサートするソリューションを実装する必要がある場合は、次のような解決策がありますか？
WebサーバーとAppサーバー間でTLS/SSLクライアント認証を実装して、データが改ざんされていないことを保証できますが、特にアプリケーションサーバーが内部的にSSLクライアント認証を処理できない場合は、環境が複雑になります。 – bcarroll
私はそれについて疑問に思っていました。 1つの実装でSM_SESSION（セッションCookie）が毎分更新されています。私は安全なクッキーのデフォルトのタイムアウトが何であるのだろうか。 – gabor