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 的数据：