インストールおよびアップグレード > 高度な展開の検討事項 > 認証 > Windchill における代替認証の設定 > シングルサインオン認証 > Security Assertion Markup Language (SAML) 認証
  
Security Assertion Markup Language (SAML) 認証
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 つの役割があります。
役割
説明
ユーザーエージェント
実際のユーザーの代わりにサービスプロバイダからリクエストを行うブラウザクライアント。
サービスプロバイダ
フェデレーション内のその他のエンティティにサービスを提供するエンティティ。ユーザーエージェントはプリンシパルの代わりにサービスプロバイダにリクエストを行います。
アイデンティティプロバイダ
アイデンティティプロバイダ (IdP) は、プリンシパルのアイデンティティ情報を作成、維持、管理し、フェデレーション内の各サービスに対してプリンシパルを認証します。
OASIS SAML v2.0 のドキュメンテーションには、これらの役割やその他の事柄についてさらに詳しい説明があります。次の図は、これらの役割間の認証プロセスを表しています。
アイデンティティプロバイダを、その他のアイデンティティプロバイダへのサービスプロバイダとして設定できます。この手順における「アイデンティティプロバイダ」とは、サービスプロバイダが直接通信する必要があるアイデンティティプロバイダのみを指し、フェデレーションされたその他のアイデンティティプロバイダのことは指していません。
Shibboleth Service Provider を使用して Windchill で SAML 機能を有効化するには、次のステップを実行する必要があります。
* 
Shibboleth は、Windchill Business Reporting の ID 管理ソフトウェアとしてはサポートされていません。
1. Shibboleth Service Provider のインストール
Shibboleth は Shibboleth Consortium からダウンロードできます。次のリソースを使用して、PTC HTTP Server と同じシステムに Shibboleth をダウンロードしてインストールします。
Shibboleth インストールファイル
Linux の場合、Shibboleth Service Provider は yum リポジトリを介してインストールできます。詳細については、Shibboleth インストールドキュメンテーションを参照してください。
インストールした後、お使いのサイトで Shibboleth を設定する必要があります。
2. Shibboleth Service Provider の設定
Shibboleth Service Provider を設定するには 2 つの XML ファイルを編集する必要があります。
a. <Shibboleth インストールディレクトリ>/etc/shibboleth/shibboleth2.xml にある shibboleth2.xml を編集します。Linux では、<Shibboleth インストールディレクトリ> ディレクトリが / ディレクトリです。
少なくとも次の設定を変更する必要があります。
▪ お使いのサービスプロバイダの一意の entityID を設定します。これは <ApplicationDefaults> タグの entityID 属性によって設定します。デフォルト値は "https://sp.example.org/shibboleth" です。この entityID はサービスプロバイダを識別する一意の文字列である必要があります。URL であれば一意性を十分に満たしています。例: <ApplicationDefaults entityID="https://windchillserver.company.com"。
▪ プロパティ sessionHook を設定して、値 "/Windchill/sso/shibboleth/sessionHook" をとる <ApplicationDefaults> タグを以下のように追加します。
<ApplicationDefaults sessionHook="/Windchill/sso/shibboleth/sessionHook"
▪ Windchill サーバーに渡されるように REMOTE_USER 属性を設定する必要があります。
Web アプリケーションに渡される SAML 属性を定義する、<ApplicationDefaults> エレメントの REMOTE_USER 属性を設定します。この属性のフォーマットは子属性をスペースで区切った文字列であり、ここで各子属性は attribute-map.xml ファイルでマッピングされている ID です。この属性文字列は、この手順で後から説明するコンフィギュレーション attribute-map.xml によって Shibboleth Service Provider に公開されます。Null 以外の値を返す 1 つ目の属性名が使用されます。たとえば、REMOTE_USER の値を返すために属性名 'uid' を使用するよう属性マップを設定している場合、REMOTE_USER の設定は REMOTE_USER="uid"でなければなりません。
詳細については、NativeSPApplication に関する Shibboleth Service Provider のドキュメンテーションを参照してください。
▪ アイデンティティプロバイダの entityID と一致するように SSO の entityID を設定します。これは <SSO> タグの entityID 属性によって設定します。デフォルト値は https://idp.example.org/idp/shibboleth です。entityID はアイデンティティプロバイダによって提供される値に置き換える必要があります。この値については、アイデンティティプロバイダの管理者にお問い合わせください。値が "MyIDP" の場合、この設定は <SSO entityID="MyIDP"> になります。
▪ プロパティ postArtifact、template、および outgoingBindings を設定して <SSO> タグを追加します。これらのプロパティの値を以下の例に示します。
<SSO postArtifact="true" template="bindingTemplate.html" outgoingBindings="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
▪ アイデンティティプロバイダのメタデータの設定
Shibboleth Service Provider は、XML フォーマットによるアイデンティティプロバイダのメタデータにアクセス可能でなければなりません。メタデータを XML ファイルとしてエクスポートする必要があるアイデンティティプロバイダや、URL を使用してメタデータにアクセス可能なアイデンティティプロバイダがあります。メタデータを Shibboleth Service Provider に提供する適切な方法については、アイデンティティプロバイダの管理者に問い合わせるか、ベンダーのドキュメンテーションを参照してください。
▪ メタデータが XML ファイルとして提供される場合、shibboleth2.xml ファイルのメインドキュメント内にタグ <MetadataProvider type="XML" validate="true" path="<メタデータ xml ファイルの場所>"/> を追加し、<メタデータ xml ファイルの場所> をご自分のメタデータファイルの場所に置き換えます。メタデータファイルが shibboleth2.xml ファイルと同じ場所にある場合、ファイル名だけが必要です。
▪ URL を介してメタデータにアクセス可能な場合、タグ <MetadataProvider type="XML" validate="true" uri="<IDP メタデータへの URL>" backingFilePath="federation-metadata.xml"/> を使用することでこれをロードできます。backingFilePath を指定することで、その URL にアクセスできない場合に、ローカルに保存したメタデータのコピーを使用できます。
Shibboleth Service Provider のドキュメンテーションに、本番環境で役立つその他の属性の設定について掲載されています。
b. <Shibboleth インストールディレクトリ>/opt/shibboleth/sp/etc/shibboleth/attribute-map.xml にある attribute-map.xml ファイルを編集します。
属性のアサーションを処理するには、この属性マッピングファイルを設定する必要があります。属性は名前とフォーマット別に SAML サービスプロバイダに公開されます。名前は実際の属性名か名前空間のどちらかを指します。属性アサーションのフォーマットは SAML 仕様の一部です。属性命名管理の詳細については、NativeSPConfiguration の NativeSPAttributeExtractor と NativeSPConfiguration に関する Shibboleth Service Provider のドキュメンテーションを参照してください。
一般的なシナリオとして、IdP の場合、"uid" などの名前付き文字列によって識別される名前フォーマット"urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"で属性をアサーションします。この例では、次の設定では、REMOTE_USER に使用される uid 文字列に IdP から uid の値がマッピングされます。
<Attribute name="uid" id="uid"/>
特定の名前空間または名前フォーマットが使用されるさらに複雑なシナリオについては、Shibboleth のドキュメンテーションを参照してください。アイデンティティプロバイダからの属性アサーションの詳細については、IdP 管理者にお問い合わせください。
3. shibboleth_install_directory/etc/shibboleth にあるファイル bindingTemplate.html を編集します。Linux では、shibboleth_install_directory ディレクトリは / ディレクトリです。
カスタムコンフィギュレーションが実装されている場合、カスタム変更を bindingTemplate.html の変更とマージします。変更をマージする前に、カスタマイズのバックアップをとることをお勧めします。
$WT_HOME/codebase/WEB-INF/templates/sso/shibboleth にサンプル bindingTemplate.html が用意されており、これは参照目的でのみ使用します。
* 
Windchill インストールディレクトリから Shibboleth ディレクトリにサンプルファイル bindingTemplate.html をコピーしないでください。
サンプル bindingTemplate.html には以下のコードが含まれています。
<!-- PTC Recommended Customization(1) Start -->
<body onload="submit();">
<!-- PTC Recommended Customization(1) End -->
…
<!-- PTC Recommended Customization(2) Start -->
<script type="text/javascript">
/**
*Saves the URL fragment to session store, if it is available in browsers address bar
*/
function saveURLFragment() {
var URL_FRAGMENT_KEY = 'WINDCHILL_SSO_URL_FRAGMENT';
var windchillStore = window.sessionStorage;
if (windchillStore) {
var hash = document.location.href.split('#')[1];
if (hash && hash.length > 0) {
windchillStore.setItem(URL_FRAGMENT_KEY, hash);
} else {
// clean-up, if left by previous incomplete login attempt.
windchillStore.removeItem(URL_FRAGMENT_KEY);
}
}
}
function submit() {
saveURLFragment();
document.forms[0].submit();
}
</script>
<!-- PTC Recommended Customization(2) End -->
4. Web コンテナコンフィギュレーション用に以下のファイルを修正します。
a. $WT_HOME/codebase/WEB-INF にある web.xml を編集して、/ptc1/* や /app/* など、/sso/* URL の新規エントリを MVCDispatcher <servelet-mapping> に追加します。
たとえば、次のようになります。
<servlet-mapping>
<servlet-name>MVCDispatcherservlet-name>MVCDispatcher>
…
<url-pattern>/sso/*</url-pattern>
</servlet-mapping>
b. $WT_HOME/tomcat にある config.xml を編集して、/ptc1/* や /app/* など、/sso/* URL の新規エントリを <target name="-addTargetedUriWorkerMapEntries"> に追加します。
たとえば、次のようになります。
<target name="-addTargetedUriWorkerMapEntries">
…
<echo file="${uriworkerFile}" append="true" message="/${appName}/sso/*=${iisAjpWorker}${line.separator}">
</target>
5. サービスマネージャで Shibboleth デーモンサービスを再起動します。
6. PTC HTTP Server を設定します。
Shibboleth Service Provider モジュールで PTC HTTP Server を設定する必要があります。
* 
PTC HTTP Server で HTTPS を設定することを強くお勧めします。シングルサインオン (SSO) ソリューションは、SSL によるセキュリティ上の利点に取って代わるものではありません。詳細については、HTTP Server および Windchill の HTTPS の設定を参照してください。
a. mod_shib モジュールを有効にして初期オプションを設定します
a. ファイル <Shibboleth インストールディレクトリ>/etc/shibboleth/apache24.config を <http サーバーディレクトリ>/conf/conf.d/00-1mod_shib.conf にコピーします。最初にロードされるモジュールの 1 つになるためには、このファイルに 00-1mod_shib.conf という名前を付ける必要があります。
b. このファイルをコピーした後で編集し、命令 ShibCompatValidUserを On に設定します。このデフォルト値は Off です。
b. Windchill ディレクトリのデフォルトの認証規則を無効にし、匿名および代替の認証プレフィックス規則を維持します。
a. <http server directory> 内の windchill シェルで、次のコマンドを実行します。
ant -DprotocolAuthOnly=true -f webAppConfig.xml regenAllWebApps
これによって Windchill でデフォルトの認証規則が無効になります。
c. apache 構成で SAML SSO 認証を有効にします。
次のコンテンツを含む新しいファイル <http サーバーディレクトリ>/conf/conf.d/30-app-[WindchillWebAppName]-1Auth.conf を作成します。
<LocationMatch ^/+Windchill/+(;.*)?>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
</LocationMatch>
SAML SSO 認証は、Windchill ヘルプセンターと、PTC HTTP Server にインストールされているその他のすべての Web アプリケーションでも有効になっていなければなりません。
Windchill ヘルプセンター用に、次のコンテンツを含む新規ファイル <http サーバーディレクトリ>/conf/conf.d/30-app-[WindchillWHCWebAppName]-WHC-1Auth.conf を作成します。
<LocationMatch ^/+Windchill-WHC/+(;.*)?>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
</LocationMatch>
PTC HTTP Server にインストールされているその他の Web アプリケーションについても、同様のステップに従います。
d. <http_server_directory>/conf/conf.d/30-app-Windchill-AJP.conf を修正して、/ptc1 や /app URL で使用可能なエントリと同様に、/sso/* URL のエントリを追加します。
たとえば、次のようになります。
JkMount /Windchill/sso/* ajpWorker
7. Shibboleth Service Provider のメタデータをアイデンティティプロバイダに提供します。
Shibboleth SP のメタデータには URL を介してアクセスできます。Shibboleth Service Provider をアイデンティティプロバイダに登録するためにはアイデンティティプロバイダにこの URL を提供する必要があります。この URL は <PTC HTTP Server の URL>/Shibboleth.sso/Metadata のように構成されています。たとえば、PTC HTTP Server の URL が https://windchill.company.comである場合、Shibboleth メタデータの URL は https:windchill.company.com/Shibboleth.sso/Metadata になります。
Shibboleth Service Provider のトラブルシューティングとデバッグ
Shibboleth デーモンのログファイルは <shibboleth のインストール場所>/var/log/shibboleth にあります。これらのログファイルを Linux で読み取るにはルートアクセスが必要です。HTTP サーバー上の別の場所に切り替える場合、Shibboleth モジュールログファイルは <<インストールディレクトリ>>/var/log/shibboleth-www にあります。Linux では、非ルートユーザーがこのディレクトリに書き込むことはできません。ポート 80 で Web サーバーを実行しようとしていない場合、PTC HTTP Server は通常、非ルートユーザーとして動作します。その場合、ログファイルは作成されません。/etc/shibboleth/native.log を修正することでログファイルの場所を変更できます。次の 2 つのプロパティを書き込み可能な場所に変更します。
log4j.appender.native_log.fileName=/var/log/shibboleth-www/native.log
log4j.appender.warn_log.fileName=/var/log/shibboleth-www/native_warn.log
たとえば、ディレクトリ /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 と PTC HTTP Server の再起動
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 を設定するときに、上記以外の注意事項も考慮する必要があります。詳細については、サポート記事 CS250036 を参照してください。
一部のクライアントは SAML 認証の設定がサポートされていません。ご自分のサイトで SAML 認証を実装する前に、サイトでこれらのクライアントがどの程度使用されているか、およびこれらのクライアントの排除が SAML 認証の使用に対する妨げになるかどうかを確認してください。PTC は次のクライアントの SAML 認証設定をサポートしていません。
• Windchill Gateway for Creo Elements/Direct Model Manager
クライアントの SAML 認証との互換性に関する最新情報については、サポートの記事 CS250038 を参照してください。
アイデンティティプロバイダとしての PingFederate の設定
以降のステップでは、PingFederate と Windchill サーバー上の Shibboleth SP インストール間の接続を設定する方法について説明します。これはオプションの設定であり、Windchill で SAML 認証を有効にするための必須の設定ではありません。会社の SSO フェデレーションの要件に応じて、SAML の展開で別の IdP を使用することもできます。サポートされているバージョンの PingFederate のダウンロードおよびライセンスの取得の詳細については、シングルサインオン認証を参照してください。
これらのステップは前述の SAML 設定のトピックに掲載されている手順を補うものであり、PingFederate と Shibboleth Service Provider がすでにインストールされていることを前提としています。IdP としての PingFederate と Shibboleth Service Provider の設定ステップは相互に関連しているので、もう一方のクライアントからエクスポートされたメタデータ XML ファイルをインポートするためには、各クライアントの設定を更新する必要があります。
1. PingFederate で、Service Provider との接続を作成します。
a. Service Provider との接続を作成する手順については、PingFederate の製品ドキュメントを参照してください。PingFederate の管理コンソールから、「IDP Configuration」 > 「SP Connections」に移動し、「Create New」をクリックします。
b. Windchill サーバーに Shibboleth Service Provider クライアントをインストールしたときにエクスポートした metadata.xml ファイルをインポートします。このファイルを読み込む手順については、SAML 認証設定のトピックのステップ 6 を参照してください。
2. 会社のディレクトリサーバー (LDAP または ADFS) にユーザー認証をリダイレクトするよう PingFederate が設定されていることを確認します。PingFederate とお使いのディレクトリサーバーの製品ドキュメントを参照し、ディレクトリサーバーの管理者とご相談の上、PingFederate を設定してください。
3. PingFederate で、作成した SP 接続用のメタデータ XML ファイルをエクスポートし、必要に応じて名前を idp-metadata.xml に変更します。
4. Windchill サーバーにインストールされている Shibboleth Service Provider で、以下の設定を行います。
a. PingFederate SP 接続からエクスポートした idp-metadata.xml ファイルを Shibboleth SP のインストールディレクトリに保存することでインポートします。以下のタグを shibboleth2.xml ファイルに追加し、これを修正して idp-metadata.xml ファイルの保存場所を反映します。
<MetadataProvider type="XML" validate="true" file="location to metadata xml file>"/>
b. PingFederate で作成した SP 接続の entityID と一致するように SSO entityID を設定します。これは PingFederate からエクスポートした idp-metadata.xml ファイルから取得します。
5. Apache Tomcat、Shibboleth SP、および Windchill サーバーを再起動します。Windchill にログインし、このログイン URL が PingFederate ログインページにリダイレクトされてログインが成功することを確認します。
* 
SSO 認証を設定した場合、ログインの試行回数は使用しているアイデンティティプロバイダによって決まります。お使いのディレクトリサーバーで適用されるログイン試行ポリシーについては、IdP 管理者にご確認ください。Windchill Directory Server または別の LDAP IdP で無効なログイン試行についてのユーザーアカウントロックアウト設定を以前に行っている場合、新しい IdP で設定されているポリシーがご自分のセキュリティ要件に適合しているか確認してください。