在这种模型下,针对任何站点的请求都将会先重定向到SSOsite去验证一个身份验证cookie是否存在。如果存在,则验证过的页面将会发送给浏览器。否则用户将会被重定向到登录页面。
为了理解此种方式,现在假设我们来运用这种模型实现以下两个站点的单点登录。
www.onmpw1.com(以下简称onmpw1)
www.onmpw2.com(以下简称onmpw2)
并且我们还有一个专门用来进行验证的服务站点www.SSOsite.com(以下简称SSOsite) 。
第一部分
实现流程
·用户请求onmpw1的一个需要验证的页面
·onmpw1向浏览器发送重定向到SSOsite的命令。并且在地址中添加一个返回地址(ReturnUrl)参数query string,该参数的值就是最初向onmpw1请求的地址。
·SSOsite会在请求中检查是否有身份验证cookie,或者任何用户token。没有这些信息,则会再次重定向到onmpw1,在重定向到onmpw1中的请求中会带有参数让用户登录的url参数和最初的浏览器请求onmpw1的地址——ReturnUrl。
·onmpw1会检测从SSOsite重定向来的请求的参数。这时onmpw1了解到该用户需要登录,因此onmpw1会重定向到登录界面,并且通知浏览器该请求不用再重定向到SSOsite。
第二部分
·用户提供了身份验证信息并且点击了登录按钮。现在不会再去重定向到SSOsite。这时,onmpw1调用SSOsite 中的web/WCF服务去检查用户提供的身份验证信息。成功验证,会将带有token属性的用户对象返回给onmpw1。而这个token是每一次用户登录都会生成的。
·onmpw1标记用户已经登录成功,然后会生成一个URL地址,该地址会带有用户token,重定向到SSOsite。
·SSOsite检查收到的URL地址,会在其中发现用户token。通过该token可以知道用户已经成功登录onmpw1了,所以SSOsite需要准备验证的cookie信息。因此,它会使用token在缓存中取出用户信息来生成cookie信息,而且还会在cookie中设置一些其他的信息(例如过期时间等)。然后把cookie加入到响应信息中。最后重定向到最初的ReturnUrl地址。同时token还是要被加在query string中带过去的。
·浏览器得到重定向到onmpw1的命令,并且从SSOsite中得到cookie信息。因此浏览器将所属域为SSOsite的cookie保存在本地。然后带着token去请求onmpw1。
·现在onmpw1看到用户token在query string 参数中,然后会再次通过web/WCF服务去在SSOsite上验证token。验证成功以后会将最初刚开始请求的页面发送给浏览器用于向用户输出。
第三部分
·用户现在去请求onmpw2。
·onmpw2重定向到SSOsite,同样设置ReturnUrl为刚开始请求的onmpw2的页面地址。
·浏览器接收到重定向的命令以后,因为本地存在SSOsite的cookie,所以会cookie加到请求中发送给SSOsite。
·SSOsite检查接收到的请求中发现有cookie信息,首先会检查该cookie信息是否过期,如果没有过期,将会从cookie中提取出用户token。然后带着token重定向到最初的onmpw2中的地址。
·onmpw2发现请求中有用户token,然后他会通过SSOsite的web/WCF服务验证token的合法性。验证成功以后,将最初浏览器请求onmpw2的页面发送给浏览器用以向用户输出。
总结
哇哦,看起来有很多东西需要做。其实并没有那么复杂。
起初,浏览器没有所属域为SSOsite的cookie信息。因此无论是点击任何站点的需要验证的界面都会跳转到登录页(这个过程是由程序内部重定向到SSOsite来检查是否存在cookie的)。一旦用户登录成功,所属域为SSOsite的,并且带有登录用户信息的cookie会被浏览器存储在本地。
然后,当用户再次访问需要验证的页面的时候,同样请求会在被重定向到SSOsite,并且浏览器会带上先前已经保存的cookie信息。SSOsite检索cookie,从中提取出用户token,并带着这个token重定向到最初请求的站点页面。然后该站点会通过web/WCF服务去验证token的合法性。然后将相应的页面发送给客户端。
一旦用户通过该单点登录模型登录到站点上,请求任何需要验证的页面都会内部重定向到SSOsite验证cookie和提取用户token,然后将请求的页面发送给浏览器输出。