不知道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流程如下圖所示。
簡單的SSO實作，首先使用者被重定向到登入伺服器，登入伺服器驗證密碼，并生成權限資訊token，加密後寫回浏覽器 端cookie,
使用者通路另一台伺服器，伺服器讀取cookie,并解密token，檢視全新資訊中是否有權限通路本伺服器！以此類推！如果token為
空， 則預設重定向到登入伺服器！