SiteMinder的正确设计

Question

我必须给出使用Site Minder的SSO架构的建议。我们几乎没有J2EE应用程序。这些J2EE应用程序设计为在SSO提供者进行身份验证后，当http头包含信息时工作。我们一直保持应用程序SSO提供程序不可知。这意味着我们只依赖SSO提供程序的头。这在RSA作为SSO提供程序的情况下运行良好。

现在SiteMinder提出了另一种架构。请求的流动方式是

带IIS的SiteMinder-

要崩溃，我们必须

a） 带IIS的SiteMinder（面向公众的站点）

b）Apache反向代理（用于路由）

c） Tomcat应用程序（用于路由和基于时间的站点访问逻辑）

d） 后端应用程序

引入新体系结构的原因是所有后端应用程序都有用于站点访问的代码。站点可能会关闭一段时间，这是由属性文件控制的。

我发现这种架构是错误的。我不明白为什么需要Apache反向代理。我仍然会使用简单的体系结构，使用flow作为）SiteMinder，使用IIS进行路由-

我错过什么了吗？

Answer 1

我看不出第二种架构背后的原理。第一个场景是Siteminder更常见的部署。

请注意，这种体系结构可能会打开漏洞（尤其是绕过登录）。看看我对这个问题的回答。这两种体系结构都是如此。

Answer 2

Apache反向代理将更容易在多个IIS实例之间实现负载平衡。据我所知，要在IIS上执行类似操作，您需要使用ARR（应用程序请求路由）模块，该模块不会优化为与Tomcat等一起使用。

然而，带有IIS的SiteMinder似乎在您的体系结构中增加了额外的开销。Apache反向代理还支持SiteMinder代理。为什么不推动在Apache代理上设置SiteMinder代理，并从图片中完全删除IIS。我可以想到以下好处：

1. 从架构中删除一个额外的层
2. 删除一个额外的网络跳
3. 清理堆栈。Apache Tomcat在企业中非常标准，而IIS Apache Tomcat绝对不是。

希望这能有所帮助