1. SSO 的過程
浏覽器通路受限資訊，被自動轉到 domino 授權頁面。如果啟用了 SSO ，當浏覽器上傳使用者名和密碼授權時， web server 會将授權資訊以 cookie 的方式寫入給浏覽器的 response 的 header 中
當浏覽器請求之後相關的頁面時，會在 request header 中帶入該 cookie 以驗證授權。
2. 為什麼 domino SSO 必須要求相同的域名字尾
其實更多限制來自浏覽器。浏覽器的安全限制會根據請求中的 host 來決定是否發送 cookie 。例如途中 domino web 的授權 cookie ltpa token 。 SSO 域和路徑決定了浏覽器在什麼條件下發送這個 cookie 。域就是域名的字尾，正常情況下應該是例如： abc.com ， xyz.net 路徑 '/' 是指位址欄中 URL 中 host 以後的資訊。
如果 cookie 域名為 abc.com 那麼浏覽器請求 server.abc.com 相關的内容就會發送這個 cookie
那麼如果域名不一緻，浏覽器不會發送 cookie ， SSO 無法實作。
3. 那麼推測當通路 abc.com 時，相關的伺服器寫入名為 xyz.com 的 cookie ，是否浏覽器就能正常通路 xyz.com 。原則上是可以的，但是浏覽器的安全設定，浏覽器會禁止接受與目前通路 host 域名不一緻的 cookie 。 就是說目前 URL 是 abc.com 時浏覽器隻會接受 server 寫域為 abc.com 或者 *.abc.com 的 cookie
4. 繞道的開發可以避免這個問題，但是從 domino 目前的情況來說，必須要求域名字尾一直，無法實作多域名 sso
5. 那如果 server 的域名字尾不一緻，甚至沒有隻有 ip ，沒有域名我們能否實作 SSO 了？
根據 SSO 原理，如果授權 cookie 能成功寫入浏覽器，并且浏覽器在通路相關的頁面時能正常發送 cookie ，那麼 從（ NAT ）的角度也許能實作 SSO
下面單獨以解決 NAT(net address translate) 裝置利用 ip 實作多伺服器 SSO ：
NAT 是 ipv4 中來解決 ip 位址有限的相關協定。我們沒有獨立公網 ip 的 pc 基本都采用 nat 來與 internet 傳輸資料
| 原請求ip位址 | 原請求端口 | 轉換後位址 | 轉換後端口 |
| 192.168.1.103 | 4001 | 192.168.1.106 | 4080 |
例如有 3 個 domino 伺服器 IP 分别為
| server1 | 192.168.1.106 |
| server2 | 192.168.1.108 |
| server3 | 192.168.1.104 |
當通路 server1 時如果要重定向到 server3 ， URL 一般會有 192.168.1.106 變為 192.168.1.104. 為了 SSO ，我們希望能否将 URL 轉變為 192.168.1.106:port 然後将所有發送至這個 port 的所有資料轉到 server3 192.168.1.104. 那麼如果 cookie 的域名也改為 '192.168.1.106' 浏覽器也會正常得到授權 cookie 然後，通路 server3 的頁面時也會正常将 cookie 發送給 192.168.1.104
linux iptables 這個防火牆基于網絡層對資料包的 nat 能夠很好的幫助我們實作這個
iptables 包括 4 個表，我們要用到其中 nat 和 filter 。這也是經常用到的兩個表。
資料包進入 prerouting ，将會被更改目标位址和端口：
例如發送給 192.168.1.106:84 的資料包會被改為 192.168.1.104:80
然後經過 forward ， 到達 postrouting 鍊，在 postrouting 鍊資料包的源位址和源端口将會被更改例如浏覽器位址 : 192.168.1.103:40001 被更改為 nat 防火牆的位址和 ip:192.168.1.106:4080
并生成一條 nat 記錄：
根據這條記錄，當 server3 傳回資料包時，相關的資料包端口資訊 4080 将會被發送至浏覽器 192.168.1.103:4001
| 192.168.1.103 | 4001 | 192.168.1.106 | 4080 |
接下來就可配置 domino sso 文檔。 SSO 文檔
配置 web redirect 資料庫，來實作 URL 的跳轉。
使用者 dwa3 在伺服器 server3 上，目前授權 server 為 server1 ，授權後會根據重定向庫，重定向到 server3 上。重定向的 3 中設定中的 mail serve ，會首先去重定向的伺服器字尾，如果為空，去取 server document->internet protocol 下的 hostname 。如果将這個域的資訊寫為 “192.168.1.106:84” ，那麼浏覽器的 URL 将會跳轉為：
http://192.168.1.106:84/mail/dwa3.nsf 。 而 192.168.1.106 接到 84 端口的包都會扔給 server3 。
然而 hostname 用來做 http 的 ip 綁定，如果這個域改為 192.168.1.106:84 ，将無法綁定 ip 。
我檢視了 web redirect 的模闆，可以更改模闆中的的 http_hostname, 在 server document 中建立一個新的值，并讓 web redirect 去取這個值來生成相關的 URL
所有的配置成功後就可以正常 SSO 了。如圖是 firefox web request 的相關資訊，并對比 server3 的 http 資料抓包
post names.nsf?login 得到授權 cookie ltpatoken, 并且被重定向至 192.168.1.106:84
從定向的 request 中帶入授權 cookie ltpatoken 。并得到來自 server3 的 cookie shimmers
( 這裡不會過多讨論 shimmers ， shimmers 不用做授權。因為是以 cookie 寫入和發送的過程與同域名字尾的過程完全一緻，而我們 SSO 授權隻涉及 ltpatoken ）
對比 server3 的資料：