Domino单点登录LTPAtoken生成原理.docxVIP

Domino单点登录LTPAtoken生成原理 一、? WebSphere与Domino之间的SSO 首先让我们来了解一下Websphere与Domino之间是怎么完成SSO的： ? 1、? Web用户向Websphere发起一个登录请求。 2、? Websphere判断为合法用户，登录成功。 3、? 生成ltpatoken，将ltpatoken写入cookie。 ? 这样，当Web用户后续向Domino发起登录请求时，Domino会找到存放在cookie信息中的ltpatoken信息，并且认为这个ltpatoken有效，完成在domino的登录过程。那么这里会有2个疑问。第1个，Domino怎么会找的到Websphere存放的cookie，这就是为什么配置SSO的时候需要2个系统是在同一个DNS域下面，因为浏览器cookie共享的限制，跨域不能共享cookie嘛（当然也能用一些其他的手段生成跨域的cookie，这样其实通过一定的开发是可以让LTPATOKEN跨域的，本案例不讨论这个问题）。第2个问题，domino找到这个token之后，凭什么认识这个ltpatoken，并且认为它有效呢，所以要求domino和Websphere在生成ltpatoken的时候就有某种约定。这就是为什么配置Domino SSO文档的时候需要引入Websphere的密钥了。有了这些前提Domino和Websphere之间就能互相认识对方生成的ltpatoken，并且从中读出需要登录的用户名，只要用户名匹配得上（这就是为什么W和D需要用同一个LDAP目录），该用户就完成登录了。 以上就是简单的Websphere与Domino之间SSO的原理。当然其实SSO过程还没有这么简单，比如还需要验证ltpatoken的有效期等。 现在我们知道实现SSO的关键在于LtpaToken，Websphere与Domino之间采用LtpaToken来共享认证信息。 那么基本上任何一个系统只能要完成以下2件事情，它就有可能参与LtpaToken认证的SSO方案了： 1、? 能生成一个有效的LtpaToken提供给别人。 2、? 能解析一个别人生成的LtpaToken。 另外，可能还有一些要求： 1、? 参与SSO的系统使用同样的密钥生成LtpaToken，称为公钥。 2、? 参与SSO的用户帐号名称在各系统中一致，因为每个系统从Token中读出了用户名之后必须要正确关联到本地对应的用户进行登录。 3、? 参与SSO的系统必须在同一个DNS域下面（跨域的问题前面提过）。 4、? 最后当然需要采用B/S方式，浏览器必须支持Cookies了。 ?一、? LtpaToken组成原理 通过了解LtpaToken的组成原理，我们就可以自己编码???成和解析LtpaToken了。首先一个LtpaToken的合成公式如下： [token] = BASE64([header][creation time][expiration time][username][SHA-1 hash]) 解释： ????????? Header: LtpaToken 版本（长度4），Domino的固定为[0x00][0x01][0x02][0x03] ????????? Creation time: 创建时间戳（长度8），格式为Unix time比如[2010-03-12 00:21:49]为4B99189D ????????? expiration time：过期时间戳（长度8） 同上 ????????? username： 用户名（长度不定） ????????? SHA-1 hash：SHA-1校验和（长度20） 如下图： ? ? 上面的SHA-1校验和，又是由前面所说的密钥和其余的Token资料合并而成，合成公式如下： [SHA-1 hash] = SHA-1([header][creation time][expiration time][username][shared secret]) 所以，如果有人篡改了Token，那校验和就与修改后的Token匹配不上了，这样Token一旦生成，有人想要修改它的信息，比如改成别的用户名，是不可能的。 二、? Domino如何处理LtpaToken 查看一下domino的Web SSO配置文档： 1、? Domino生成LtpaToken的密钥存放在LTPA_DominoSecret字段 2、? LTPA_TokenExpiration字段存放失效分钟数。 3、? LTPA_TokenName字段存放Token表示在cookie的name ….如下图： ? 再加上上面分析过的LtpaToken组成原理，我们大概可以知道domino是怎么生成LtpaTo