July 9, 2009 at 19:53Cross Site Authentication (SSO)
There is a task - to organize cross-site authorization between projects hosted on different domains (site1.com, site2.com). The user is authorized on one project, is authorized on all (Single Sign On). Same thing with the Single Sign Out button. Each project has access to the session repository and database.
In two days, he shoveled many articles and discussions. Conclusion - I could not find a standard solution for my case (I did not consider the intranet solutions and sites with a clearly separated open / closed zone).
Update: Continuing the story Cross-site authorization 2 .
The basis of this option is a centralized authorization server and HTTP redirects.
1. The user enters a login password and posts a form.
2. We encrypt the username + password + return URL + url if the username / password is incorrect + lifetime (no more than 30 seconds) c the ability to decrypt and get a unique token.
3. We make a redirect to the authorization server by passing the received token in the parameter.
4. The authorization server decrypts it and carries out authorization.
5. Authorization has passed: we put the cookie, we raise the session and generate a token (session id and token lifetime). The login / password is not correct: instead of the token, the flag is that the authorization failed.
6. The authorization server redirects to the reverse URL with the received parameter.
7. We decrypt the token and put the cookie.
8. We do a redirect ourselves to clear the URL in the address bar.
1. The user goes to the site. Check if there is a cookie, if there is a session, if not, then move on.
2. We make a redirect to the authorization server with an encrypted return address.
3. The authorization server checks if there is a cookie.
4. If there is, then we encrypt the token with the session id and token lifetime, if not, then the flag that there are no cookies.
5. We do a redirect back with the received parameter.
6. We decrypt the token and put the cookie.
7. We do a redirect ourselves to clear the URL in the address bar.
1. Remove cookie and encrypt url return.
2. We make a redirect to the authorization server with the return url and delete the session and cookie.
2. We remove the user's binding to the session in the database (in my users table, each user has his current session in order to raise it by cookie).
3. We do a redirect back.
Of the pluses, I want to note that everything works using the usual HTTP protocol without the use of additional technologies.
The minus is quite large and is associated with authorization by cookies: if the user has cookies disabled or the robot has visited us, then a nightmare begins: there will be 3 redirects to each of his requests + a new session will be created.
There are 2 solutions to this problem:
1. Instead of redirecting, connect JavaScript from the authorization server, which, if there is a cookie, will raise the session and put the cookie on the site. But this solution also has disadvantages: as I understand it, there are problems with Safari and authorization by cookies will not work if JavaScript is disabled.
2. Try to burn the one who does not save cookies (mostly robots). You can parse the XML file from www.user-agents.org and put it in some MemcacheDb and check it with every request. Or try to set a cookie, if it doesn’t work, then save the IP (it is possible with the User Agent) in the same MemcacheDb and also check with each request. You can combine both methods.
The features of this option are that you do not need an authorization server and robots are not scary, and also works with JavaScript disabled. Although the decision is honestly not the most beautiful.
1. The user enters a username / password and posts a form.
2. We authorize, put the cookie, we raise the session.
3. Create a token: encrypt the session id and token lifetime.
5. We show one single-pixel picture for each domain with a token in the url.
6. Pictures (scripts that give pictures) decrypt tokens and set cookies on each domain (do not forget to give the P3P header: CP = "IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT").
Cookies are already on all domains.
1. Delete cookies and session.
3. Create a token: encrypt the session id and token lifetime.
4. We show pictures from each domain with a token in the url.
5. Pictures decrypt the token and delete cookies.
Of the minuses: cookie authorization does not work if the images are disabled. Each domain / project should know about everyone else.
I myself did not choose which option to use, therefore, I decided to discuss this topic with you in order to find problem areas and come to an optimal solution.
In two days, he shoveled many articles and discussions. Conclusion - I could not find a standard solution for my case (I did not consider the intranet solutions and sites with a clearly separated open / closed zone).
Update: Continuing the story Cross-site authorization 2 .
Option 1
The basis of this option is a centralized authorization server and HTTP redirects.
Entrance:
1. The user enters a login password and posts a form.
2. We encrypt the username + password + return URL + url if the username / password is incorrect + lifetime (no more than 30 seconds) c the ability to decrypt and get a unique token.
3. We make a redirect to the authorization server by passing the received token in the parameter.
4. The authorization server decrypts it and carries out authorization.
5. Authorization has passed: we put the cookie, we raise the session and generate a token (session id and token lifetime). The login / password is not correct: instead of the token, the flag is that the authorization failed.
6. The authorization server redirects to the reverse URL with the received parameter.
7. We decrypt the token and put the cookie.
8. We do a redirect ourselves to clear the URL in the address bar.
Cookie authorization
1. The user goes to the site. Check if there is a cookie, if there is a session, if not, then move on.
2. We make a redirect to the authorization server with an encrypted return address.
3. The authorization server checks if there is a cookie.
4. If there is, then we encrypt the token with the session id and token lifetime, if not, then the flag that there are no cookies.
5. We do a redirect back with the received parameter.
6. We decrypt the token and put the cookie.
7. We do a redirect ourselves to clear the URL in the address bar.
Exit
1. Remove cookie and encrypt url return.
2. We make a redirect to the authorization server with the return url and delete the session and cookie.
2. We remove the user's binding to the session in the database (in my users table, each user has his current session in order to raise it by cookie).
3. We do a redirect back.
Of the pluses, I want to note that everything works using the usual HTTP protocol without the use of additional technologies.
The minus is quite large and is associated with authorization by cookies: if the user has cookies disabled or the robot has visited us, then a nightmare begins: there will be 3 redirects to each of his requests + a new session will be created.
There are 2 solutions to this problem:
1. Instead of redirecting, connect JavaScript from the authorization server, which, if there is a cookie, will raise the session and put the cookie on the site. But this solution also has disadvantages: as I understand it, there are problems with Safari and authorization by cookies will not work if JavaScript is disabled.
2. Try to burn the one who does not save cookies (mostly robots). You can parse the XML file from www.user-agents.org and put it in some MemcacheDb and check it with every request. Or try to set a cookie, if it doesn’t work, then save the IP (it is possible with the User Agent) in the same MemcacheDb and also check with each request. You can combine both methods.
Option 2
The features of this option are that you do not need an authorization server and robots are not scary, and also works with JavaScript disabled. Although the decision is honestly not the most beautiful.
entrance
1. The user enters a username / password and posts a form.
2. We authorize, put the cookie, we raise the session.
3. Create a token: encrypt the session id and token lifetime.
5. We show one single-pixel picture for each domain with a token in the url.
6. Pictures (scripts that give pictures) decrypt tokens and set cookies on each domain (do not forget to give the P3P header: CP = "IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT").
Cookie authorization
Cookies are already on all domains.
Exit
1. Delete cookies and session.
3. Create a token: encrypt the session id and token lifetime.
4. We show pictures from each domain with a token in the url.
5. Pictures decrypt the token and delete cookies.
Of the minuses: cookie authorization does not work if the images are disabled. Each domain / project should know about everyone else.
I myself did not choose which option to use, therefore, I decided to discuss this topic with you in order to find problem areas and come to an optimal solution.