本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
在桌面上為企業部署設定 Amazon Quick
| 適用對象:企業版和標準版 |
| 目標對象:系統管理員 |
若要在桌面上使用 Amazon Quick 進行企業部署,管理員必須設定企業單一登入 (SSO),以便組織中的使用者可以使用其企業憑證登入。此設定會將組織的 OpenID Connect (OIDC) 相容身分提供者 (IdP) 連線至 Amazon Quick。
注意
如果您使用的是 免費或 Plus 帳戶,本節不適用於您。繼續進行開始使用。
設定會依序包含下列步驟:
-
在 IdP 中建立 OIDC 應用程式。
-
在 Amazon Quick 管理主控台中設定擴充功能存取。
-
將桌面應用程式分發給您的使用者。
本指南提供 Microsoft Entra ID、Okta 和 Ping Identity (PingFederate 和 PingOne) 的 IdP 特定指示。請參閱以下特定身分提供者的說明。
企業登入的運作方式
Amazon Quick 桌面應用程式使用 OIDC 通訊協定來驗證使用者。當使用者選擇企業登入時,應用程式會開啟瀏覽器視窗,並重新導向至 IdP 的授權端點。然後,應用程式會使用 Code Exchange 的驗證金鑰 (PKCE) 交換產生的權杖授權碼。
Amazon Quick 會驗證權杖,並將使用者映射至您帳戶中的身分。IdP 中的電子郵件地址必須與 Amazon Quick 中使用者的電子郵件地址完全相符。
先決條件
開始之前,請確認您有下列項目:
-
具有作用中 Amazon Quick 訂閱 AWS 的帳戶。Amazon Quick 帳戶的所在區域 (身分區域) 必須是美國東部 (維吉尼亞北部) (us-east-1)。支援所有身分類型,包括 IAM Identity Center、IAM 聯合和原生 Amazon Quick (使用者名稱/密碼) 使用者。
-
管理員存取您的 Amazon Quick 帳戶。
-
具有建立 OIDC 應用程式註冊許可的 IdP 存取權。
重要
Amazon Quick 帳戶的所在區域 (身分區域) 必須是美國東部 (維吉尼亞北部) (us-east-1)。桌面應用程式的所有推論也會使用此區域。雖然 Amazon Quick on the Web 可用於其他區域,但桌面應用程式會連線至 us-east-1 進行身分驗證和推論。
步驟 1:在身分提供者中建立 OIDC 應用程式
在 IdP 中註冊公有 OIDC 用戶端應用程式。Amazon Quick 桌面應用程式使用此用戶端透過 PKCE 的授權碼流程來驗證使用者。不需要用戶端秘密。
桌面應用程式需要重新整理權杖來維護長期工作階段。重新整理字符的設定方式取決於您的 IdP:
-
Microsoft Entra ID – 必須授予
offline_access範圍。如果沒有,使用者必須經常重新驗證身分。 -
Okta – 必須在應用程式上啟用重新整理字符授予類型,並且必須授予
offline_access範圍。 -
Ping 身分 – 必須啟用重新整理字符授予類型,且必須授予
offline_access範圍。對於 PingFederate,也必須在 OIDC 政策中啟用 Return ID Token On Refresh Grant 設定。
選擇身分提供者的指示。
Microsoft Entra ID
如需詳細說明,請參閱 Microsoft Entra 文件中的註冊應用程式
建立 Entra ID 應用程式註冊
-
在 Azure 入口網站中,導覽至 Microsoft Entra ID → 應用程式註冊 → 新註冊。
-
進行下列設定:
設定 Value 名稱 Amazon Quick Desktop支援的帳戶類型 僅限此組織目錄中的帳戶 (單一租戶) 重新導向 URI 平台 公有用戶端/原生 (行動和桌面) 重新導向 URI http://localhost:18080 -
選擇註冊。
-
在概觀頁面上,記下應用程式 (用戶端) ID 和目錄 (租戶) ID。在後續步驟中,您需要這些值。
這是公有用戶端註冊。公有用戶端的 Entra ID 會自動強制執行 PKCE。
設定 API 許可
-
在應用程式註冊中,導覽至 API 許可 → 新增許可 → Microsoft 圖形 → 委派許可。
-
新增下列許可:
openid、email、profile、offline_access。 -
選擇新增許可。
-
如果您的組織需要,請選擇授予 【您的組織】 的管理員同意。
設定身分驗證設定
-
在應用程式註冊中,導覽至身分驗證。
-
在進階設定下,將允許公有用戶端流程設定為是。
-
確認
http://localhost:18080已列在 Mobile 和桌面應用程式下。 -
選擇儲存。
您的 OIDC 端點使用以下格式。<TENANT_ID> 將 取代為您的目錄 (租戶) ID。
| 欄位 | Value |
|---|---|
| 發行者 URL | https://login.microsoftonline.com/<TENANT_ID>/v2.0 |
| 授權端點 | https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/authorize |
| 權杖端點 | https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token |
| JWKS URI | https://login.microsoftonline.com/<TENANT_ID>/discovery/v2.0/keys |
Okta
如需詳細說明,請參閱 Okta 文件中的建立 OpenID Connect 應用程式整合
建立 Okta OIDC 原生應用程式
-
在 Okta 管理員主控台中,導覽至應用程式 → 應用程式 → 建立應用程式整合。
-
選取 OIDC - OpenID Connect 作為登入方法。
-
選取原生應用程式做為應用程式類型,然後選擇下一步。
-
進行下列設定:
設定 Value 應用程式整合名稱 Amazon Quick Desktop授予類型 授權碼和重新整理權杖 登入重新導向 URIs http://localhost:18080指派 指派給適當的使用者或群組 -
選擇儲存。
-
在一般索引標籤上,記下用戶端 ID。
Okta 會自動為原生應用程式強制執行 PKCE (S256)。
設定範圍
-
在 Okta 管理員主控台中,導覽至安全性 → API → 授權伺服器,然後選取您的授權伺服器 (例如預設)。
-
在範圍索引標籤上,確認已啟用下列範圍:
openid、email、profile、offline_access。 -
在存取政策索引標籤上,確認指派給此應用程式的政策允許
Authorization Code和Refresh Token授予類型。
驗證身分驗證設定
-
在應用程式整合中,前往一般索引標籤。
-
在一般設定下,確認應用程式類型為原生,用戶端身分驗證為無 (公有用戶端),且 PKCE 為必要。
-
在 LOGIN 下,確認
http://localhost:18080列為重新導向 URI。 -
如果您進行任何變更,請選擇儲存。
您的 OIDC 端點使用以下格式。<OKTA_DOMAIN> 將 取代為您的 Okta 網域 (例如 your-org.okta.com)。
| 欄位 | Value |
|---|---|
| 發行者 URL | https://<OKTA_DOMAIN>/oauth2/default |
| 授權端點 | https://<OKTA_DOMAIN>/oauth2/default/v1/authorize |
| 權杖端點 | https://<OKTA_DOMAIN>/oauth2/default/v1/token |
| JWKS URI | https://<OKTA_DOMAIN>/oauth2/default/v1/keys |
Ping 身分
選擇 Ping Identity 產品的指示。
PingFederate
如需詳細說明,請參閱 Ping Identity 文件中的在 PingFederate 中設定 OIDC 應用程式
建立 PingFederate OIDC 用戶端
-
在 PingFederate 管理主控台中,前往應用程式 → OAuth → 用戶端,然後選擇新增用戶端。
-
在用戶端 ID 欄位中,輸入此用戶端的唯一識別符。
-
在 Name (名稱) 欄位中,輸入
Amazon Quick Desktop。 -
針對用戶端身分驗證,選取無。
-
在重新導向 URI 區段中,輸入
http://localhost:18080,然後選擇新增。 -
在允許授予類型清單中,選取授權碼並重新整理權杖。
-
選取 Code Exchange (PKCE) 需要證明金鑰核取方塊。
-
在通用範圍下,授予下列項目:
openid、email、profile、offline_access。 -
選擇儲存。
-
記下用戶端 ID。在後續步驟中,您需要此值。
設定 OIDC 政策
-
在 PingFederate 管理主控台中,前往應用程式 → OAuth → OpenID Connect 政策管理。
-
選取與此用戶端相關聯的 OIDC 政策,或選擇新增政策來建立政策。
-
選取重新整理授予時傳回 ID 權杖核取方塊。這可確保桌面應用程式在重新整理工作階段時收到具有目前宣告的新 ID 字符。
-
在屬性合約下,確認已包含
email宣告,並映射至身分驗證來源中對應的使用者屬性。email宣告必須同時存在於初始身分驗證和重新整理權杖授予期間發出的權杖中。 -
選擇儲存。
您的 OIDC 端點使用以下格式。<PINGFEDERATE_HOST> 將 取代為您的 PingFederate 伺服器主機名稱。
| 欄位 | Value |
|---|---|
| 發行者 URL | https://<PINGFEDERATE_HOST> |
| 授權端點 | https://<PINGFEDERATE_HOST>/as/authorization.oauth2 |
| 權杖端點 | https://<PINGFEDERATE_HOST>/as/token.oauth2 |
| JWKS URI | https://<PINGFEDERATE_HOST>/pf/JWKS |
PingOne
如需詳細說明,請參閱 Ping Identity 文件中的編輯應用程式 – 原生
建立 PingOne OIDC 原生應用程式
-
在 PingOne 管理員主控台中,前往應用程式 → 應用程式,然後選擇 + 圖示。
-
輸入
Amazon Quick Desktop做為應用程式名稱。 -
在應用程式類型區段中,選取原生,然後選擇儲存。
-
在組態索引標籤上,選擇編輯並設定下列設定:
設定 Value 回應類型 Code 授予類型 授權碼和重新整理權杖 PKCE 強制執行 S256 Redirect URIs (重新導向 URI) http://localhost:18080權杖端點身分驗證方法 無 -
選擇儲存。
-
在資源索引標籤上,新增下列範圍:
openid、email、profile、offline_access。 -
在屬性映射索引標籤上,確認
email屬性已映射至使用者的電子郵件地址。 -
將應用程式切換為已啟用。
-
請注意組態索引標籤中的用戶端 ID 和環境 ID。
注意
PingOne 網域因區域而異。以下範例使用 .com。將網域取代為您環境的網域 (例如 .ca、 .eu或 .asia)。
您的 OIDC 端點使用以下格式。將 取代<ENV_ID>為您的 PingOne 環境 ID。
| 欄位 | Value |
|---|---|
| 發行者 URL | https://auth.pingone.com/<ENV_ID>/as |
| 授權端點 | https://auth.pingone.com/<ENV_ID>/as/authorize |
| 權杖端點 | https://auth.pingone.com/<ENV_ID>/as/token |
| JWKS URI | https://auth.pingone.com/<ENV_ID>/as/jwks |
步驟 2:在 Amazon Quick 管理主控台中設定擴充功能存取
新增擴充功能存取
-
登入 Amazon Quick 管理主控台。
-
在許可下,選擇延伸存取。
-
選擇新增延伸項目存取。
-
選取快速延伸模組的桌面應用程式,然後選擇下一步。
-
輸入 Amazon Quick 延伸模組詳細資訊:
欄位 Value 名稱 此延伸存取的名稱 說明 (選用) 描述 發行者 URL 步驟 1 中的 OIDC 發行者 URL 授權端點 步驟 1 中的 OIDC 授權端點 URL 權杖端點 步驟 1 中的 OIDC 字符端點 URL JWKS URI 步驟 1 中的 JSON Web 金鑰集 URI 用戶端 ID 步驟 1 中的 OIDC 用戶端識別符 -
選擇新增。
重要
在選擇新增之前,請確認所有值皆正確。延伸存取組態無法在建立後編輯。如果任何值不正確,您必須刪除延伸存取並建立新的延伸存取。
建立擴充功能
-
在 Amazon Quick 主控台的 Connect 應用程式和資料下方左側導覽中,選擇延伸模組。
-
選擇新增延伸模組。
-
選取桌面應用程式,以進行您先前建立的快速延伸存取。選擇下一步。
-
選擇建立。
步驟 3:下載並分發桌面應用程式
設定企業登入後,請自行下載並安裝桌面應用程式來驗證設定。在登入畫面上選擇企業登入,然後使用您的公司登入資料進行驗證,以確認組態是否正常運作。如需下載和安裝步驟,請參閱 開始使用。
如果登入失敗,請針對步驟 1 的 OIDC 端點,驗證您在步驟 2 中輸入的值。如果任何值不正確,請刪除許可 → 延伸存取下的延伸存取,並使用正確的值重複步驟 2。
驗證設定之後,請將您的使用者導向 開始使用,以取得下載、安裝和登入指示。
疑難排解
redirect_mismatch錯誤-
確認 IdP 中的重新導向 URI 完全是
http://localhost:18080且設定為公有用戶端或原生平台。 - 登入後找不到使用者
-
IdP 權杖中的電子郵件必須與 Amazon Quick 中使用者的電子郵件完全相符。確認已佈建使用者,且兩個系統中的電子郵件地址皆相同。
- 字符驗證失敗
-
確認延伸存取組態中的發行者 URL 與您 IdP 的 OIDC 組態中的發行者 URL 完全相符。
- 同意或許可錯誤 (Microsoft Entra ID)
-
在 Azure 入口網站中授予管理員對必要 API 許可的同意。導覽至應用程式註冊的 API 許可頁面,然後選擇授予 【您的組織】 的管理員同意。
- 工作階段頻繁過期
-
確認您的 IdP 已設定為發出重新整理權杖。對於 Microsoft Entra ID,
offline_access範圍是必要的。對於 Okta,必須啟用重新整理字符授予類型,並且必須授予offline_access範圍。對於 Ping 身分,必須啟用重新整理字符授予類型,並且必須授予offline_access範圍。對於 PingFederate,也請確認已在 OIDC 政策中選取 Return ID Token On Refresh Grant。 invalid_scope錯誤 (Okta)-
確認您的授權伺服器上
offline_access已啟用 。導覽至安全性 → API → 授權伺服器 → 預設 → 範圍並確認範圍存在。同時驗證應用程式的存取政策是否允許重新整理權杖授予類型。 - 應用程式未啟用 (PingOne)
-
如果身分驗證立即失敗,但未到達 PingOne 登入頁面,請確認應用程式切換在 PingOne 管理員主控台中設定為已啟用。
- 重新整理後遺失電子郵件宣告 (PingFederate)
-
確認
email宣告已包含在 OIDC 政策屬性合約中,並對應至正確的使用者屬性。映射必須產生初始身分驗證和重新整理字符授予的email宣告。