データ接続、認証、および代替アクセス マッピングについて
最終更新日: 2010年4月13日
適用対象: SharePoint Server 2010
この記事の内容
ユニバーサル データ接続
データ接続の認証
SharePoint 代替アクセス マッピングおよびデータ接続
ブラウザー対応の InfoPath フォーム テンプレートでデータ接続を使用する場合は、潜在的な管理性および認証の問題を考慮する必要があります。これらの問題は、ユニバーサル データ接続 (UDC) ファイルを使用してフォーム テンプレートからデータ接続情報を抽象化すること、Secure Store Service (Office SharePoint Server 2007 のシングル サインオンに代わる機能) を使用して多層アーキテクチャでの認証の問題を処理すること、および InfoPath Forms Services で利用可能な Web サービス プロキシを使用することによって解決できます。
ユニバーサル データ接続
SharePoint Foundation には、データ接続ライブラリ (DCL) のサポートが含まれています。データ接続ライブラリには、Office データ接続ファイルとユニバーサル データ接続 (UDC) の 2 種類のデータ接続を格納できます。Microsoft InfoPath 2010 では、ユニバーサル データ接続 (UDC) ファイル スキーマに準拠し、通常、*.udcx または *.xml のファイル拡張子を持つデータ接続が使用されます。これらの UDC ファイルによって、サーバーに保存され、標準フォーム テンプレートやブラウザー対応のフォーム テンプレートで使用されるさまざまなデータ ソースを記述できます。
データ接続ライブラリにある UDC ファイルを使用することには、次のような利点があります。
フォーム作成者は、InfoPath クライアントと InfoPath Forms Services の両方で機能するフォーム テンプレートのデータ接続を構成できます。
フォーム作成者は、フォーム テンプレートを複数のサーバーに発行し、フォーム テンプレートでデータ接続情報を変更することなく、サーバーごとに異なるデータ接続の設定を使用できます。
フォーム作成者は、別のドメインのデータ ソースにアクセスできるドメイン セキュリティ フォーム テンプレートを発行できます。
管理者は、UDC ファイルを参照するフォーム テンプレートを変更することなく、データ接続をリダイレクトできます。
管理者は、クロス ドメイン アクセスとして承認する接続を指定できます。
管理者は、単一のサーバーでデータ接続を発行し、複数のサーバーで共有できます。
データ接続ライブラリを作成する方法の詳細については、「[方法] データ接続ライブラリを作成および使用する」を参照してください。フォーム テンプレートは、常に、データ接続ライブラリ内の UDC ファイルに対してデザインされますが、集中管理されたバージョンの UDC ファイルを使用するように接続を構成できます。このような集中管理される UDC ファイルは、サーバー管理者によってアップロードされます。UDC ファイルを集中管理するには、SharePoint サーバーの全体管理の [アプリケーション構成の管理] ページを参照し、[InfoPath Forms Services] セクションの [データ接続ファイルの管理] リンクをクリックします。
UDC ファイルが管理者によってアップロードされる場合は、[中央管理される接続ライブラリ] オプションを使用するようにデータ接続を構成します。このオプションは、データ接続ウィザードでデータ接続を選択し、[接続のオプション] をクリックすると表示されます。
.gif "重要") 重要 |
|---|
両方の UDC ファイルは同じ名前である必要があります。集中管理されるデータ接続へのリンクが確立された後、ローカル サイト上のデータ接続は削除できますが、削除されたデータ接続を使用するフォーム テンプレートをデータ接続ウィザードを使用してデザインすることはできなくなります。 |
サポートされるデータ ソース
UDC ファイルは、以前の Office データ接続ファイルとは異なり、幅広いデータ ソースをサポートしているので、複数のデータ ソースを記述できます。ただし、InfoPath フォーム テンプレートで構成できるほとんどのデータ ソースはサポートされていますが、電子メール送信など、一部のデータ接続は UDC ファイルでは記述できません。
次のようなデータ ソースを使用できます。
Microsoft SQL Server データベース クエリ
Web サービス クエリまたは送信
XML ファイル クエリ (リモート サーバー上にある XML ファイル)
SharePoint ライブラリ送信
SharePoint リスト クエリ
Web サーバー送信 (HTTP ポスト)
注意
HTTP ポスト用の UDC ファイルを作成するためのデータ接続ウィザードには、[データ] タブの [データ接続] をクリックして表示される [データ接続] ダイアログ ボックスではなく、[データ] タブの [送信オプション] をクリックして [送信オプション] ダイアログ ボックスからアクセスします。
データ接続の認証
InfoPath で開いたフォームは、フォーム テンプレート用に構成されたデータ ソースと直接通信できます。一方、ブラウザーで開いたフォームは、単一サーバーまたは Web フロント エンドである、InfoPath Forms Services を実行するサーバーと直接通信できます。これにより、一般的にダブル ホップ問題と呼ばれる問題が発生します。ダブル ホップ問題 (より正確には、マルチ ホップ委任の問題) とは、第 3 のコンピューター (第 3 層) にあるリソースにアクセスするために必要な資格情報が、第 2 層からそれらのリソースに対する要求では使用できないという認証の問題です。
注意
認証が必要な各層は、ネットワーク上の Windows コンピューターであり、NTLM 認証が構成されていると仮定します。
たとえば、ブラウザー内のフォーム (第 1 層) が InfoPath Forms Services を実行するサーバー (第 2 層) と通信し、このサーバーがデータベース サーバーまたはネットワーク共有 (第 3 層) にあるリソースにアクセスする必要があるとします。ブラウザーと InfoPath Forms Services サーバーとの間で Microsoft Windows によって使用される NTLM 認証システムに固有の委任の制限により、ブラウザーと InfoPath Forms Services を実行するサーバーとの間で使用されたプライマリ セキュリティ トークンを、データベース サーバーに渡すことができません。
この問題はブラウザーでフォームを開いたときにより頻繁に発生します。これは、InfoPath でフォームを開いたときには、ブラウザーが InfoPath Forms Services を実行するサーバーに対して行うのと同様に、プライマリ認証トークンを渡してデータ ソースと直接認証できるからです。
多層アーキテクチャで委任の問題を解決する方法として推奨されるのは、Microsoft SharePoint Server 2010 の Secure Store Service ですが、Secure Store Service を利用できない場合には他のオプションもあります。
Secure Store Service 以外の多層委任のソリューション
基本/ダイジェスト認証 : この種類の認証は、通常、標準 HTML フォームで使用され、エクストラネットのシナリオで使用される InfoPath フォームで便利な場合があります。ユーザーに対して、第 3 層の Web サーバー上のリソースへのアクセスに必要な資格情報を入力するためのダイアログ ボックスが表示され、入力された資格情報は別の Windows コンピューターへの複数のホップで使用できます。基本認証が構成されている場合、サーバーはこれらの資格情報をクリア テキストで送信します。一方、ダイジェスト認証が構成されている場合は、資格情報はネットワーク上で MD5 ハッシュまたはメッセージ ダイジェストとして送信されます。
埋め込まれた資格情報 : ユニバーサル データ接続 (UDC) ファイルに資格情報を埋め込むことはできますが、リソースにアクセスするためのユーザー名とパスワードのセキュリティが保護されている場合にのみ使用してください。
匿名/サービス アカウントの使用 : SharePoint サイトが匿名アクセスを受け付けるように構成されている場合、サーバーは匿名アカウントを使用して第 3 層のリソースにアクセスします。
Kerberos : Kerberos は、多層アーキテクチャでの委任をサポートするように設計された認証プロトコルです。Kerberos を使用すると、ユーザーはユーザー名とパスワードを使用してキー配布センター (KDC) サーバーで認証され、ユーザーに対して Kerberos チケットが発行されます。チケットは暗号化され、サーバーでのみ解読できる検証ツールが添付されます。アプリケーションの各層では、ユーザーの資格情報を要求することなく、KDC によって個別にチケットを検証できます。
制約付き委任 : Windows Server 2003 には、制約付き委任 (CD) とプロトコル遷移と呼ばれる Kerberos サービスに対する 2 つの拡張機能があります。これらのサービスによって、Windows は、クライアントが Kerberos を使用できないか、またはポート 88 (Kerberos ポート) がブロックされているエクストラネットのシナリオで、ユーザーの代わりに Kerberos チケットを取得できます。多くのインターネット サーバーや企業のファイアウォールでは、既定でポート 88 がブロックされています。CD を使用するには、すべてのクライアントで Windows XP 以降を実行し、すべてのサーバーで Windows Server 2003 以降を実行している必要があります。また、Active Directory で CD が有効になっており、構成されている必要があります。
フォーム ベース認証 : SharePoint 管理者は、ユーザーがサーバーで認証するために使用するメカニズムとして、フォーム ベース認証を指定できます。フォーム ベース認証では、次の処理が行われます。
ユーザーが Web フロントエンド (WFE) に対して HTTP 要求を行います。
WFE が Web フォームを指す HTTP 302 (リダイレクト) 応答を返します。
ユーザーが資格情報を Web フォームに入力します。
資格情報がサード パーティのプラグイン認証プロバイダーによって検証され、WFE で認識されている資格情報 (SharePoint ID など) にマップされます。
この処理の最後に、ユーザーは有効な SharePoint ID を取得します。ただし、InfoPath Forms Services には接続に使用する有効な Windows 資格情報がないので、フォームでは SSO またはその他の方法を使用して、データ ソースに接続するための資格情報を取得する必要があります。
推奨される認証方法 : Secure Store Service および Web サービス プロキシ
Secure Store Service: Secure Store Service では、これまでに説明した方法とは異なる方法で、第 2 層以降のサーバー上のリソースに接続するための代替資格情報を提供します。Secure Store Service は、アプリケーションとユーザー資格情報を他の資格情報にマップするデータベースと、Secure Store Service の機能を抽象化し、この API のプロバイダーを含むすべての Secure Store プロバイダーを使用できるようにする API で構成されます。InfoPath フォームで作業をしているサーバー管理者は、次の Secure Store プロバイダーを使用できます。
Office サーバー Secure Store プロバイダー
サードパーティの Secure Store プロバイダー
Secure Store Service の設定の詳細については、以下のトピックを参照してください。[方法] 外部システムに接続するために Secure Store Service を使用する、[方法] 外部システムに接続するために Secure Store Service からの資格情報を使用する、Business Connectivity Services のセキュリティの概要 (SharePoint Foundation 2010)、Business Connectivity Services のセキュリティの概要 (SharePoint Server 2010)。
プロキシを使用する多層 Web サービス認証 : 多層アーキテクチャにまたがる Web サービス要求を有効にするために、ブラウザーのフォームから Web サービス SOAP メッセージを転送する InfoPath Forms Services プロキシが用意されています。
このプロキシを有効にするオプションは、SharePoint サーバーの全体管理サイトの [アプリケーション構成の管理] ページにあります。[InfoPath Forms Services] セクションの [Web サービス プロキシの管理] リンクをクリックして、管理者が展開したフォームやユーザーが展開したフォームのプロキシを有効にします。
注意
プロキシによって SOAP メッセージを転送できるようにするには、UDC ファイル内の UseFormsServiceProxy 属性を true に設定する必要があります。
SharePoint 代替アクセス マッピングおよびデータ接続
SharePoint の代替アクセス マッピングが提供するメカニズムによって、サーバー ファーム管理者はユーザーがポータル サイトにアクセスするためのさまざまな方法を識別し、ユーザーが SharePoint サイトにアクセスする方法に応じて適切な URL が表示されるようにすることができます。たとえば、ユーザーが企業のイントラネットから福利厚生サイトにアクセスする場合は http://benefits という URL を使用し、従業員が自宅からエクストラネット経由で同じサイトにアクセスするときには https://benefits.mycompany.com という URL を使用するように設定できます。
代替アクセス マッピングは、通常、InfoPath Forms Services によるデータ接続の処理方法には影響しません。ただし、ユーザーがイントラネットとエクストラネットの両方からフォームにアクセスする場合は、データ接続の認証モデルを構成し、両方の場所からテストして、適切に動作することを確認する必要があります。サーバーへの接続で完全修飾 URL とローカル サーバー名のどちらを使用するかは、接続性を確保するための代替アクセス マッピングによって異なります。
SharePoint サーバーの全体管理で代替アクセス マッピングの設定を表示するには、[サーバー構成の管理] ページを参照し、[グローバル構成] セクションの [代替アクセス マッピング] リンクをクリックします。代替アクセス マッピングの詳細については、TechNet の Microsoft Office SharePoint Server 2010 で「代替アクセス マッピング」を検索してください。