SAML 2.0 認証をWindchillに統合することで、フェデレーションされたシングルサインオンソリューションへの参加が可能になります。このトピックは、SAML 2.0 仕様に関する必要な知識があることを前提としています。詳細については、OASIS Security Services Technical Committee によって https://www.oasis-open.org/standards#samlv2.0 で公開されている SAML v2.0 のドキュメンテーションを参照してください。

Windchill認証の戦略では認証の実施に Web サーバーが利用されます。次の手順は、PTC が Windchill の SAML との互換性を確認するために PTC HTTP Server で Shibboleth Service Provider を使用してテストした統合を示しています。Windchill のインストールでサポートされている Shibboleth のバージョンについては、Windchill ソフトウェアマトリクスを参照してください。テストは特定の条件下で実施され、設定例として提供されます。サイトごとに SAML の実装方法は異なります。SAML サービスプロバイダの選択はユーザーが行います。PTC がテストしたのは Shibboleth Service Provider の適合性のみであるため、ほかの SAML サービスプロバイダの適合性については一切保証いたしません。PTC は直接的には SAML サービス プロバイダの設定またはコンフィギュレーションをサポートしていません。選択した SAML サービスプロバイダの設定については、その製品のドキュメンテーションを参照するか、カスタマーサポートにお問い合わせください。この手順では、フェデレーション内でアイデンティティプロバイダを確立または設定する方法については説明していません。アイデンティティプロバイダの確立については、OASIS または Shibboleth のドキュメンテーションを参照するか、アイデンティティプロバイダの管理者にお問い合わせください。

ほとんどのシングルサインオンソリューションでは SAML Web ブラウザ SSO プロファイルが使用されます。このシナリオでは、少なくとも 3 つの役割があります。

OASIS SAML v2.0 のドキュメンテーションには、これらの役割やその他の事柄についてさらに詳しい説明があります。次の図は、これらの役割間の認証プロセスを表しています。

アイデンティティプロバイダを、その他のアイデンティティプロバイダへのサービスプロバイダとして設定できます。この手順における「アイデンティティプロバイダ」とは、サービスプロバイダが直接通信する必要があるアイデンティティプロバイダのみを指し、フェデレーションされたその他のアイデンティティプロバイダのことは指していません。

Shibboleth Service Provider を使用して Windchill で SAML 機能を有効化するには、次のステップを実行する必要があります。

Shibboleth デーモンのログファイルは <shibboleth のインストール場所>/var/log/shibboleth にあります。これらのログファイルを Linux で読み取るにはルートアクセスが必要です。HTTP サーバー上の別の場所に切り替える場合、Shibboleth モジュールログファイルは <<インストールディレクトリ>>/var/log/shibboleth-www にあります。Linux では、非ルートユーザーがこのディレクトリに書き込むことはできません。ポート 80 で Web サーバーを実行しようとしていない場合、PTC HTTP Server は通常、非ルートユーザーとして動作します。その場合、ログファイルは作成されません。/etc/shibboleth/native.log を修正することでログファイルの場所を変更できます。次の 2 つのプロパティを書き込み可能な場所に変更します。

たとえば、ディレクトリ /opt/ptc/logs を作成し、そのディレクトリ内のログファイルを使用するようこれらのプロパティを設定します。

デバッグログの作成を有効にするには、次の手順に従います。

/etc/shibboleth/native.loggger を編集し、rootCategory ログレベルを DEBUG に変更します(log4j.rootCategory=INFO, native_log, warn_logがlog4j.rootCategory=DEBUG, native_log, warn_log になります)。これにより、Shibboleth デーモンと shibboleth モジュールおよび /var/log/shibboleth-www または配置した場所にあるネイティブファイルの詳細レベルが大幅に向上します。

Shibboleth Service Provider には、Shibboleth デーモンおよび PTC HTTP Server 内のモジュールの 2 つのコンポーネントが含まれています。このどちらかを再起動する場合、両方のサービスを再起動する必要があります。Windows では、Shibboleth デーモンは Windows サービスとして設定され、サービスコントロールパネルから再起動できます。Linux では、これは shibd.service systemd ユニットであり、systemctl を使用して停止および開始できます。PTC HTTP Server の起動と停止の詳細については、 HTTP Server および Windchill メソッドサーバーの起動を参照してください。

Creo Parametricと Windchill Workgroup Manager の埋め込みブラウザは、プライマリブラウザ内のWindchill セッションからのログインキャッシュを使用できません。このため、ユーザーには Creo ParametricとWindchill Workgroup Manager の埋め込みブラウザから追加のログインリクエストが表示されるので、完全なシングルサインオンにはなりません。これらの埋め込みブラウザは、SAML の設定で指定されているアイデンティティプロバイダによってユーザーを認証します。

Arbortext Editorがユーザーの PTC ソリューションの一部である場合は、ユーザーのサイトで SAML を設定するときに、上記以外の注意事項も考慮する必要があります。詳細については、https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS250036 を参照してください。

一部のクライアントは SAML 認証の設定がサポートされていません。ご自分のサイトで SAML 認証を実装する前に、サイトでこれらのクライアントがどの程度使用されているか、およびこれらのクライアントの排除が SAML 認証の使用に対する妨げになるかどうかを確認してください。PTC は次のクライアントの SAML 認証設定をサポートしていません。

クライアントの SAML 認証との互換性に関する最新情報については、https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS250038 のアーティクルを参照してください。

以降のステップでは、PingFederate と Windchill サーバー上の Shibboleth SP インストール間の接続を設定する方法について説明します。これはオプションの設定であり、Windchill で SAML 認証を有効にするための必須の設定ではありません。会社の SSO フェデレーションの要件に応じて、SAML の展開で別の IdP を使用することもできます。サポートされているバージョンの PingFederate のダウンロードおよびライセンスの取得の詳細については、シングルサインオン認証を参照してください。

これらのステップは前述の SAML 設定のトピックに掲載されている手順を補うものであり、PingFederate と Shibboleth Service Provider がすでにインストールされていることを前提としています。IdP としての PingFederate と Shibboleth Service Provider の設定ステップは相互に関連しているので、もう一方のクライアントからエクスポートされたメタデータ XML ファイルをインポートするためには、各クライアントの設定を更新する必要があります。