0

我们在我们的域上托管了一个应用程序。所有用户都必须首先通过 POST 表单登录。登录后，表单会自动重定向到我们网站上的仪表板页面。

是否可以允许一些客户托管他们自己的登录表单（在他们的网站上），发布到我们的应用程序？跨域发帖是否以任何方式被视为不好的做法？有什么陷阱需要注意吗？最后，考虑到我们的站点总是在 HTTPS 上运行，但客户端站点可能不是，那么 SSL 是如何处理的？这可以用 iframe 规避吗？

4

2 回答 2

1

您要重新发明的内容称为openid。

您需要做的是提供一个 openid 服务，然后用户可以制作自己的登录表单来连接到您的 open id 服务器。

我有这样一个网站的一个很好的例子：http: //www.stackoverflow.com，它使用 google 和其他人作为 openid 服务登录，制作自己的登录表单。

于 2012-10-04T12:29:09.833 回答
0

您尝试执行的操作通常称为单点登录(SSO)。这可以使用多种技术来实现。

总体思路是将服务提供者 (SP)（有时也称为资源提供者）与身份提供者 (IdP) 分开，后者提供用户将要使用的实际服务，身份提供者 (IdP)是验证用户身份的地方.

simplePHP库使用多种SSO 标准为 IdP 和 SP 身份验证层提供实现：SAML、Shibboleth（也基于 SAML）、OpenID...

请注意，如果您使用的是标准，则不需要使用与您为服务选择的实现相同的实现来实现 IdP。例如，可以使用 Shibboleth 库在 Java 中实现 IdP，并将其与使用 simplePHP 的 SP 结合使用。

您使用哪些技术将取决于您在身份验证后所需的信息类型，例如是否需要额外的属性，以及如何管理 IdP 和 SP 之间的信任。

通常，从 SP 的角度来看，一个简单的 OpenID 系统集成起来相当简单，但它对用户的断言非常有限。相比之下，Shibboleth 有许多选项来指定哪个 SP 可以看到哪些用户属性以及哪些 IdP 打算发布或不发布，但它需要更坚固的基础设施：这通常在一个联邦中完成，所有各方交换一个一组元数据配置，包括它们用来信任彼此的断言的 X.509 证书。

由于身份验证将在您的管理范围之外进行，因此您无法真正控制用户将如何进行身份验证（除非这是更正式的协议的一部分，例如在 Shibboleth 联盟中）。即使您的服务需要 HTTPS，OpenID 提供程序也可能允许用户通过纯 HTTP 进行身份验证。（话虽这么说，大多数严肃的 OpenID 提供商都会安全地做到这一点，无论如何都要由用户来选择他们信任的一个。）

永远不要在您的服务中嵌入 IdP 页面：让用户转到他们的 IdP 页面。为了使身份验证系统安全（就用户而言），用户必须能够看到他们正在输入密码的内容。通过使用 iframe，您可以有效地将真实站点隐藏在后面（并且徽标很容易抓取/伪造）。（StackExchange OpenID 提供程序在这方面存在一些问题。）

于 2012-10-04T13:54:18.027 回答