We offer a number of online services. We are required to develop a system which provides a quick/simple experience for users if they are transferred from one service (on domain1.com) to another service (on domain2.com).
我们提供多种在线服务。如果用户从一个服务(在domain1.com上)转移到另一个服务(在domain2.com上),我们需要开发一个为用户提供快速/简单体验的系统。
Is there a safe and secure way to automatically login a user automatically once he has been transferred to the new service?
一旦他转移到新服务后,是否有一种安全可靠的方式自动登录用户?
Yell at me if the solution below is completely insecure/wrong.
如果下面的解决方案完全不安全/错误,请对我大喊大叫。
We were considering a system similar to that provided by a number of online services for password recovery - they are emailed a link with a unique hash which expires, that allows them to change their password.
我们正在考虑一个类似于许多在线服务提供的用于密码恢复的系统 - 它们通过电子邮件发送一个带有唯一哈希的链接,该链接过期,允许他们更改密码。
The domain1.com would generate a unique hash and store it in a database with the hash linked to a user along with an expire datetime field.
domain1.com将生成唯一的哈希并将其存储在数据库中,其中哈希链接到用户以及到期日期时间字段。
The user will be transferred to domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e
用户将被转移到domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e
domain2.com would next make a request to domain1.com with the hash to get the information about the user. domain1.com would then remove the hash from the database. domain2.com would log the user in and set cookie etc.
domain2.com接下来将使用哈希向domain1.com发出请求以获取有关用户的信息。然后domain1.com将从数据库中删除哈希。 domain2.com会记录用户并设置cookie等。
Could something based on OpenID or OAuth achieve the same results?
可以基于OpenID或OAuth获得相同的结果吗?
5 个解决方案
#1
114
Single sign-on (SSO) is conceptually pretty simple.
单点登录(SSO)在概念上非常简单。
- User hits
domain1.com. -
domain1.comsees there's no session cookie. -
domain1.comredirects tosso.com -
sso.compresents login page, and take credentials -
sso.comsets session cookie for the user -
sso.comthen redirects back todomain1to a special url (likedomain1.com/ssologin) - the
ssologinURL contains a parameter that is basically "signed" by thesso.com. It could be as simple as a base64 of encrypting the loginid using a shared secret key. -
domain1.comtakes the encrypted token, decrypts it, uses the new login id to log in the user. -
domain1sets the session cookie for the user.
用户点击domain1.com。
domain1.com看到没有会话cookie。
domain1.com重定向到sso.com
sso.com提供登录页面,并获取凭据
sso.com为用户设置会话cookie
sso.com然后重定向回domain1到一个特殊的URL(如domain1.com/ssologin)
ssologin URL包含一个基本上由sso.com“签名”的参数。它可以像使用共享密钥加密loginid的base64一样简单。
domain1.com获取加密的令牌,对其进行解密,使用新的登录ID登录用户。
domain1为用户设置会话cookie。
Now, the next case.
现在,下一个案例。
- User hits
domain2.com, which followsdomain1and redirects tosso.com -
sso.comalready has a cookie for the user, so does not present the login page -
sso.comredirects back todomain2.comwith the encrypted information -
domain2.comlogs in the user.
用户点击domain2.com,它跟随domain1并重定向到sso.com
sso.com已经为用户提供了cookie,因此不会显示登录页面
sso.com使用加密信息重定向回domain2.com
domain2.com登录用户。
That's the fundamentals of how this works. You can make it more robust, more feature rich (for example, this is SSOn, but not SSOff, user can "log out" of domain1, but still be logged in to domain2). You can use public keys for signing credentials, you can have requests to transfer more information (like authorization rights, etc) from the SSO server. You can have more intimate integration, such as the domains routinely checking that the user still has rights from the SSO server.
这是其工作原理的基础。您可以使其更强大,功能更丰富(例如,这是SSOn,但不是SSOff,用户可以“注销”domain1,但仍然登录到domain2)。您可以使用公钥来签名凭据,您可以请求从SSO服务器传输更多信息(如授权权限等)。您可以进行更密切的集成,例如域定期检查用户是否仍拥有SSO服务器的权限。
But the cookie handshake via the browser using redirects is the key foundation upon which all of these SSO solutions are based.
但是使用重定向通过浏览器进行cookie握手是所有这些SSO解决方案所依据的关键基础。
#2
7
If someone were able to play man in the middle and grab that hash, would they be able to steal the cross domain transfer? Obviously it needs to be generated and sent to the client prior to them needing to use it. So say for instance:
如果有人能够在中间玩男人并抓住那个哈希,他们是否能够窃取跨域转移?显然,需要在需要使用它之前生成并发送给客户端。例如说:
I'm playing man in the middle spying on Jack. Jack accesses domain1.com which causes a hash to be prepared and sent to him so that when he accesses domain2.com he can send that hash as authentication. As he accesses domain1.com, his request comes through me, you return the page, I grab the hash and let him carry on. I access domain2.com using the hash, you've now let me into domain2.com and deleted the hash. He's none the wiser until he attempts to login to domain2.com and is told that his credentials are no longer valid.
我在扮演杰克的中间人。 Jack访问domain1.com,这会导致准备一个哈希并发送给他,这样当他访问domain2.com时,他可以发送该哈希作为身份验证。当他访问domain1.com时,他的请求来自我,你返回页面,我抓住哈希并让他继续。我使用哈希访问domain2.com,你现在让我进入domain2.com并删除哈希。在他尝试登录domain2.com并被告知他的凭据不再有效之前,他并不聪明。
How do you overcome that?
你是怎么克服的?
#3
7
There wouldn't be any point using SSL for the cross-domain login unless you use SSL for the entire session. It is just as easy to steal a session cookie as it is to use a hash in an url. What is the point in hiding the hash in SSL if the rest of the session is insecure.
除非您在整个会话中使用SSL,否则使用SSL进行跨域登录不会有任何意义。窃取会话cookie就像在URL中使用哈希一样容易。如果会话的其余部分不安全,那么在SSL中隐藏哈希值有什么意义。
The method given at the top is pretty much the standard method. Whether you choose to use secure protocols is another matter entirely, but it would be pointless to only encrypt part of the session.
顶部给出的方法几乎是标准方法。您是否选择使用安全协议完全是另一回事,但仅加密部分会话是没有意义的。
#4
6
This is a good solution. Here are two points to consider:
这是一个很好的解决方案。以下两点需要考虑:
You use the term "hash", but it's not clear what data you'll hash. Instead, use a "nonce": a large (128-bit) number generated by a cryptographic quality RNG.
您使用术语“哈希”,但不清楚您将散列哪些数据。相反,使用“nonce”:由加密质量RNG生成的大(128位)数字。
Also, you didn't specify this, but communications between the user and both domains, and between the domains themselves, must be secure. Use SSL to authenticate the servers and to keep the nonce confidential.
此外,您没有指定此项,但用户与两个域之间以及域之间的通信必须是安全的。使用SSL对服务器进行身份验证并对nonce保密。
#5
2
What about SEO? It looks like every request before succesfull login is redirected to other domain and back. I would tell that this is very ugly. What headers should you send? 301 to SSO and then back 301 to original page? So search bot is "requested" to change his index for that page twice?
SEO怎么样?看起来成功登录之前的每个请求都被重定向到其他域并返回。我会说这很难看。你应该发送什么标题? 301到SSO然后回301到原始页面?因此,“请求”搜索僵尸程序两次更改该页面的索引?
#1
114
Single sign-on (SSO) is conceptually pretty simple.
单点登录(SSO)在概念上非常简单。
- User hits
domain1.com. -
domain1.comsees there's no session cookie. -
domain1.comredirects tosso.com -
sso.compresents login page, and take credentials -
sso.comsets session cookie for the user -
sso.comthen redirects back todomain1to a special url (likedomain1.com/ssologin) - the
ssologinURL contains a parameter that is basically "signed" by thesso.com. It could be as simple as a base64 of encrypting the loginid using a shared secret key. -
domain1.comtakes the encrypted token, decrypts it, uses the new login id to log in the user. -
domain1sets the session cookie for the user.
用户点击domain1.com。
domain1.com看到没有会话cookie。
domain1.com重定向到sso.com
sso.com提供登录页面,并获取凭据
sso.com为用户设置会话cookie
sso.com然后重定向回domain1到一个特殊的URL(如domain1.com/ssologin)
ssologin URL包含一个基本上由sso.com“签名”的参数。它可以像使用共享密钥加密loginid的base64一样简单。
domain1.com获取加密的令牌,对其进行解密,使用新的登录ID登录用户。
domain1为用户设置会话cookie。
Now, the next case.
现在,下一个案例。
- User hits
domain2.com, which followsdomain1and redirects tosso.com -
sso.comalready has a cookie for the user, so does not present the login page -
sso.comredirects back todomain2.comwith the encrypted information -
domain2.comlogs in the user.
用户点击domain2.com,它跟随domain1并重定向到sso.com
sso.com已经为用户提供了cookie,因此不会显示登录页面
sso.com使用加密信息重定向回domain2.com
domain2.com登录用户。
That's the fundamentals of how this works. You can make it more robust, more feature rich (for example, this is SSOn, but not SSOff, user can "log out" of domain1, but still be logged in to domain2). You can use public keys for signing credentials, you can have requests to transfer more information (like authorization rights, etc) from the SSO server. You can have more intimate integration, such as the domains routinely checking that the user still has rights from the SSO server.
这是其工作原理的基础。您可以使其更强大,功能更丰富(例如,这是SSOn,但不是SSOff,用户可以“注销”domain1,但仍然登录到domain2)。您可以使用公钥来签名凭据,您可以请求从SSO服务器传输更多信息(如授权权限等)。您可以进行更密切的集成,例如域定期检查用户是否仍拥有SSO服务器的权限。
But the cookie handshake via the browser using redirects is the key foundation upon which all of these SSO solutions are based.
但是使用重定向通过浏览器进行cookie握手是所有这些SSO解决方案所依据的关键基础。
#2
7
If someone were able to play man in the middle and grab that hash, would they be able to steal the cross domain transfer? Obviously it needs to be generated and sent to the client prior to them needing to use it. So say for instance:
如果有人能够在中间玩男人并抓住那个哈希,他们是否能够窃取跨域转移?显然,需要在需要使用它之前生成并发送给客户端。例如说:
I'm playing man in the middle spying on Jack. Jack accesses domain1.com which causes a hash to be prepared and sent to him so that when he accesses domain2.com he can send that hash as authentication. As he accesses domain1.com, his request comes through me, you return the page, I grab the hash and let him carry on. I access domain2.com using the hash, you've now let me into domain2.com and deleted the hash. He's none the wiser until he attempts to login to domain2.com and is told that his credentials are no longer valid.
我在扮演杰克的中间人。 Jack访问domain1.com,这会导致准备一个哈希并发送给他,这样当他访问domain2.com时,他可以发送该哈希作为身份验证。当他访问domain1.com时,他的请求来自我,你返回页面,我抓住哈希并让他继续。我使用哈希访问domain2.com,你现在让我进入domain2.com并删除哈希。在他尝试登录domain2.com并被告知他的凭据不再有效之前,他并不聪明。
How do you overcome that?
你是怎么克服的?
#3
7
There wouldn't be any point using SSL for the cross-domain login unless you use SSL for the entire session. It is just as easy to steal a session cookie as it is to use a hash in an url. What is the point in hiding the hash in SSL if the rest of the session is insecure.
除非您在整个会话中使用SSL,否则使用SSL进行跨域登录不会有任何意义。窃取会话cookie就像在URL中使用哈希一样容易。如果会话的其余部分不安全,那么在SSL中隐藏哈希值有什么意义。
The method given at the top is pretty much the standard method. Whether you choose to use secure protocols is another matter entirely, but it would be pointless to only encrypt part of the session.
顶部给出的方法几乎是标准方法。您是否选择使用安全协议完全是另一回事,但仅加密部分会话是没有意义的。
#4
6
This is a good solution. Here are two points to consider:
这是一个很好的解决方案。以下两点需要考虑:
You use the term "hash", but it's not clear what data you'll hash. Instead, use a "nonce": a large (128-bit) number generated by a cryptographic quality RNG.
您使用术语“哈希”,但不清楚您将散列哪些数据。相反,使用“nonce”:由加密质量RNG生成的大(128位)数字。
Also, you didn't specify this, but communications between the user and both domains, and between the domains themselves, must be secure. Use SSL to authenticate the servers and to keep the nonce confidential.
此外,您没有指定此项,但用户与两个域之间以及域之间的通信必须是安全的。使用SSL对服务器进行身份验证并对nonce保密。
#5
2
What about SEO? It looks like every request before succesfull login is redirected to other domain and back. I would tell that this is very ugly. What headers should you send? 301 to SSO and then back 301 to original page? So search bot is "requested" to change his index for that page twice?
SEO怎么样?看起来成功登录之前的每个请求都被重定向到其他域并返回。我会说这很难看。你应该发送什么标题? 301到SSO然后回301到原始页面?因此,“请求”搜索僵尸程序两次更改该页面的索引?