我完全新的SiteMinder和SSO一般。 我整个下午都戳周围SO和CA网站的一个基本的例子，并不能找到一个。 我不关心设置或编程SM之类的东西。 所有这一切都已经由其他人来完成。 我只是想适应我的JS的web应用程序使用SM进行身份验证。
我得到的SM将与一键添加一个HTTP头如SM_USER会告诉我的用户是谁。 我不明白的是 - 什么阻止任何人加入这个头自己，完全绕过SM？ 我有什么把我的服务器端代码来验证SM_USER真正从SM来的？ 我想安全cookie都参与...
Answer 1:
安装在Web服务器上的SM Web代理旨在拦截所有流量，并检查是否资源请求是...
受保护的SiteMinder
如果用户有一个有效的SMSESSION（即经过身份验证 ）
如果1和2是真的，那么WA检查SiteMinder策略服务器来查看用户是否被授权访问所请求的资源。
为了确保你没有的用户信息HTTP头注射，在SiteMinder的WebAgent将改写所有SiteMinder的特定HTTP头信息。 从本质上讲，这意味着你可以“信任” SM_信息，因为它是由Web代理传入请求的服务器，而不是部分创建的WebAgent被呈现关于用户。
Answer 2:
因为所有的流量应该通过SiteMinder Web代理这样即使用户设置该头将被覆盖/删除
Answer 3:
SiteMinder的r12.52包含一个名为增强的会话与保证的DeviceDNA™新功能。 的DeviceDNA可以用来确保在SiteMinder会话Cookie没有被篡改。 如果会话被重放的不同机器上，或从同一机器上的另一个布劳尔例如，将的DeviceDNA捕获此并阻止该请求。
点击此处查看网络广播在CA SiteMinder的r12.52讨论新功能
Answer 4:
所有SiteMinder的架构确实使应用程序只是有信任“SM_”报头的假设。
在实践中，这可能不是根据您的应用程序的架构就足够了。 基本上，你有三种情况：
- Web代理程序安装在Web服务器在您的应用程序运行（对Apache / PHP应用典型案例）上：如上所述，您可以信任的头，因为没有要求，而不受Web代理被过滤到您的应用程序。
- Web代理程序安装比您的应用程序运行，但在同一台机器上的一个不同的Web服务器上（典型案例：在服务于JEE应用服务器Apache的前端安装SM代理）：你必须确保没有请求可以直接到达您的应用程序服务器。 要么你的应用程序服务器绑定到环回接口或您筛选服务器上的端口。
- 在Web代理程序运行在你的应用程序前面的反向代理。 同样的话。 这里唯一的解决方案是实现您的应用程序的IP过滤器，只允许来自您的反向代理请求。
Answer 5:
典型的企业架构将网络服务器（代理的SiteMinder）+应用服务器（应用程序）
说IP过滤未启用，并网请求直接允许应用服务器，Web服务器绕过和SSO代理。
如果应用程序必须实现一个解决方案断言/饼干中没有被篡改/注射请求头，我们有呈三角以下任何解决方案？
- 发送在一个单独的cookie加密或加密（符号/ ASYM）的SM_USERID与SMSESSION ID一起
- 应用程序将使用密钥来解密SMSESSION或SM_USERID以检索用户ID，会话过期的状态和任何其他addtional细节和授权的详细信息（如果适用）。
- 应用程序现在信任USER_ID和做认证
文章来源: How can I trust that the SiteMinder HTTP headers haven't been tampered with?
