中央認証サーバーの設定
中央認証サーバー (CAS) は、SSO フレームワークに参加している PTC 製品間の信頼関係を管理します。CAS はブローカーとして機能し、ユーザーが認証されるとユーザーログインを認証し、サービスプロバイダとリソースサーバーの間で交換されるアクセストークンを発行および検証します。
CAS をデプロイする際に考慮する必要がある一般的なヒントをいくつか以下に示します。
• ユーザーログインセッションが有効である最大時間をレビューし、SSO ソリューションに参加している各アプリケーションで同じ値を使用するかどうかを検討します。
• 許容される時間スキュー公差内でシステムが動作していることを確認します。1 つ以上のシステムクロックが CAS と同期しておらず、システムで設定されているスキュー公差時間を超えると、コンフィギュレーションによってエラーがスローされ、ユーザーの認証が阻止されます。
PTC SSO 対応製品では、SSO フレームワークと標準プロトコルを使用して、以下の 2 つの認証フローが実装されます。
• フェデレーション認証
• 認証 - OAuth 付与タイプを使用した委任認証
フェデレーション認証
フェデレーション認証は、ユーザーのログインリクエストを ID プロバイダに保存されている資格証明と比較することによって検証するプロセスです。
PTC 製品の SSO アーキテクチャでは、ユーザーログインリクエストをエンタープライズ IdP にリダイレクトするように中央認証サーバー (CAS) を設定する必要があります。IdP は、ユーザーログイン資格証明の真正性を検証し、ユーザーが認証されたことを示すアサーションを作成します。認証は、PTC 製品でサポートされるプロトコル (PTC 製品でサポートされる SSO プロトコルを参照) および顧客のコンフィギュレーションに応じて、SAML または OIDC を使用して実装されます。
認証が確認されると、ユーザーが正常に認証されたことを示すアサーションがリクエスト元のアプリケーションに送信され、ユーザーログインが承認されます。このトランザクション中、ユーザー資格証明は CAS と PTC アプリケーションのどちらにも表示されず、これらのアプリケーションによって管理されません。ブラウザが IdP にリダイレクトされると、ユーザー名とパスワードの情報がユーザークライアントエージェント (ブラウザ) と IdP の間で直接交換されます。同じフェデレーション内にあり、同じ CAS を介したユーザー認証に依存する PTC 製品ごとに、個別のサービスプロバイダ (SP) 接続を作成する必要があります。
SSO コンフィギュレーションに基づいて、標準の SAML および OIDC 認証フローに従います。特定の CAS テクノロジを PTC SSO コンフィギュレーションで使用する前に、その CAS テクノロジでサポートされているオプションを確認する必要があります。
次のシーケンス図に、認証フローを示します。この例では、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 への応答をリダイレクトします。
PTC は、PingFederate が IdP として設定されている PingFederate コンフィギュレーション用の自動化スクリプトを提供しています。詳細については、中央認証サーバーとしての PingFederate の自動設定を参照してください。
サードパーティ IdP の場合、SSO 設定で CAS を設定しなければなりません。
委任認証 (OAuth)
委任認証は、ユーザーがリソースサーバー (RS) と資格証明を共有することなく、サービスプロバイダ (SP) がユーザーに代わって RS から操作を実行したりリソースにアクセスしたりできるという概念です。
OAuth 2 アクセストークンは CAS からリクエストされ、リソースサーバーからのデータのリクエストで使用されます。リソースサーバーは、アクセストークンを割り当てる前に、リクエスト元を認証済みユーザーとして検証するために CAS に依存します。委任認証シナリオに参加している PTC アプリケーションごとに個別の OAuth クライアントを作成しなければなりません。
PTC 製品は、追加の保護措置として範囲を設定することにより、OAuth によって保護されているリソースをさらに保護します。サービスプロバイダがリソースサーバーからのデータのリクエストとともにアクセストークンを送信する際、リソースサーバー内のデータに対して登録されている範囲がアクセストークンに添付されていなければなりません。詳細については、委任認証での範囲の管理を参照してください。
PTC 製品は、対話型クライアントと非対話型クライアントの両方で、OAuth 付与タイプをサポートしています。使用する適切な付与タイプを決定するには、クライアントの機能について理解することが重要です。
 |
使用する製品でサポートされている OAuth 付与タイプを、該当する PTC 製品ドキュメントで確認してください。
|
◦ 対話型: ユーザーがクライアントで認証されると、クライアントがそのユーザーに代わってリソースをリクエストします。リソースへのアクセスを許可する権限は、エンドユーザーの権限に基づきます。
◦ 非対話型: マシンツーマシン (M2M) 対話とも呼ばれます。クライアントはアプリケーションであり、OAuth トークンをリクエストする際に CAS に対してクライアント自身の ID を示す必要があります。OAuth トークンの ID はマシンの ID (クライアントまたはサービスプリンシパル) であり、人間のユーザーを意図していません。
次のシーケンス図に、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 に渡され、リクエストされたリソースが取得されます。OAuth トークンを管理してリクエストを検証できるようにするには、クライアント資格証明付与タイプをサポートするように RS を設定する必要があります。次のシーケンス図に、非対話型クライアントが RS である Windchill からリソースをリクエストするクライアント資格証明フローを示します。
SSO アーキテクチャは、複数のサービスプロバイダと複数のリソースサーバーを使用するフェデレーションとして設定することもできます。SP と RS のコンフィギュレーションは、1 つの CAS によって管理されます。これにより、すべてのユーザー ID がフェデレーション間で共有されます。次の例では、Windchill Navigate がサービスプロバイダ、Windchill と SAP がリソースサーバーです。
