不知道BEA是从哪里探听到我们要用Portal的产品，无论如何要跟我们“探讨”一下，于是就来了。
我没有参与过公司原来和Sun，关于我们系统业务模式的讨论，所以听着还是有些感觉的。BEA在没有详细了解我们的方案的基础上，基本上得到我们同样的技术架构和业务流程，这一点让我们有很大的成就感。不过BEA还是有大公司的气魄，根据他们所参与的类似项目，针对我们项目拟出了一系列的“注意事项”，有些是我们以往忽略或者完全考虑的东西，获益非凡。
就交流情况来看，排除价格因素，BEA的Portal和SUN的没有太大区别，都实现了JSR 168，在个性化展现等Portal常用功能上都花了很大的功夫。不过BEA的Portal不包括SSO（Single Sign On），这点虽然我们事先知道，但还是让我们在做选择时有些为难。不过，我们在了解SUN的产品的过程中，已基本了解了SUN的SSO的工作原理，一定要我们自己实现问题也不大。这里简单说说SUN的SSO，以后有机会还可以分析一下MicroSoft的PassPort（另一个单点登录产品）。
SSO的好处就不多说了，SUN的SSO解决方案是基于COOKIE的，所以它也很容易的实现了跨域的SSO。在配置了跨域SSO的情况下，某个用户在一个域中经过Identity验证后，能够访问被同一个Identity服务器保护的另一个域的网络资源。比如说，一个Identity服务器位于Domain 1并且作为验证服务提供者，用户在Domain 1中被Identity验证，因此Token是在Domain 1中设置的。另有一Server B位于Domain 2并且受Agent保护，而保护Server B的是位于Domain 2的另一个Identity服务器，Domain 2中的Identity服务器以Domain 1中的Identity服务器作为验证服务器。
假如User A经过位于Domain 1中的IDENTITY服务器进行验证以后，他接着访问Domain 2中的Server B，位于Domain 2中的Agent会检查该请求是否拥有一个SSO Token，结果是没有属于Domain 2的令牌。在配置了跨域SSO的情况下，Agent会将用户请求重定向到位于Domain 2中的Identity Server的跨域SSO Servlet，接着该组件会将用户的请求重定向到位于Domain 1中的Identity Server服务器中的跨域处理组件，也就是跨域SSO控制器，因为位于Domain 1中的Identity Server是验证服务器。Domain 1中的Identity Server接收到属于Domain 1的Cookie，负责处理SSO的服务向 Domain 2中的Identity Server发送一个SSO Token，Domain 2的验证服务验证来自Domain 1的SSO Token并且为用户创建一个属于Domain 2的SSO Token，最后为用户设置属于Domain 2的Cookie。在该用户具有访问Server B权限的条件下，用户可以访问他所请求的URL。
以图形化方式表示的跨域SSO流程如下图所示。
联系客服
