Questions about SSO using Memcache

Single sign-on between multiple sites
Goal:
OA station www.oa.com, forum Domain www.bbs.com, assume that the forum does not have the login function, the user from the OA landed successfully, click BBS Jump link or directly in the address bar to access BBS, all for landing success status.

Simple architecture: Separate memcache server used for session sharing, two stations have their own user table, but the data has a certain correlation, such as the OA user table ID and BBS user table ID;

My implementation:
After the user logs in from OA, generate the user ID related cache data user_id=>xxx in Memcache, and then use the P3P protocol to generate the cookie under the BBS system, which is used to take the user_id= in Memcache by certain encryption algorithm. >xxx, users jump or direct access to the BBS, read the cookie data, after the end of the decryption according to the data in the Memcache BBS user data, will write the session and identify the success of the landing;

Questions:
1, I use memcache share this part of user data is not redundant?
2. What part of the data is shared by SSO, which is usually said to be memcache for session sharing? How it's done
3. Use Memcache for session sharing in SSO do not use cookies in this scenario? Is it cross-domain?
4. Can the implementation of SSO not use cookies?

Reply to discussion (solution)

Use only P3P smart to achieve single sign-on in the same domain, you can find this with more than one browser
Log-in user information with Memcache storage for easy follow-up checking, no direct relationship to SSO

Use only P3P smart to achieve single sign-on in the same domain, you can find this with more than one browser
Log-in user information with Memcache storage for easy follow-up checking, no direct relationship to SSO

The moderator means that P3P can only write cookies in the same domain, and cannot write cookies across domains.
But I test on this machine can write a cookie across the domain, and then I think the other domain by writing to the cookie in the domain to achieve a single point of landing, how is this scheme?
Is there a better plan for moderators? (Do not use CAS or similar systems)

I have tested that P3P can only write cookies in the same domain.
See how you write it.

I have tested that P3P can only write cookies in the same domain.
See how you write it.

This is probably the way:
Local construction of www.a.com and www.b.com

Www.b.com==> index.php Code is written by P3P a cookie,
Www.a.com==>index.php inside the call, after accessing the www.a.com/index.php, the cookie will be generated under the www.b.com domain.

1, I use memcached share this part of user data is not redundant?
See if you need to use this part of the data across sites, which is superfluous when you don't need it.

2. What part of the data is shared by SSO, which is usually said to be memcached for session sharing? How it's done
Ditto. Generally in SSO you can consider storing the global permission bit in the memcached, and do the quick authentication of the permission. But you said that the integration of permissions distributed in each system, should not need this part of the data.
Memcached as session sharing provides a cross-process, cross-system data transfer method, P3P can only small batch transfer data between domains, and memcached even pictures can be passed, and the browser, client programs, mobile phone applications can be.

3. Use Memcache for session sharing in SSO do not use cookies in this scenario? Is it cross-domain?
A cookie is typically used to pass Token,token data, which is usually a one-time use, and is passed as a parameter when a system starts another system.
Cross-domain refers to the data passing between different domains of the browser, and memcached is not related to the service-side component.
Token delivery, which is also required in the client program, is passed through the parameters

4. Can the implementation of SSO not use cookies?
More reliable with URL parameters

4. Can the implementation of SSO not use cookies?
More reliable through URL parameters, but requires more server-side code

4. Can the implementation of SSO not use cookies?
More reliable through URL parameters, but requires more server-side code

Require direct access to other sites is also logged in, but not through the URL, you can only use cookies

4. Can the implementation of SSO not use cookies?
More reliable through URL parameters, but requires more server-side code

Require direct access to other sites is also logged in, and not through the URL, can only use a cookie bar [/quo


The main thing is to see if there is a server-side SSO interface, the URL parameter is most convenient if it can be verified by token on the server side. If SSO is used only in browser clients, such as Taobao, then the URL parameter will not work.

Implementation of SSO, it is necessary to implement the method of URL parameter delivery, in order to protect tokens, when used by third parties only when the use of cookies.

Implementation of SSO, it is necessary to implement the method of URL parameter delivery, in order to protect tokens, when used by third parties only when the use of cookies.

This method can not directly access other stations through the address bar to display the status of the login

Implementation of SSO, it is necessary to implement the method of URL parameter delivery, in order to protect tokens, when used by third parties only when the use of cookies.

This method can not directly access other stations through the address bar to display the status of the login

That's right. There are many restrictions on URLs, just high reliability and no JavaScript support to run.
And the cookie mode can not access the server in the browser directly to determine the user status of the ability to reduce the SSO server-side pressure is very helpful.

