如何在多个域上创建共享登录服务？ [英] How to create a Shared Login Service across Multiple Domains?

问题描述

我对如何实施共享跨域登录系统以及最佳做法和安全预防措施感兴趣。如果您熟悉37Signals，您可能习惯于使用共享的通用身份验证机制，如果您使用其他产品的顶级导航，则不必后续登录。我想以类似的方式实现一些东西。

I'm interested in how to implement a shared cross-domain login system as well as best practices and security precautions to take. If you are familiar with 37Signals, you are probably accustomed to their usage of having a shared universal authentication mechanism whereby you do not have to subsequently login if you use the top level navigation to a different product. I would like to implement something in a similar fashion.

我在网上找到的最近的东西是中央认证服务和对跨域登录 - 如何在从一个域转移到另一个域时自动登录用户，在这种情况下可能略有不同。

The closest thing I've found online is the Wikipedia entry on a Central Authentication Service and the response to Cross Domain Login - How to login a user automatically when transfered from one domain to another, which may be slightly different in this case.

我已经检查了他们的会话cookie，以了解他们在这个过程中做了什么。最初，每个产品链接都有一个gotouristub，即：

I have inspected their session cookies to get a grasp on what they're doing in the process. Initially, each product link has a "goto" uristub, i.e.:

https://MY_COMPANY.campfirenow.com/id/users/ [int_identifier] / goto

https://MY_COMPANY.campfirenow.com/id/users/[int_identifier]/goto

在Firebug中使用FireCookie和NET选项卡，我可以看到设置的Cookie和重定向发生在进程中。 goto url会触发302重定向到

Using FireCookie and the NET tab in Firebug, I'm able to see the cookies that are set and the redirects that occur in the process. The goto url fires a 302 redirect to:

https：// MY_COMPANY。 basecamphq.com/login/authenticate?sig=[BASE64_ENCODED_AND_ENCRYPTED_DATA]

https://MY_COMPANY.basecamphq.com/login/authenticate?sig=[BASE64_ENCODED_AND_ENCRYPTED_DATA]

重新创建会话标识符，很可能是出于CSRF目的。 Cookie中的一些数据以及GET参数sig使用base64_decode部分解密，如下所示：

The session identifier is recreated, most likely for CSRF purposes. Some of the data in the cookies as well as the GET parameter sig were partially decrypted using base64_decode to the following:

// sig GET param
array(2) {
  [0]=>
���ף�:@marshal_with_utc_coercionT7�z��<k��kW"
  [1]=>
  string(18) "���k�<kn8�f���to��"
}

// _basecamp_session cookie session param
string(247) {
:_csrf_token"1Sj5D6jCwJKIxkZ6oroy7o/mYUqr4R5Ca34cOPNigqkw=:session_id"%060c0804a5d06dafd1c5b3349815d863"
flashIC:'ActionController::Flash::FlashHash{:
@used{: auth{"
              MY_COMPANY{:
                       user_idi�3
:identity_idi�W����������s�]��:�N[��:

߾

编码打破了代码块。感谢您的帮助！

The encoding is breaking the code block. Thanks for your help!

推荐答案

我认为你的问题中的关键是你写的你不必后来登录如果您使用顶级导航到不同的产品。

I think the key in your Q is where you write "whereby you do not have to subsequently login if you use the top level navigation to a different product".

我将解释：
您希望能够从site1.com移动到site2。 com，让site2.com知道您是通过site1.com登录的用户。

I will explain: You want to be able to move from site1.com to site2.com and let site2.com know that you are some user that logged in via site1.com.

因为Cookie不能在不同的域之间共享（除了子域名，但我猜猜你不是在谈论子域名），你必须传递一些关于site2.com的链接的信息，让它与后端通讯，知道你是什么用户。

because cookies are not shareable between different domains (other then subdomains but I guess you are not talking about sub-domains) you have to pass some information on the link to site2.com that will let it talk with its back-end and know what user you are.

让我们开始一个朴素的解决方案，然后我们的方式来解决一些问题，它造成：
假设你有一个用户表在一些后端数据库，你的用户有一些ID。
现在假设用户在site1.com上进行身份验证，而他是来自您的数据库的用户123。
最原始的解决方案是调用site2.com/url/whatever?myRealID=123
，并让site2检查此ID，并确认用户确实是他。

lets start with a naive solution and then work our way to make resolve some of the problems that it poses: suppose you have a users table on some back-end DB and your user has some ID. now assume that the user authenticated on site1.com and he is user 123 from your DB. The most naive solution would be to call site2.com/url/whatever?myRealID=123 and have site2 check for this ID and "belive" the user that this is indeed him.

问题：任何人（即使是您网站的有效用户）将看到您的链接，可以创建一个与myRealID = 123的链接，或者尝试其他值。

Problem: Anyone (even a valid user of your site) that will see your link can create a link with myRealID=123 or try other values for it. and site2.com will accept him as that user.

解决方案：不要使用可猜测的ID，假设您向用户表中添加一个唯一的GUID，如果用户123有一个guid的8dc70780-15e5-11e0-ac64-0800200c9a66然后调用site2.com/url/whatever?myGuid=8dc70780-15e5-11e0-ac64-0800200c9a66。

Solution: lets not use guessable ID's suppose you add to your users table a unique GUID and if user 123 has a guid of 8dc70780-15e5-11e0-ac64-0800200c9a66 then call site2.com/url/whatever?myGuid=8dc70780-15e5-11e0-ac64-0800200c9a66.

新问题：虽然这是不可能的，有人会猜到你的用户的GUID他的GUID仍然可以被一个中间人劫持看到这个链接，它会有人会得到他可以永远使用的指导。

New Problem: well even though It would be very unlikely that someone will guess your user's GUID his GUID can still be hijacked by some middle man that sees this link and it someone will get the guid he can use it for ever.

解决方案：使用保存在服务器上的私钥对包含以下数据项，当前时间戳，目标站点（即site2.com）的GUID进行签名，该签名可以被翻译成说这是该链接是由网站在所述时间为具有该GUID以由该域认证的用户创建的并且将其与时间戳和GUID一起发送到site2.com 。现在当site2.com获取链接，他可以确保它是正确签名，如果一些中间人或最初的用户将尝试以任何方式（我修改时间或GUID），然后签名将不匹配和site2。

Solution: Use a private key saved on your server to sign a string that contains the following data items, current time-stamp, destination site (i.e "site2.com") the said GUID, this signature can be translated into saying "This is a proof that this link was created by the site at the said time for the user that has this GUID to authenticated by this domain" and send it to site2.com along with the time-stamp and GUID. Now when site2.com gets the link he can make sure that it is signed properly and if some middleman or originally user would try to change it in any way (either my modifying the time or GUID) then the signature would not match and site2.com will refuse authenticating the user.

最后一个问题：如果链接被中间人拦截，他仍然可以使用，如果从其他机器。

One last problem: if the link is intercepted by a middleman he can still use if from some other machine.

解决方案：向传递的参数中添加一个随机数。随机数只是一个随机数，您的身份验证系统应该确保它不允许您再次使用此数字进行身份验证（因此名称为N（umber）-ONCE）。请注意，这意味着您在site1.com上创建的每个链接都应该有一个不同的现时，需要保存在后端以供以后验证。

Solution: add a nonce to the passed parameters. The nonce is just a random number that your authentication system should make sure that it does not allow you to authenticate with this number more then once (hence then name N(umber)-ONCE). Note that this means that each link you create on site1.com that leads to site2.com should have a distinct nonce which needs to be saved on the back-end for later validation.

因为你不想永远添加记录到这个nonce表永远是自定义决定这样的链接只有在其创建后的某个给定的时间有效。因此您可以创建比此时间限制之前的随机数记录。

because you don't want to keep adding records to this nonce table forever it is custom to decide that such a link is only valid for some given time after its creation. and so you can create nonce records that are older than this time limit.

我希望这是你在寻找的大纲。
可能我错过了一些东西，但这些是基本的准则，使用签名证明链接中的数据的真实性，并使用一个随机数来防止中间人攻击。如果可能，我还建议为这些链接使用HTTPS。

I hope that this is the outline you where looking for. It is possible that I missed something but those are the basic guidelines, use a signature to prove the authenticity of the data in the link and use a nonce to prevent middleman attacks. I would also recommend using HTTPS for those links if possible.

Eyal

这篇关于如何在多个域上创建共享登录服务？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！