中央認証サーバーおよび ID プロバイダとして Azure AD を使用
 |
ThingWorx をアップグレードし、CAS として AzureAD を使用し、ThingWorx コネクタベースの SSO 接続タイプを使用してリソースサーバーに接続している場合、sso-settings.json ファイル内の AuthorizationServersSettings でプロパティ mandatoryScopes の値を offline_access に設定する必要があります。
AzureAD の動作の変更に伴い、新規トークンを取得するプロセスでリフレッシュトークンは提供されません。その結果、アクセストークンが期限切れになった後で、セッション中にアクセストークンを再発行することはできません。この問題を解決するには、ユーザーは再度ログインし、新しいトークンを正常な状態に戻す必要があります。
|
ThingWorx では、SSO 対応製品を管理するために、中央認証サーバー (CAS) および ID プロバイダ (IdP) の両方として機能する Azure AD がサポートされています。ユーザーは自分のアプリケーションからデータにアクセスし、そのデータを ThingWorx セッションで使用できます。
この SSO アーキテクチャでは、ThingWorx はユーザー認証の SAML リクエストを Azure AD に送信します。Azure AD はユーザー資格証明の真正性を確認し、ユーザーログインを認証するアサーションを ThingWorx に送信します。
Azure AD は、ThingWorx と、ThingWorx がデータを取得するリソースサーバーとの間の信頼関係も管理します。Azure AD は、リソースプロバイダからのデータのリクエストに ThingWorx が組み込むアクセストークンを生成します。リソースサーバーは、アクセストークンの真正性を確認するために Azure AD に依存します。このシナリオは、ユーザーがリソースサーバーからデータを取得するために ThingWorx を認証するので、委任認証と呼ばれます。ThingWorx、Azure AD、およびその他の PTC 製品の間で交換されるアクセストークンは、OAuth プロトコルを使用します。
次に進む前に、PTC の ID とアクセスの管理のヘルプセンターに目を通してください。このヘルプセンターでは、シングルサインオンと関連する用語の概要、および Azure AD の設定に関する詳細情報が提供されています。以下のような、シングルサインオンコンフィギュレーションの例も示されています。
• Azure AD での認証の設定
• Azure AD での承認の設定