JIYIK CN >

Single Sign On (SSO) is not unfamiliar to us. For large systems, using SSO can reduce a lot of trouble for users. Take Baidu for example. Baidu has many subsystems - Baidu Experience, Baidu Knows, Baidu Library, etc. If we need to enter a username and password to log in to each system when using these systems, I believe the user experience will definitely plummet. Of course, for systems such as personal blogs, SSO is not necessary at all.

Suppose our system is huge, but it is just one system without any subsystems. In this case, we do not need single sign-on. What we need is to build a cluster environment. Although there is only one system here, if multiple hosts are load balanced, the problem of session sharing will be involved . Session sharing problem will be easier to solve than SSO.

Well, let's not worry about systems that don't require single sign-on. The title has already indicated the three situations of SSO single sign-on. Let's introduce these three situations respectively.

How to verify different sites under the same domain name

As we know, PHP form authentication is completely dependent on Cookies. Therefore, if two sites can share the same authentication cookie, it will be easy to log in to multiple sites with the same user.

According to the HTTP protocol, two sites can share cookies. The premise is that the two sites are under the same domain name (or a second-level domain name). In this case, the cookies belong to the same domain. The browser will store the cookies and the domain to which the cookies belong locally. When you visit any sub-site under the domain, the browser will send these cookies to the site system.

Suppose we have two sites

www.onmpw.com/site1
www.onmpw.com/site2

These two sites share the same host address and are both under the same domain name. If you have just logged into www.onmpw.com/site1, your browser will have an authentication cookie from www.onmpw.com/site1. When you click on any subpage under site1, these cookies will be sent to site1. This is easy to understand. Similarly, when you request www.onmpw.com/site2, these cookies will also be sent with the request for any page under site2. Why is this so? Because the domain of the cookie stored on the browser side is www.onmpw.com. Site1 and site2 belong to the same domain. So both sites can get the cookies under this domain.

In this case, if the system is PHP, we don't need to do any special processing. We just need to verify it in the normal way. Because the sessionId of the two is the same, as long as their session information is saved in the same place, it will be fine.

How to do single sign-on for the same domain but different subdomains

If our site is deployed according to the following domain name

sub1.onmpw.com
sub2.onmpw.com

Both sites share the same domain onmpw.com.

By default, the browser will send the host corresponding to the domain to which the cookie belongs. In other words, the default domain of the cookie from sub1.onmpw.com is .sub1.onmpw.com. Therefore, sub2.onmpw.com will not get any cookie information belonging to sub1.onmpw.com. Because they are on different hosts and their subdomains are also different.

In this case, if we use PHP to implement it, we can set the cookie information of both to the same domain.

First login sub1.onmpw.com system

After the second login is successful, set the cookie information. It should be noted here that we can save the username and password in the cookie, but when setting it, the domain of the cookie must be set to the top-level domain .onmpw.com. Here you can use the setcookie function, the fourth parameter of which is used to set the domain of the cookie.

setcookie('username','onmpw',null,'.onmpw.com');
setcookie('password','pwd',null,'.onmpw.com');

Third, when accessing the sub2.onmpw.com system, the browser will send the username and password in the cookie to the sub2.onmpw.com system together with the request. At this time, the system will first check whether the session is logged in. If not, it will verify the username and password in the cookie to achieve automatic login.

Fourth, after logging in successfully, write the session information. In the future, you can use your own session information for verification.

Of course, the method of logging in to sub2.onmpw.com is the same. After the above steps, you can achieve single sign-on for different secondary domain names.

However, there is a problem here. After the sub1 system exits, it can only clear its own session information and the cookie information of the domain .onmpw.com. It cannot clear the session information of the sub2 system. Then sub2 is still logged in. In other words, although this method can achieve single sign-on, it cannot achieve simultaneous exit. The reason is that although sub1 and sub2 can share cookies through the setting of the setcookie function, their sessionIds are different, and this sessionId is also stored in the form of cookies in the browser, but the domain it belongs to is not .onmpw.com. In other words, the sessionIds of the two are different.

How to solve this problem? We know that in this case, as long as the sessionId of the two systems is the same, this problem can be solved. That is to say, the domain of the cookie storing the sessionId is also .onmpw.com. In PHP, the sessionId is generated after the session_start() call. If you want sub1 and sub2 to have the same sessionId, you must set the domain of the sessionId before session_start(). There are two ways:

First, use the PHP function ini_set function to set as follows

ini_set('session.cookie_path', '/');
ini_set('session.cookie_domain', '.onmpw.com');
ini_set('session.cookie_lifetime', '0');

第二 直接修改php.ini 文件

session.cookie_path = /
session.cookie_domain = '.onmpw.com'
session.cookie_lifetime = 0

经过以上设置，sub1和sub2系统就会使用相同的session信息了。这样既可以实现单点登录，也可以实现同时退出。

不同域之间如何实现单点登录

假设我们需要在以下这些站之间实现单点登录

www.onmpw1.com
www.onmpw2.com
www.onmpw3.com

对于这种情况，我们有两种实现方式，其中我们先来介绍实现比较简单的方式。

方式一

为了实现单点登录，当用户登录其中的任何一个站点时，我们需要针对其他每个站点在浏览器端设置cookie信息。

如果用户在onmpw1站点进行登录，登录成功授权以后，浏览器将会存储一份儿onmpw1站点的cookie信息。同时，为了可以登录onmpw2和onmpw3，我们需要在设置onmpw1的cookie的同事也对onmpw2和onmpw3进行cookie设置。因此在对onmpw1进行响应之前，我们需要先跳转到onmpw2和onmpw3站点去设置cookie信息。

下图是对于两个站点的单点登录模型（三个的图画起来比较麻烦，为了节省时间，就用两个来表示，但是原理是相同的）

此种情况的验证步骤是这样的：

一、用户向www.onmpw1.com（以下简称onmpw1）请求一个需要验证的页面。

[状态: 浏览器还没有验证的cookie信息]

二、浏览器向onmpw1发送请求（该请求没有cookie信息，因为它还没有存储所属域为onmpw1.com的cookie信息）。

[状态: 浏览器还没有验证的cookie信息]

三、onmpw1发现在请求中没有带cookie信息，所以它将请求重定向到登录页面

[状态: 浏览器还没有验证的cookie信息]

四、用户提交了登录所需验证的信息并且点击登录按钮，浏览器发送一个post请求到onmpw1。

[状态: 浏览器还没有验证的cookie信息]

五、onmpw1收到提交的验证信息，开始验证这些信息。如果验证成功，则标记该用户已经登录。然后会创建带有登录用户信息的cookie，并将其加入响应信息中。

[状态: 浏览器还没有验证的cookie信息]

六、onmpw1暂时还不去响应浏览器的请求。这时它将会向浏览器发送重定向到www.onmpw2.com（以下简称onmpw2）的命令，并且还带有在onmpw2站点需要返回的url地址，该地址为最初onmpw1中的。因为cookie信息已经在响应信息中，所以这个cookie也被发送给浏览器了。

[状态: 浏览器还没有验证的cookie信息]

七、浏览器接收道带有验证的cookie信息和重定向到onmpw2的命令的响应信息以后，将cookie信息的域设置为onmpw2存储到本地，并且想onmpw2发送请求。这个请求中会带有刚才的cookie信息。

[状态：浏览器中已经有所属域为onmpw2的cookie信息]

八、onmpw2立刻会重定向到需要返回的url地址，并且通过读取浏览器发送的cookie信息，获取到onmpw1的cookie。并将这cookie也一同发送给浏览器。

[状态：浏览器中已经有所属域为onmpw2的cookie信息]

九、浏览器在接受到这些信息以后，会将所属域为onmpw1的cookie存储在本地。并且再次向onmpw1发送一个带有cookie信息的请求。

[状态：浏览器中已经有所属域为onmpw2和onmpw1的cookie信息]

十、onmpw1接收到验证信息以后，知道验证cookie已经设置成功。此时onmpw1会返回相应的请求界面，而不再是登录界面。

[状态：浏览器中已经有所属域为onmpw2和onmpw1的cookie信息]

所以说，当用户再次访问onmpw2的时候，cookie信息已经存储到浏览器中了。这时onmpw2会在cookie中读取到登录的用户的信息，然后提供相应的界面给浏览器。

这样，单点登录就已经设置成功了。在本例中，按照上述步骤，登录onmpw1以后，onmpw2和onmpw3就可以同时实现登录了。

如何退出登录

既然我们已经实现了单点登录，但是我们还得考虑退出的问题。既然是同时登录的，那总不能在退出的时候一个一个的退出吧！所以说我们还要设置单点退出。

要想实现单点退出，在本例中，我们需要做的是当在一个站点退出的时候，其他两个站点的cookie同样也需要在浏览器中清除。这样才可以实现单点退出。

这样其实也很简单，在理解了上述单点登录的流程以后，单点退出只是按照上面的步骤将设置验证cookie改成从响应信息中移除cookie就可以实现了。

对于这种情况，不管是单点登录也好，还是单点退出。都存在一个问题，在本例中我们只是有三个站点。如果说我们整个系统有10个20个或者更多站点，那像我们这样来回的重定向会很影响效率。

方式二

接下来我们来介绍另一种方式。这种方式需要我们借助一个单独的SSO服务，专门做验证用。而且我们还需要对于不同的站点的用户要有一个统一的用户数据。相对于前一种方式——浏览器需要存储每个站点的cookie——来说，这种方式浏览器只需要存储SSO服务站点的cookie信息。将这个cookie信息用于其他站点从而实现单点登录。我们暂且将这个SSO服务站点成为www.SSOsite.com（以下简称SSOsite）。

在这种模型下，针对任何站点的请求都将会先重定向到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，然后将请求的页面发送给浏览器输出。

本文比较长，显得有些啰嗦。但是总是希望过程能给大家讲清楚。希望本文对大家有所帮助。