配置中央授權伺服器
「中央驗證伺服器」(CAS) 可管理參與 SSO 架構之 PTC 產品之間的信任關係。CAS 可透過在驗證使用者之後授權使用者登入，以及透過發出並核對在服務提供者與資源伺服器之間交換的存取權杖，作為應用程式之間的代理程式使用。
以下是您在部署 CAS 時應考慮的一些一般提示：
• 審核使用者登入工作階段的最長有效時間，並考慮是否應在參與 SSO 解決方案的每個應用程式中使用相同的值。
• 確認系統在可接受的時間偏斜公差內工作。如果一或多個系統時鐘與 CAS 不同步，且超過在系統中設定的偏斜公差時間，組態將會擲回錯誤並防止使用者進行驗證。
PTC 之已啟用 SSO 的產品會使用 SSO 架構與標準協定實行下列兩個驗證流程：
• 聯合驗證
• 授權 - 使用 OAuth 授與類型的委派授權
聯合驗證
聯合驗證是透過將使用者的登入請求與儲存在識別提供者中的認證進行比較，來對該請求進行驗證的流程。
在 PTC 產品 SSO 架構中，應將中央驗證伺服器 (CAS) 配置為將使用者登入請求重新導向至您的企業 IdP。IdP 會核對使用者登入認證的真實性，並建立已驗證使用者的宣告。系統會使用 SAML 或 OIDC 實行驗證，具體視 PTC 產品支援的協定 (請參閱 PTC 產品支援的 SSO 協定) 與客戶組態而定。
確認驗證之後，系統會將宣告傳送至請求應用程式，指示已成功驗證使用者，並授權使用者登入。在此交易過程中，CAS 與 PTC 應用程式都沒有可見度，也不會管理使用者認證。當瀏覽器重新導向至 IdP 時，使用者名稱與密碼資訊的交換會在使用者用戶端代理 (瀏覽器) 與 IdP 之間直接發生。您必須針對位於相同聯合中的每個 PTC 產品建立單獨的服務提供者 (SP) 連線，且這些產品依賴於透過相同 CAS 進行的使用者驗證。
將根據 SSO 組態遵循標準 SAML 與 OIDC 驗證流程。在選取特定 CAS 技術以用於 PTC SSO 組態之前，應先檢閱該技術的支援選項。
下列順序圖描述了驗證流程。在此範例中，ThingWorx 作為 SP，PingFederate 是 CAS。ThingWorx 針對 SP 與 IdP 之間的驗證交換，使用開放標準 SAML 2.0 協定。
驗證流程如下：
1. 使用者嘗試存取服務提供者。
2. 服務提供者會為使用者產生 SAML 請求，並將請求傳送至 CAS。
3. CAS 會將 SAML 請求重新導向至 IdP。
4. IdP 會將使用者重新導向至驗證頁，以提供其認證 (例如使用者名稱與密碼)。在使用者輸入其認證之後，IdP 會產生 SAML 回應。如果使用者驗證成功，SAML 回應將包含內含使用者授權的 SAML 宣告。
5. 然後，IdP 會將回應重新導向至 CAS。
針對協力廠商 IdP，您必須在 SSO 設定中配置您的 CAS。
委派授權 (OAuth)
委派授權是一種概念，可讓服務提供者 (SP) 代表使用者採取動作或從資源伺服器 (RS) 存取資源，而無需使用者與 RS 共用其認證。
系統會從 CAS 請求 OAuth 2 存取權杖，之後會在從資源伺服器請求資料時使用這些權杖。在分配存取權杖之前，資源伺服器會依賴 CAS 來核對請求者是否為已驗證的使用者。您需要針對參與委派授權情境的每個 PTC 應用程式，建立單獨的 OAuth 用戶端。
PTC 產品會配置範圍作為額外的保護措施，來進一步保護由 OAuth 保護的資源。當服務提供者將存取權杖隨著其對資源伺服器資料的請求一起傳送時，存取權杖也必須附加針對資源伺服器中的資料註冊的範圍。如需詳細資訊，請參閱在委派授權中管理範圍。
PTC 產品針對互動式與非互動式用戶端皆支援 OAuth 授與類型。瞭解用戶端功能對於決定要使用的適當授與類型而言很重要。
 |
請務必查閱特定 PTC 產品文件集，以確認您產品支援的 OAuth 授與類型。
|
◦ 互動式：使用者向用戶端進行驗證，用戶端將代表相同使用者請求資源；允許存取資源的授權取決於一般使用者授權。
◦ 非互動式：也稱為機器對機器 (M2M) 互動。用戶端是一個應用程式，在請求 OAuth 權杖時必須向 CAS 識別其自身。OAuth 權杖中的識別是機器識別 (用戶端或服務主體)，而不應該是人類使用者。
下列順序圖描述了 OAuth 授權編碼流程。ThingWorx 是 SP，PingFederate 是 CAS，Windchill 是 RS。互動式用戶端中的 ThingWorx 配置為使用開放標準 OAuth2 協定授權編碼流程來以安全、可靠且有效的方式授權 SP 以存取資源，並使用一般使用者的使用者 ID 進行授權以擷取資源。
授權流程如下：
1. 在從 IdP 接收 SAML 回應之後，CAS 會傳送授與授權請求頁，供使用者核准。CAS 會使用授與授權請求頁，取得產生 OAuth 代碼的授權。
2. 在使用者授與存取權之後，CAS 會產生 OAuth 授權代碼。然後，CAS 會將 SAML 回應與授權代碼重新導向至服務提供者。
3. 在服務提供者接收 OAuth 授權代碼之後，會使用授權代碼從 CAS 請求存取權杖與重新整理權杖。
4. CAS 會驗證授權代碼，並產生 OAuth 存取權杖與重新整理權杖。然後，CAS 會將這兩個權杖傳送至服務提供者。
5. 資源擁有者 (通常為使用者) 會從服務提供者 (需要來自資源伺服器的資料) 請求內容。
6. 服務提供者會使用存取權杖，代表資源擁有者從資源伺服器請求內容。
7. 資源伺服器會向 CAS 核對存取權杖。
8. 然後，資源伺服器會取得請求的內容，並將其傳送至服務提供者。
9. 接收內容之後，服務提供者會將其遞送至資源擁有者。
可以使用此相同流程配置替代 CAS 技術；可能需要考慮特定的配置步驟與設定。
在非互動式情況下，「用戶端認證」流程用來將用戶端 ID 與密碼傳遞至 CAS，以擷取 OAuth 權杖。然後，會將 OAuth 權杖傳遞至 RS 以擷取請求的資源。必須將 RS 配置為支援「用戶端認證」授與類型，才能管理 OAuth 權杖及驗證請求。下列順序圖描述了以從 Windchill 請求資源的非互動式用戶端作為 RS 的「用戶端認證」流程。
您也可以將 SSO 架構配置為具有多個服務提供者與多個資源伺服器的聯合。SP 與 RS 組態由單一 CAS 管理。如此一來，就會在聯合之中共用所有使用者識別。在下列範例中，Windchill Navigate 是服務提供者，而 Windchill 與 SAP 是資源伺服器。
