このセクションでは、Windchill でサポートできるさまざまな認証方法について説明します。

Windchill のユーザー認証方法は、Java Platform, Enterprise Edition (Java EE) に基づいています。Java EE 認証方法では、認証の役割が Web アプリケーションから、アプリケーションの展開先である Java EE Web アプリケーションコンテナに渡されます。この方法の目的は、実行時に使用される認証のメカニズムとポリシーを、アプリケーション展開環境のプロパティにすることです。アプリケーションコードで認証を記述することはありません。

Java EE Web アプリケーションコンテナは、次の認証をサポートするために必要です。

SiteMinder などの商用 Web サーバーセキュリティ製品には、これらの認証機能に加え、トークン (SecureID)、バイオメトリクス、複数サイトにわたるシングルサインオンなどの追加オプションが用意されている場合があります。通常、HTTP 基本認証と SSL/TLS クライアント認証以外のメカニズムは、フォームベース認証と同様に動作します。これらのメカニズムは、HTTP Cookie ヘッダを使用して結果を生成することによって、クライアントセッショントラッキングに依存します。

Windchill は、Web サーバーの認証に基づいて、認証されたユーザー名が発行されるように設計されています。したがって、Web サーバーまたはサーブレットエンジンでのアクセス制御によって、認証済みの Windchill URL のアクセス権限が決まります。これらの制御は、Web ブラウザで取得されたユーザー名とパスワードに基づいてアクセス権を決定します。HTTP 認証実装により、以下の Windchill 設定要件が発生します。

標準の Java EE 認証方法に従っても問題が発生する可能性があることを理解するには、次のセクションで説明する、認証メカニズムの背景情報を把握する必要があります。

HTTP プロトコルには、認証メカニズムがあります。サーバーは、保護されたリソースに対する未承認リクエストを受け取ると、401 レスポンスステータスコードとともに WWW 認証ヘッダを返します。この認証ヘッダは、保護されたリソースにアクセスするために必要な認証スキームを示します。次回のリクエストでは、適切な承認ヘッダでリクエストを再実行する必要があります。HTTP プロキシを使用すると、プロキシ認証ヘッダーとプロキシ承認ヘッダーを使用する認証レイヤーを同様に追加することもできます。

標準の HTTP 認証スキームの 1 つに、HTTP 基本認証があります。HTTP 基本認証では、Web サイトの一部である保護ドメイン内の情報にアクセスするために、ユーザーからのすべてのリソース要求に、有効なユーザー名とパスワードを含める必要があります。要求ごとに再認証を行わないようにするには、要求ごとに入力できるよう、HTTP クライアント (Web ブラウザ) がユーザー名とパスワードを保存します。

ただし、HTTP サーバーは、ユーザー名とパスワードをクリアするようブラウザに強制できません。ユーザー名とパスワードは、クライアント側で保護ドメインごとにキャッシュされているからです。そのため、HTTP サーバーは、再認証を強制できません。シングルサインオンツールなどの代替認証メカニズムを使用することによって、この制限に対処できます。

内蔵されている認証サポートでは、HTTP プロトコルはステートレスです。つまり、リクエスト単位で動作し、クライアントセッションという概念を持ちません。HTTP プロトコルの内蔵認証サポートを無視して、サーバーによるステートフルセッショントラッキングに依存すると、認証済みセッションに対するサーバーの制御を強化できます。その最も一般的なアプローチがフォームベース認証です。このメカニズムでは、ログオンフォームを含んだ中間 HTML ページがユーザーとの対話に挿入されます。フォームベース認証では、ユーザーが HTML ページのハイパーリンクをブラウズし、ログオンページが表示されると入力できることを前提としています。通常、フォームベースのログオンを使用するサーバーは、後続のリクエストを同じ認証済みセッションの一部として認識するために使用される HTTP Cookie を設定することによって、ユーザーセッションを追跡します。これにより、サーバーのタイムアウトまたはセッションログアウトが可能になり、ログオンフォームを随時表示することによって再認証を強制できます。

フォームベース認証は、HTTP を使用する際のアプリケーションレベルの規則であり、HTTP プロトコルそのものに含まれるわけではありません。フォームベース認証は、HTTP プロトコル認証メカニズムをバイパスします。代わりに、Cookie ヘッダやリダイレクト (ステータスコード 3xx のレスポンス) などの HTTP プロトコルのほかの機能を使用して、プロトコルと対話することなく認証を実行します。このため、フォームベース認証をプロトコルレベルで透過的に処理することはできず、Windchill へのアクセスに使用されるクライアントは、フォームベース認証をサポートするように特別に設計されている必要があります。たとえば、フォームベース認証を使用する際に、Windchill プログラム (ビジュアリゼーションサービスや Windchill Desktop Integration など) の変更が必要になることがあります。また、Windchill ゲートウェイの機能を変更しなければならない場合があります。

フォームベース認証ソリューションの使用については、Windchill における代替認証の設定を参照してください。

このトピックでは、SSL/TLS (Secure Sockets Layer/Transport Layer Security) クライアント認証と HTTPS クライアント認証を同じ意味で使用しています。HTTPS は、TCP 接続上で暗号接続をネゴシエートして確立するためのプロトコルである SSL/TLS を使用して、セキュリティ保護された通信チャネル上で実行されるもので、本質的には HTTP です。HTTP 基本認証はプロトコルレベルで行われ、フォームベース認証はアプリケーションレベル (プロトコルレベルより上位) で行われます。一方、HTTPS クライアント認証は、プロトコルレベルの下位にあるトランスポートレベルで行われます。

HTTPS では、以下の 2 とおりの方法で SSL/TLS を使用できます。

HTTPS クライアント認証は、HTTP プロトコル認証 (フォームベース認証など) のメカニズムの外部で行われますが、HTTP プロトコルより下位で行われます。したがって、HTTP のアプリケーションコードの使用に対しては、透過的な状態を保つことができます (フォームベース認証と異なります)。これを行うには、SSL 接続の確立時にユーザーの証明書と非公開キーを使用できる必要があります。Java アプリケーションでは、必要なキーストアプロパティをプロトコルハンドラに渡すように、Java システムプロパティを設定する必要が生じる場合があります。

ホストベース証明書のほかに、TrustedAuthFilter は双方向 SSL 証明書に基づくクライアントの信頼をサポートするようになりました。この場合、クライアント証明書は特定のユーザーにマップする必要はなく、単に追加の証明書として使用されます (パーティへの招待状やクラブのメンバーシップと同様)。このクライアント証明書が、ユーザーの識別情報を提供します。TrustedAuthFilter の使用の詳細については、該当する Javadoc を参照してください。

NTLM は、Microsoft Windows NT のチャレンジ/レスポンス認証システムです。Web リソースに対する認証には、ローカルユーザーのドメイン認証資格証明が使用されます。Windows のドメインコントローラは、クライアントにランダムチャレンジを送信します。クライアントは、このランダムチャレンジとユーザーの資格証明を使用して、レスポンスを作成します。作成されたレスポンスは、ドメインコントローラに送信され、ドメインコントローラは、レスポンスの復号化とユーザー資格証明の検証を行います。

NTLM 認証には、クライアントプロトコルハンドラが満たす必要がある特殊な要件があります。NTLM チャレンジを理解し、正しいレスポンスを生成できるクライアントプロトコルハンドラがなければ、この認証スキームは成り立ちません。

Security Assertion Markup Language (SAML) 認証は、XML をベースとするオープン標準準拠の認証フレームワークであり、OASIS Security Services Technical Committee によって維持管理されています。SAML によって、フェデレーションに参加しているサービスプロバイダへのシングルサインオンを実現するフレームワークが提供されます。PTC は、Windchill を SAML ベースのシングルサインオンフェデレーションに参加可能なサービスプロバイダとして確立するための、Shibboleth サービスプロバイダでのコンフィギュレーションに関して、テストと文書化をすでに完了しています。この認証方法では、SAML 標準についての専門知識が要求されます。フェデレーションの設定要件については、組織のアイデンティティプロバイダ管理者または地域の SAML 専門家に問い合せてください。