1. Domain-based solution. Application a in a.domain.com, b in B. Domain.com, if you set up a cookie, set Domain for domain.com, which can visit this cookie on A and B. (Cookie's Domain, Path, Port, Version, Secure is the same). 2. Solution based on Gateway. When actually deployment, the request for all applications must be forwarded through a GATEWAY, such as using a L4 switch top in front. 3, CAS this type, scheme based on TOOKEN delivery. A authentication server (assuming to auth), there are two applications A, B, deployed on different servers, respectively. 1) User Access A, A application cannot find the user's identity information, use the Redirect method to boot the user to http: // auth / login? Service = http: // a / path. 2) Auth Display the login interface, the user enters the login information, and the authentication is passed. Auth generates a cookie (this cookie can only be read on AUTH), use the redirect method to boot back to http: // a / path? Token = xxxxx (in a solution, this token is an Account through a certain encoding algorithm Information) 3) A Read the information of Token = XXXX to get the user identity. 4) User Access B. B does not find the user's identity information, redirect to http: // auth / login? Service = http: // b / path 5) Auth read cookie Get user identity, then redirect back http: // b / path? Token = xxxx 6) B read token = xxxx information, get the user identity information token scheme is a simple and easy implementation of an SSO scheme, if the actual use, because Auth should pay all the certification requests, and the biggest, the best for auth Do LBS.
