單一登入常見問題

Adobe 提供下列身分類型：

• Enterprise ID ：組織建立並擁有帳戶。這些帳戶是在申請的網域上建立的。Adobe 管理憑證並處理登入。
• Federated ID：組織建立並擁有帳戶、透過聯盟與企業目錄連結，而企業公司或學校則管理認證並透過單一登入處理登入程序。
• Adobe ID：使用者建立並擁有帳戶。Adobe 管理認證並處理登入程序。視儲存模型而定，使用者或組織擁有帳戶和資產。
  

是的，您可以有混合的 Enterprise ID、Federated ID 和 Adobe ID，但是不能在同一個已申請的網域中使用。

Enterprise ID 和 Federated ID 在網域層級互斥，所以只能選擇其中一個。您可以將 Adobe ID 搭配 Federated ID 或 Enterprise ID 使用。

例如，如果企業只申請一個網域，則 IT 管理員可以選擇 Enterprise ID 或 Federated ID。如果組織在企業內申請多個網域，IT 管理員可以將一個網域搭配 Adobe ID 和 Enterprise ID 使用，並將另一個網域搭配 Adobe ID 和 Federated ID 使用，依此類推。這表示對每個網域而言，您都可以連同 Adobe ID 擁有 Enterprise ID 或 Federated ID。

使用 Federated ID 管理 Adobe 授權不但更快速，而且更輕鬆且安全。

• IT 管理員會控制驗證與使用者週期。
• 當您從企業目錄中移除使用者時，該使用者將不再擁有存取桌面應用程式、服務或行動應用程式的權限。
• Federated ID 允許組織利用已經配置好的使用者身分管理系統。
• 因為您的使用者會使用組織的標準身分識別系統，所以 IT 無須管理個別的密碼管理程序。

當使用者登入時，系統會將他們重新導向組織標準且熟悉的單一登入體驗。

可以。您可以從 Enterprise ID 切換至使用同一個網域的 Federated ID。如需詳細資訊，請參閱如何「在不同目錄中移動網域」。

是的，您可以使用與 SAML 2.0 相容的身分提供者，將企業目錄及其登入和驗證基礎結構聯合 Adobe 一起使用。

不需要。當網域是為了 Federated ID 而申請時，現有的 Adobe ID (使用該網域中的電子郵件地址) 不會有任何變更。Admin Console 中現有的 Adobe ID 則會保留。

資產遷移是一項自動化程序。當您啟動此程序時，所有目前儲存在 Adobe ID 帳戶中的受支援內容都會遷移至您的 Enterprise/Federated ID 帳戶。若要了解詳細資訊，請參閱「自動化資產遷移」。

Adobe 的 Federated ID 實作可支援授權，驗證則是由您的身分提供者 (IdP) 負責處理。

身為企業組織，您可以建立驗證服務 (利用類似 Active Directory 的公司 ID 結構) 與 Adobe 之間的連結，如此可讓企業組織代管驗證。Adobe 絕對不會儲存密碼，IT 管理員也無法透過 Adobe Admin Console 為 Federated ID 重設密碼或編輯使用者名稱。

可以，您可以透過 Adobe Admin Console 所提供的「匯入使用者」功能新增。如需詳細資訊，請參閱「新增多個使用者」。

不可以。Adobe 會接觸您的身分提供者，而不會直接接觸您的企業目錄。但是，我們支援從您的企業目錄將使用者和群組資訊匯入至 Adobe Admin Console。如需詳細資訊，請參閱「新增多個使用者」。

Adobe 建議所有的企業管理員將其 Adobe ID 使用者轉換為 Federated ID。您可以使用下列步驟，從 Adobe ID 轉換為 Federated ID。

Adobe 使用安全且普遍採用的業界標準安全性聲明標記語言 (SAML)，這表示我們的 SSO 實作會輕鬆整合任何支援 SAML 2.0 的身分提供者。

以下是與 SAML 2.0 相容的一些 IdP 清單：

• Okta
• Oracle Identity Federation
• Microsoft ADFS
• Microsoft Azure AD^#
• Google 聯盟^#
• Ping Federate
• Salesforce IdP (具有外部簽署的憑證)
• CA Federation
• ForgeRock OpenAM
• Shibboleth
• NetIQ Access Manager
• OneLogin
• Novell Access Manager

可以，前提是它必須遵循 SAML 2.0 通訊協定的規範。

是的，身分提供者必須與 SAML 2.0 相容。

您的 SAML 身分提供者至少必須具備以下條件：

1. IDP 憑證
2. IDP 登入 URL
3. IDP 繫結：HTTP-POST 或 HTTP-Redirect
4. IDP 的聲明消費者服務 URL，而這也必須能夠接受 SAML 要求和傳遞狀態。

如果還有其他疑問，請洽詢您的身分提供者。

不是的，破解 2048 位元憑證的情況從未發生過。更何況，據唯一成功破解過最多 768 位元憑證的人士 (Lenstra 群組) 估計，即使是使用相同的硬體設備來破解 1024 位元憑證，他們也要花上比 1000 年更久的時間才做到 (此一壯舉約莫比破解 2048 位元憑證來得簡單 32,000,000 倍)。

如果您想要取得有關電算怪傑估計破解各種長度憑證的最新資料，請前往這個網站；如果只是為了好玩想要了解這些憑證有多安全 (雖然精確，但帶有行銷宣傳意味)，請前往這個網站 (或其數學贊助網站)。

不會，這項限制只是針對瀏覽器與伺服器之間用來進行通訊管道編碼的憑證。然而，這些 IdP 憑證是用來對通過該編碼管道的資料進行簽署 (而非編碼)。瀏覽器無法看到這些憑證︰只有在 Adobe 與客戶的 IdP 之間才會用到。

您可在憑證生命週期以每年約 $10 美元的價格取得優良的商業級 2048 位元憑證。此外，IdP 所使用的憑證還可以自我簽章，這表示可以透過開放原始碼軟體免費產生這些憑證。

不行，因為還有另外兩個檢查 IdP 身分的強式加密層，必須加以破解，然後才能假裝成 IdP。而且，這兩個額外層無法自我簽章。也就是說，必須破解的不只是強制加密的憑證，還有產生該憑證之簽章者的憑證要解決。

如需進階支援電話號碼和電子郵件地址，請參閱傳送給您的帳戶管理員的歡迎電子郵件和 PDF 附件。

相同的 URL 端點可用於多個目錄。但是，每個 IdP 的聯盟中繼資料是單獨管理的。因此，公共 IdP 端點需要處理內容不同的要求。

是的，前提是目錄的 SAML 整合使用 username 格式，且 Admin Console 上的使用者名稱與提供的持久 ID 相同。不過，這需要在將使用者同步到 Admin Console 時，持久 ID 必須維持可用。這不是常見情況，因此，在實務中，並不支援 NameID 元素的持久格式。

否。NameID 元素值是當做 Admin Console 上的使用者名稱；NameQualifier 會被忽略。

是。Adobe 支援 SHA256 憑證。如需詳細資訊，請參閱「設定身分」。

可以。您需要將經 CA 簽署之憑證提供給 Adobe 客戶支援，我們將會上傳憑證。

如要繼續進行，請登入 Admin Console，瀏覽至「支援 > 支援摘要」，然後按一下「建立案例」。如需詳細資訊，請參閱「如何建立及管理支援案例」。

根據預設，Okta 憑證是自我簽章。例外情況下 (可能需要付費)，他們可以改由公共 CA 簽署憑證。