跨域登錄POST - 陷阱

Question

我們有一個應用託管在我們的域名上。所有用戶都需要先通過POST表單登錄。一旦登錄發生，然後自動將重定向到我們網站上的儀表板頁面。

是否有可能允許某些客戶端託管他們自己的登錄表單（在他們的網站上），該POSTS到我們的應用程序？跨域發佈是否被認爲是不好的做法？是否有任何陷阱需要注意？最後，鑑於我們的網站始終以HTTPS運行，但客戶端網站可能不會運行，SSL如何處理？這可以用iframe規避嗎？

Answer 1

你試圖重塑的東西叫做openid。

你需要做的是提供一個openid服務，然後用戶可以使自己的登錄表單連接到你的開放id服務器。

我有一個這樣的網站的一個很好的例子：http://www.stackoverflow.com使用谷歌和其他作爲openid服務登錄，使自己的登錄表單。

Answer 2

您試圖執行的操作通常被稱爲Single Sign-On（SSO）。這可以使用各種技術來實現。

的總體思路是分離的服務提供商（SP）（有時也稱爲資源提供），這是提供實際服務的用戶將要使用，從身份提供商（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 provider has some problems in that respect。）