Implementation of Single Sign-On (SSO) Single Point Login

Source: Internet
Author: User
Tags tojson
We all know that large portals such as Netease And Sohu all have the concept of "pass". This pass system is the "single sign-on system" discussed today ". Its main feature is that multiple sites have one user center. After one login, others also log on automatically and log off. For example, if we log on to the mailbox at 126 and go to 163.com, the logon status is displayed. My Implementation Scheme here is the traditional cookie scheme. I hope this article will be useful to anyone who needs it, and I hope you can raise any shortcomings. Basic SSO functions: · Unified Logon All site logins must jump to SSO to log on, with the URL parameter you just requested, so that you can return after logging on. Like http://sso.a.com/login? Url = http://www. B .com, after logging on, We response a cookie and set its domain to a.com top-level domain so that any site in the same domain can directly access this cookie. Because Cookies cannot be cross-origin, we need to solve the cookie problem in different domains. The solution is to obtain the cookie information of a.com through the js api, and pass a B .com through the URL. We know that AJAX cannot be accessed across regions, but we can <SCRIPT> A cross-region JS (this is jsapi). Therefore, the SSO system needs to provide a callback parameter and output it as a JS Code . SSO outputs the cookie to the caller and accepts the callback parameter. VaR user = Request. Cookies [ " Username " ];
VaR callback = Request. querystring [ " Callback " ];
If (User ! = Null )
Response. Write (callback + " ( " + User. tojson () + " ) " ); // Tojson is an extension method that serializes objects into JSON format. B .com $. Getscript ( " Http://sso.a.com/getcookie? Callback = setuser " );
Function Setuser (data)
{
If (Data ! = Null )
{
VaR User = Eval (data );
Alert ( " Hello " + User. username );
}
Setcookie (User ); // Write the obtained cookie locally
} In this way, we can use B .com to know whether the user is logged on. · Unified Cancellation You must connect to sso.a.com/logoutto Delete cookie. · Verify Logon To enable the simultaneous logout function, for example, if bbs.a.com is canceled, www. B .com must be aware of it. Therefore, all B .com requests that need to know the login status must access sso.a.com once to verify whether they are still logged on. There are two ways to verify Logon: One is that the above mentioned jsapi knows whether a cookie exists to determine whether other systems have logged out. In addition, when a cookie is saved locally, the server verifies whether the user is still logged on through WebService. The two methods have their own advantages and disadvantages. The first is that you do not need to know whether a local cookie exists. The second is to use WebService, but the added validation is rigorous. If we perform important data operations on B .com, we recommend that you use server-side checks to determine the logon status. If you determine from the cookie, you must ensure that the cookie cannot be forged, that is, you must encrypt the cookie, decryption. If the cookie through the WebService client also requires an unforged identifier, such as guid, but does not require encryption, you only need to match the guid and username of the server. However, the stress on WebService is much greater than that on cookie decryption. If the site is mostly visited and the access volume is high, such authentication requests will put a lot of pressure on SSO. · Server Design If SSO has other tasks that are under great pressure, it must be deployed on multiple machines. Multiple deployments have a session problem. Therefore, the user logon status of the server cannot store the session in inproc, nor in statusserver. It can only be in sqlserver. My solution is to put it in the distributed cache (memcached). Of course, it is not a session, but a normal cache list. Put username and guid in memcached to make a hash table, so that you can quickly find a user's login situation (guid and request are consistent) · Authorized White List SSO exposes some WebService interfaces for the site, so it cannot be used by others. In this case, you need to verify whether the requested IP address is an authorized IP address)

I hope my friends with ideas can post comments.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.