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 2.6.0 を使用してテストした統合を示しています。これは特定の条件下でテストされたものであり、コンフィギュレーション例として提供されています。サイトごとに SAML の実装方法は異なります。SAML サービスプロバイダの選択はユーザーが行います。PTC がテストしたのは Shibboleth Service Provider の適合性のみであるため、ほかの SAML サービスプロバイダの適合性については一切保証いたしません。PTC は直接的には SAML サービス プロバイダの設定またはコンフィギュレーションをサポートしていません。選択した SAML サービスプロバイダの設定については、その製品のドキュメンテーションを参照するか、カスタマーサポートにお問い合わせください。この手順では、フェデレーション内でアイデンティティプロバイダを確立または設定する方法については説明していません。アイデンティティプロバイダの確立については、OASIS または Shibboleth のドキュメンテーションを参照するか、アイデンティティプロバイダの管理者にお問い合わせください。
ほとんどのシングルサインオンソリューションでは SAML Web ブラウザ SSO プロファイルが使用されます。このシナリオでは、少なくとも 3 つの役割があります。
役割
|
説明
|
ユーザーエージェント
|
実際のユーザーの代わりにサービスプロバイダからリクエストを行うブラウザクライアント。
|
サービスプロバイダ
|
フェデレーション内のその他のエンティティにサービスを提供するエンティティ。ユーザーエージェントはプリンシパルの代わりにサービスプロバイダにリクエストを行います。
|
アイデンティティプロバイダ
|
アイデンティティプロバイダ (IdP) は、プリンシパルのアイデンティティ情報を作成、維持、管理し、フェデレーション内の各サービスに対してプリンシパルを認証します。
|
OASIS SAML v2.0 のドキュメンテーションには、これらの役割やその他の事柄についてさらに詳しい説明があります。次の図は、これらの役割間の認証プロセスを表しています。
アイデンティティプロバイダを、その他のアイデンティティプロバイダへのサービスプロバイダとして設定できます。この手順における「アイデンティティプロバイダ」とは、サービスプロバイダが直接通信する必要があるアイデンティティプロバイダのみを指し、フェデレーションされたその他のアイデンティティプロバイダのことは指していません。
Shibboleth Service Provider 2.6.0 を使用して Windchillで SAML 機能を有効化するには、次のステップを実行する必要があります。
1. Shibboleth Service Provider のインストール
Shibboleth は Shibboleth Consortium からダウンロードできます。次のリソースを使用して、PTC HTTP Server と同じシステムに Shibboleth をダウンロードしてインストールします。
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"。
▪ 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"でなければなりません。
▪ アイデンティティプロバイダの entityID と一致するように SSO の entityID を設定します。これは <SSO> タグの entityID 属性によって設定します。デフォルト値は https://idp.example.org/idp/shibboleth です。entityID はアイデンティティプロバイダによって提供される値に置き換える必要があります。この値については、アイデンティティプロバイダの管理者にお問い合わせください。値が "MyIDP" の場合、この設定は <SSO entityID="MyIDP"> になります。
▪ アイデンティティプロバイダのメタデータの設定
Shibboleth Service Provider は、XML フォーマットによるアイデンティティプロバイダのメタデータにアクセス可能でなければなりません。メタデータを XML ファイルとしてエクスポートする必要があるアイデンティティプロバイダや、URL を使用してメタデータにアクセス可能なアイデンティティプロバイダがあります。メタデータを Shibboleth Service Provider に提供する適切な方法については、アイデンティティプロバイダの管理者に問い合わせるか、ベンダーのドキュメンテーションを参照してください。
▪ メタデータが XML ファイルとして提供される場合、shibboleth2.xml ファイルのメインドキュメント内にタグ <MetadataProvider type="XML" validate="true" file="<メタデータ 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 仕様の一部です。属性命名管理の詳細については、Shibboleth の次のドキュメントを参照してください。
NativeSPAttributeExtractor | |
NativeSPAddAttribute | |
一般的なシナリオとして、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 2 デーモンサービスを再起動します。
4. PTC HTTP Server を設定します。
Shibboleth Service Provider モジュールで PTC HTTP Server を設定する必要があります。
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 ヘルプセンターと Windchill Business Reporting (Cognos)、および 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>
Windchill Business Reporting (Cognos) 用に、次のコンテンツを含む新しいファイル <http サーバーディレクトリ>/conf/conf.d/30-app-[CognosWebAppName]-1Auth.conf を作成します。
<LocationMatch ^/+Cognos/+(;.*)?>
AuthType shibboleth
ShibRequestSetting requireSession 1
require shib-session
</LocationMatch>
PTC HTTP Server にインストールされているその他の Web アプリケーションについても、同様のステップに従います。
5. Java Web Start アプレットを設定します。
Java Web Start アプレットが Windchill サーバーから jar ファイルをダウンロードする必要があります。このメカニズムでは SAML SSO はサポートされませんが、設定による 2 つの回避策があります。
a. Windchill からの *.jar ファイルの匿名ダウンロードを有効にします。
b. プロトコル認証の使用を有効にします。
プロパティ wt.auth.legacySupport.enabled=true を設定することで、Java Web Start アプリケーションランチャが HTTP Basic 認証ダウンロードを使用して jar ファイルをダウンロードできるようにします。これにより、ユーザーは追加の認証を求められます。Java Web Start アプリケーションは、ブラウザから独立したスタンドアロンアプリケーションとして動作し、シングルサインオンおよびサーブレットエンジンセッションの Cookie にアクセス可能でなければなりません。これを可能にするには、次のプロパティを使用します。
▪ wt.servlet.sessionCookie=JSESSIONID
これはこの Cookie のデフォルト値であり、サーブレットセッションの Cookie 名が異なる場合にのみ変更する必要があります。
▪ wt.servlet.sessionCookiePattern=<セッションの Cookie と一致する正規表現>
このプロパティはデフォルトでは設定されていません。
Shibboleth Service Provider のセッションの Cookie と一致する正規表現の値は _shibsession_.* です。Shibboleth Service Provider のデフォルトの Cookie 名は _shibsession_<entityID に基づいた Shibboleth Service Provider の一意の ID> です。Cookie 名の <一意の ID> 部分は予測が困難なので、正規表現の値 _shibsession_.* が使用されます。したがって、前述のプロパティは wt.servlet.sessionCookiePattern=_shibsession_.* に設定する必要があります。別のサービスプロバイダを使用している場合、Cookie 名はこれとは異なります。
6. 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 の設定で指定されているアイデンティティプロバイダによってユーザーを認証します。
Servigistics Arbortext Editorがユーザーの PTC ソリューションの一部である場合は、ユーザーのサイトで SAML を設定するときに、上記以外の注意事項も考慮する必要があります。詳細については、
https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS250036 を参照してください。
一部のクライアントは SAML 認証の設定がサポートされていません。ご自分のサイトで SAML 認証を実装する前に、サイトでこれらのクライアントがどの程度使用されているか、およびこれらのクライアントの排除が SAML 認証の使用に対する妨げになるかどうかを確認してください。PTC は次のクライアントの SAML 認証設定をサポートしていません。
• Windchill Archive
• Windchill Gateway for Cadence Allegro Design Workbench
• Windchill Gateway for Creo Elements/Direct Model Manager
• Windchill Gateway for FORAN
アイデンティティプロバイダとしての PingFederate の設定
以降のステップでは、PingFederate と
Windchill サーバー上の Shibboleth SP インストール間の接続を設定する方法について説明します。これはオプションの設定であり、Windchill で SAML 認証を有効にするための必須の設定ではありません。会社の SSO フェデレーションの要件に応じて、SAML の展開で別の IdP を使用することもできます。サポートされているバージョンの PingFederate のダウンロードおよびライセンスの取得の詳細については、
シングルサインオン認証を参照してください。
これらのステップは前述の SAML 設定のトピックに掲載されている手順を補うものであり、PingFederate と Shibboleth Service Provider がすでにインストールされていることを前提としています。IdP としての PingFederate と Shibboleth Service Provider の設定ステップは相互に関連しているので、もう一方のクライアントからエクスポートされたメタデータ XML ファイルをインポートするためには、各クライアントの設定を更新する必要があります。
1. Windchill サーバーにインストールされている Shibboleth Service Provider クライアントと PingFederate との間の信頼を確立するために使用される証明書を生成します。PingFederate で SP 接続を作成する際にこの証明書が必要になります。
Windchill サーバーで HTTPServer\bin から以下のコマンド (Windows マシンで作業している場合) を実行して、p12 証明書を生成します。
set OPENSSL=<ApacheHome>\ssl\openssl.cnf
openssl pkcs12 -export -in <Location>\server.crt -inkey <Location>\server.key -out PingFederate_<WindchillHost>.p12
Enter Password: password
2. PingFederate で、Service Provider との接続を作成します。
a. Service Provider との接続を作成する手順については、PingFederate の製品ドキュメントを参照してください。PingFederate の管理コンソールから、 > に移動し、「Create New」をクリックします。
b. この SP 接続を設定する際には、ステップ 1 で生成した PK12 証明書を使用してください。
c. Windchill サーバーに Shibboleth Service Provider クライアントをインストールしたときにエクスポートした metadata.xml ファイルをインポートします。このファイルを読み込む手順については、
SAML 認証設定のトピックのステップ 6 を参照してください。
3. 会社のディレクトリサーバー (LDAP または ADFS) にユーザー認証をリダイレクトするよう PingFederate が設定されていることを確認します。PingFederate とお使いのディレクトリサーバーの製品ドキュメントを参照し、ディレクトリサーバーの管理者とご相談の上、PingFederate を設定してください。
4. PingFederate で、作成した SP 接続用のメタデータ XML ファイルをエクスポートし、必要に応じて名前を idp-metadata.xml に変更します。
5. 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 ファイルから取得します。
6. Apache Tomcat、Shibboleth SP、および Windchill サーバーを再起動します。Windchill にログインし、このログイン URL が PingFederate ログインページにリダイレクトされてログインが成功することを確認します。
| SSO 認証を設定した場合、ログインの試行回数は使用しているアイデンティティプロバイダによって決まります。お使いのディレクトリサーバーで適用されるログイン試行ポリシーについては、IdP 管理者にご確認ください。Windchill ディレクトリサーバーまたは別の LDAP IdP で無効なログイン試行についてのユーザーアカウントロックアウト設定を以前に行っている場合、新しい IdP で設定されているポリシーがご自分のセキュリティ要件に適合しているか確認してください。 |