Design and implementation of a cross-domain single sign-on system

Design and implementation of a cross-domain single sign-on system one, cross-domain Single sign-on system overall design 1. System architecture

As shown: There is a certification center and multiple sites in the system. User information unified by the Certification center management, in other sub-station login will jump to the certification center to log in.

2. Work Flow

The key point of a single sign-on system is that when a user logs in from a sub-station, it is generated in the authentication centerTicketidentity, as long as the identity exists on behalf of the user has successfully landed. Each sub-station before entering, regardless of the localTicketidentity is present, will go to request a certification center, to do the following things: if the sub-stationTicketdoes not exist, and does not necessarily mean that the user does not log in from another child station, but if the user is logged in at another child station, then the certification center must haveTicketThe purpose of the request is to judge the certification centerTicketIf there is, if it exists, then the user is already logged in the other child station, to do is only request back in their own siteCookiesplanted inTicket, if it does not exist, it means that the user is not logged in at all, then jump directly to the login page; if the child stationTicketis present, then it goes to the authentication center that the purpose of the request is that if the certification centerTicketno longer exists, the user has exited, and the request returns after the localCookiesin theTicketclear, to achieve the "all-in-one, one retreat" effect, if the certification centerTicketIs still present, you need to verify that theTicketauthenticity, is not the client's (need some other means). The detailed process is as follows.

The

assumes that the user has never logged on to the system, and when he accesses a site, Will go to the Certification Center to request it once ( jsonp cross-domain request), Results found that the certification center also does not have ticket Then jump to the login page of the certification center, and when the user logs in to the Certification center, the certification center jumps to a site, at this time a site will also go to the Certification Center request once, and this time will get ticket ticket planted in the site of the cookie

When the user at this time to visit the B site, the same will go to the Authentication Center request once, the results of the request found ticket exist, it will ticket also planted in their own site Cookie , so that users can freely access the B site without having to log in .

When the user exits at site B, the authentication Center is requested once, and the request will clear the ticket value saved by the Certification center . When the other site operation, to the Certification center request, found that ticket has not, but also will be the ticket of their own site , so that will jump to the login page.

Second, Jsonp cross-domain script request

One of the technical points that need to be addressed for cross-domain single sign-on is cross-domain issues. UseJsonpTo solve this problem, two things need to be done in the system. First: Create a new one in the certification centerJSfile (Note: This file is not used by the certification center, but to other sub-sites for cross-domain access), to achieveAjaxof theJsonprequest, that is, in the certification centerJS, write a paragraphAjax, it is going to tune the local interface to determine the localTicketis present. If present, theSuccessin the return, theTicketthe value species. If it does not exist, it will alsoTicketcleared (the action is to clear the siteCookies, which allows the user to exit). Second: In the system, other sub-site header files, reference a paragraphJSto achieveJSremote loading, as follows:

<script type= "Text/javascript" src= "Http://auth.gfly.com/js/RemotePlantCookies.js" ></script>

In this way, each time the child site refresh, will load the authentication center of the JS file, and the JS file is cross-domain, in the kind of cookies , in fact, are planted at each sub-site.

Examples of JSONP cross-domain requests are as follows:

$ (document). Ready (function () {    var res = $.ajax ({            type: "Get",            dataType: "Jsonp",                          URL: "/http/ Auth.gfly.com/index.php?r=user/user/getticket ",            crossdomain:true,            success:function (r)            {                 var res = R;                 if (Res.res = = True)                 {                     var exp = new Date ();                       Exp.settime (Exp.gettime () + 6 * * * +);                      Document.cookie = "ticket=" +res.token+ "expires=" +exp.togmtstring () + ";p ath=/";                 }                 else                 {                     var date = new Date ();                     Date.settime (Date.gettime () -10000);                     Document.cookie= "ticket=000; Expire= "+date.togmtstring ();                 }}            ,            error:function ()            {            }     });});

Third, safety instructions

        in cookie It is dangerous to pass information such as password, although our ticket ticket ticket Send the request message to the server, it can also be verified. Based on this, a slightly safer approach is to log on at the authentication center side while the client's ip address recorded, in the validation ticket ip is the address associated with the previously saved ip address consistent, only by consensus can be verified, otherwise ignored.

Note: Complete with the Grand Tune Single sign-on system. Welcome to celebrate!!

Design and implementation of a cross-domain single sign-on system