中央認証サーバーの設定 - PingFederate
PTC は、中央認証サーバー (CAS) として PingFederate をサポートしています。CAS は、SSO フレームワークに参加している PTC 製品間の信頼関係を管理します。CAS はブローカーとして機能し、ユーザーが認証されるとユーザーログインを認証し、サービスプロバイダとリソースサーバーの間で交換されるアクセストークンを発行および検証します。
PTC 製品は、SSO フレームワーク内で以下の要素を実装します。
1. SAML アサーションを使用して IdP でユーザーを認証します。
2. 次に、ユーザーが認証された後、PingFederate はユーザーに対して権限承認ページを表示し、ここで、ユーザーは、リソースサーバーからのデータを、使用しているアプリケーションと共有するかどうかを尋ねられます。
PingFederate を使用している場合は、PingFederate ドキュメンテーションを参照してください。PingFederate を展開する際に考慮する必要がある一般的なヒントをいくつか以下に示します。
• ユーザーログインセッションが有効である最大時間をレビューし、SSO ソリューションに参加している各アプリケーションで同じ値を使用するかどうかを検討します。
• 許容される時間スキュー公差内でシステムが動作していることを確認します。1 つ以上のシステムクロックが CAS と同期しておらず、システムで設定されているスキュー公差時間を超えると、コンフィギュレーションによってエラーがスローされ、ユーザーの認証が阻止されます。
フェデレーション認証
フェデレーション認証は、ユーザーのログインリクエストを ID プロバイダに保存されている資格証明と比較することによって検証するプロセスです。
PTC 製品の SSO アーキテクチャでは、PingFederate はユーザーログインを直接認証しません。代わりに、ユーザーログインリクエストをエンタープライズ IdP にリダイレクトするように PingFederate を設定しなければなりません。IdP は、ユーザーログイン資格証明の真正性を検証し、ユーザーが認証されたことを示すアサーションを PingFederate に送信します。次に、PingFederate は、ユーザーが認証されたことを示すアサーションをリクエスト元のアプリケーションに送信し、ユーザーログインを認証します。このトランザクション全体にわたり、PingFederate はユーザー資格証明を処理しません。ブラウザが IdP にリダイレクトされると、ユーザー名およびパスワード情報の交換がユーザークライアントエージェント (ブラウザ) と IdP の間で直接行われます。PingFederate を介してユーザー認証をルーティングする PTC 製品ごとに個別のサービスプロバイダ接続を作成しなければなりません。
次の例では、ThingWorx がサービスプロバイダ、PingFederate が CAS です。ThingWorx では、サービスプロバイダと ID プロバイダの間の認証交換にオープン規格の 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 設定で PingFederate を設定しなければなりません。詳細については、サードパーティ IdP 用の認証の手動設定を参照してください。
委任認証
委任認証は、ユーザーがリソースサーバー (RS) と資格証明を共有することなく、サービスプロバイダがユーザーに代わって RS から操作を実行したりリソースにアクセスしたりできるという概念です。
PingFederate は、PTC 製品がリソースサーバーからのデータのリクエストに含める OAuth 2 アクセストークンを生成します。リソースサーバーは、アクセストークンの真正性を検証するために CAS に依存します。委任認証シナリオに参加している PTC アプリケーションごとに個別の OAuth クライアントを作成しなければなりません。
PTC 製品は、追加の保護措置として範囲を設定することにより、OAuth によって保護されているリソースをさらに保護します。サービスプロバイダがリソースサーバーからのデータのリクエストとともにアクセストークンを送信する際、リソースサーバー内のデータに対して登録されている範囲がアクセストークンに添付されていなければなりません。詳細については、委任認証での範囲の管理を参照してください。
次の例では、ThingWorx がサービスプロバイダ、PingFederate が CAS、Windchill がリソースサーバーです。ThingWorx では、安全性、信頼性、および効率性の高い方法でサービスプロバイダがリソースにアクセスすることを認証するために、オープン規格の OAuth2 プロトコルが使用されています。
権限承認プロセスは次のとおりです。
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 がリソースサーバーです。
