將 PingFederate 作為中央授權伺服器 > 配置中央授權伺服器 - PingFederate
配置中央授權伺服器 - PingFederate
PTC 支援 PingFederate 作為中央授權伺服器 (CAS)。CAS 可管理參與 SSO 架構之 PTC 產品之間的信任關係。CAS 可透過在驗證使用者之後授權使用者登入,以及透過發出並核對在服務提供者與資源伺服器之間交換的存取權杖,作為應用程式之間的代理程式使用。
PTC 產品可在 SSO 架構中實行下列元素:
1. 使用 SAML 宣告向 IdP 驗證使用者。
2. 然後,在驗證使用者之後,PingFederate 會向使用者顯示授與核准頁,詢問使用者是否要將資源伺服器的資料與其使用的應用程式共用。
當與 PingFederate 搭配使用時,您應審核 PingFederate 文件集。以下是您在部署 PingFederate 時應考慮的一些一般提示:
審核使用者登入工作階段的最長有效時間,並考慮是否應在參與 SSO 解決方案的每個應用程式中使用相同的值。
確認系統在可接受的時間偏斜公差內工作。如果一或多個系統時鐘與 CAS 不同步,且超過在系統中設定的偏斜公差時間,組態將會擲回錯誤並防止使用者進行驗證。
聯合驗證
聯合驗證是透過將使用者的登入請求與儲存在識別提供者中的認證進行比較,來對該請求進行驗證的流程。
在 PTC 產品 SSO 架構中,PingFederate 不會直接驗證使用者登入。而是應該將 PingFederate 配置為將使用者登入請求重新導向至您的企業 IdP。IdP 會核對使用者登入認證的真實性,並將宣告傳送至已驗證使用者的 PingFederate。然後,PingFederate 會將宣告傳送至已驗證使用者的請求應用程式,並授權使用者登入。在此交易中,PingFederate 不會處理使用者認證;當瀏覽器重新導向至 IdP 時,使用者名稱與密碼資訊的交換會在使用者用戶端代理 (瀏覽器) 與 IdP 之間直接發生。您必須針對透過 PingFederate 路由使用者驗證的每個 PTC 產品,建立單獨的服務提供者連線。
在下列範例中,ThingWorx 是服務提供者,而 PingFederate 是 CAS。ThingWorx 會針對服務提供者與識別提供者之間的授權交換,使用開放標準 SAML 2.0 通訊協定。
SSO 驗證流程範例
驗證流程如下:
1. 使用者嘗試存取服務提供者。
2. 服務提供者會為使用者產生 SAML 請求,並將請求傳送至 CAS。
3. CAS 會將 SAML 請求重新導向至 IdP。
4. IdP 會將使用者重新導向至驗證頁,以提供其認證 (例如使用者名稱與密碼)。在使用者輸入其認證之後,IdP 會產生 SAML 回應。如果使用者驗證成功,SAML 回應將包含內含使用者授權的 SAML 宣告。
5. 然後,IdP 會將回應重新導向至 CAS。
PTC 會針對以 PingFederate 作為 IdP 的 PingFederate 組態,提供自動化指令集。如需詳細資訊,請參閱自動將 PingFederate 配置為中央授權伺服器
針對協力廠商 IdP,您必須在 SSO 設定中配置 PingFederate。如需詳細資訊,請參閱手動配置協力廠商 IdP 的驗證
委派授權
委派授權是一種概念,可讓服務提供者代表使用者採取動作或從資源伺服器 (RS) 存取資源,而無需使用者與 RS 共用其認證。
PingFederate 會產生 OAuth 2 存取權杖,PTC 產品會將其包含在對資源伺服器資料的請求中。資源伺服器會依賴 CAS 來核對存取權杖的真實性。您需要針對參與委派授權情境的每個 PTC 應用程式,建立單獨的 OAuth 用戶端。
PTC 產品會配置範圍作為額外的保護措施,來進一步保護由 OAuth 保護的資源。當服務提供者將存取權杖隨著其對資源伺服器資料的請求一起傳送時,存取權杖也必須附加針對資源伺服器中的資料註冊的範圍。如需詳細資訊,請參閱在委派授權中管理範圍
在下列範例中,ThingWorx 是服務提供者,PingFederate 是 CAS,而 Windchill 是資源伺服器。ThingWorx 會使用開放標準 OAuth2 通訊協定授權服務提供者,以安全、可靠且有效的方式存取資源。
SSO 授權流程範例
授權流程如下:
1. 在從 IdP 接收 SAML 回應之後,CAS 會傳送授與授權請求頁,供使用者核准。CAS 會使用授與授權請求頁,取得產生 OAuth 代碼的授權。
2. 在使用者授與存取權之後,CAS 會產生 OAuth 授權代碼。然後,CAS 會將 SAML 回應與授權代碼重新導向至服務提供者。
3. 在服務提供者接收 OAuth 授權代碼之後,會使用授權代碼從 CAS 請求存取權杖與重新整理權杖。
4. CAS 會驗證授權代碼,並產生 OAuth 存取權杖與重新整理權杖。然後,CAS 會將這兩個權杖傳送至服務提供者。
5. 資源擁有者 (通常為使用者) 會從服務提供者 (需要來自資源伺服器的資料) 請求內容。
6. 服務提供者會使用存取權杖,代表資源擁有者從資源伺服器請求內容。
7. 資源伺服器會向 CAS 核對存取權杖。
8. 然後,資源伺服器會取得請求的內容,並將其傳送至服務提供者。
9. 接收內容之後,服務提供者會將其遞送至資源擁有者。
您也可以實行具有多個資源伺服器的 SSO 架構。在此範例中,ThingWorx Navigate 是服務提供者,而 Windchill 與 SAP 是資源伺服器。
具有多個資源伺服器的 SSO 架構。
這是否有幫助?