ビジネス データ カタログの認証を管理する

Microsoft Office SharePoint Server 2007 のビジネス データ カタログは、2 種類の認証モデルと、シングル サインオン (SSO) を使用してユーザー資格情報を格納する 3 種類の認証モードをサポートしています。

この記事の内容 :

  • 適切な認証モデルと認証モードを選択する

  • バックエンド アプリケーションのアカウントを構成する

  • シングル サインオン サービスを有効にして構成する

  • 企業アプリケーション定義を作成して構成する

  • アプリケーションのアプリケーション定義を変更してインポートする

  • タスク要件

SSO を使用してビジネス データ カタログの認証を管理するには、展開に組み込むデータベースまたは Web サービスごとにこのドキュメントの手順を実行します。

適切な認証モデルと認証モードを選択する

ビジネス データ カタログ内のアプリケーションでは、さまざまな認証モードを使用できます。これらの認証モードでは、2 種類の認証モデルのどちらかを使用できます。

認証モデルを選択する

ビジネス データ カタログで使用される認証モデルは概念的なものであり、特定の XML やその他の構成設定に対応しているわけではありません。認証モデルを実装するには、特定のアカウントを使用してバックエンド サーバーに接続できるようにアプリケーション定義 XML ファイルを構成します。

ビジネス データ カタログは、次の認証モデルをサポートしています。

  • 信頼されたサブシステム

  • 偽装と委任

信頼されたサブシステムのモデルでは、中間層 (通常は Web サーバー) は固定 ID としてのバックエンド サーバーに対して認証を行います。偽装と委任のモデルでは、クライアントは認証を中間層に委任します。中間層はクライアントに偽装し、クライアントの代わりにバックエンド システムに対して認証を行います。各モデルでは、さまざまな統合シナリオで使用できる複数の認証モードがサポートされています。

信頼されたサブシステムのモデルには、次の利点があります。

  • データベース接続のプール

  • より単純な管理

  • アプリケーションのバックエンド サーバーの管理者は、1 つのアカウントの権限を管理するだけで済む

信頼されたサブシステムのモデルは、新しい展開の場合に選択することをお勧めします。アプリケーション管理者は、バックエンド サーバーに対する多数のユーザーの承認権限を構成する必要はありません。その代わりに、アプリケーションごとに 1 つのアカウントを構成し、Office SharePoint Server で承認を構成できます。

信頼されたサブシステムのモデルでは、企業アプリケーション定義でグループ アカウントに関連付けられているサービス アカウントまたはデータベース アカウントを使用します。

偽装と委任のモデルには、次の利点があります。

  • バックエンド サーバーでの監査

  • バックエンド サーバーでのユーザーごとの承認 (追加構成の必要はない)

偽装と委任のモデルは、ユーザーごとの承認が構成されている既存のアプリケーションに対して使用することをお勧めします。偽装と委任のモデルを構成した後も、バックエンド アプリケーションの構成を使用して各ユーザーを引き続き認証できます。組織が Office SharePoint Server の展開に統合されている複数の基幹業務アプリケーションを管理しており、それらの各アプリケーションに継続的に管理しなければならない独自の承認設定がある場合、このモデルは手間がかかることがあります。バックエンド サーバーでの監査が必要でない限り、偽装と委任のモデルは、初期展開中、信頼されたサブシステムのモデルを構成できるようになるまでの間に限って使用することをお勧めします。

委任と偽装のモデルでは、個別の Windows ユーザー アカウントと、個別のアカウントに関連付けられている、データベース ユーザー アカウント (データベース専用) とフォームベース認証ユーザー アカウント (Web サービス専用) のどちらかを使用します。

認証モードを選択して構成する

次の表に、ビジネス データ カタログでサポートされている認証モードと、そのモードで SSO を使用するかどうかを示します。

認証モード

説明

SSO の使用

PassThrough

ログオンしているユーザーの資格情報を使用して、バックエンド サーバー上のアプリケーションに対して認証を行います。このモードは、偽装と委任の認証モデルでのみ使用できます。PassThrough 認証では、Kerberos 委任を有効にする必要があります。

使用しない

RevertToSelf

アプリケーション プール ID アカウントを使用して、バックエンド サーバーに対してユーザーの認証を行います。個別のアカウントの代わりにサービス アカウントが常に使用されるため、RevertToSelf では信頼されたサブシステムの認証モデルを使用します。

使用しない

WindowsCredentials

Web サービスとデータベースの両方に使用されます。ビジネス データ カタログは、企業アプリケーション定義の資格情報を使用して Windows ユーザー アカウントを偽装し、Windows 認証を行います。

使用する

Credentials

Windows 認証の代わりに基本認証またはダイジェスト認証を使用する Web サービスに使用されます。Credentials 認証モードを使用する場合は、セキュリティを確保するために、ビジネス データ カタログとバックエンド サーバー間のチャネルを SSL (Secure Sockets Layer) またはインターネット プロトコル セキュリティ (IPSec) を使用してセキュリティ保護することを強くお勧めします。

使用する

RdbCredentials

バックエンド データベースにのみ使用されます。ビジネス データ カタログは、認証に企業アプリケーション定義の資格情報を使用します。

使用する

これらのモードのほとんどでは、企業アプリケーション定義として構成された個別の ID またはグループ ID を使用し、SSO を使用してアプリケーションの資格情報を格納します。ユーザーを認証するために、PassThrough モードではログオンしているユーザーの資格情報を使用し、RevertToSelf モードではアプリケーション プール ID アカウントを使用します。

すべての SSO 認証モードで、企業アプリケーション定義は、信頼されたサブシステムのモデルにはグループ アカウントを使用し、偽装と委任のモデルには個別のアカウントを使用します。企業アプリケーション定義の詳細については、このドキュメントのセクション「企業アプリケーション定義を作成して構成する」を参照してください。

選択する認証モードは、バックエンド サーバーで構成するアカウントと資格情報や、SSO の設定に影響します。構成する必要のあるアプリケーション定義 XML ファイルのプロパティについては、このドキュメントの後のセクション「アプリケーション定義 XML ファイルを変更してインポートする」を参照してください。

認証モデルと認証モードの詳細については、「ビジネス データ カタログの認証」(https://go.microsoft.com/fwlink/?LinkID=100498&clcid=0x411) を参照してください。

アプリケーションのアカウントを構成する

SSO またはアプリケーションのアプリケーション定義 XML ファイルを構成する前に、バックエンド サーバーに対する 1 つ以上の資格情報の承認権限を構成します。

  • 信頼されたサブシステムの認証モデルを使用する場合は、アプリケーションで単一のアカウントまたは資格情報のセットを構成するだけでかまいません。

  • 偽装と委任の認証モデルを使用する場合は、ビジネス データ カタログが偽装する、SSO グループ アカウントのすべての資格情報について承認を構成する必要があります。組織でアプリケーションが既に使用されている場合は、必要な資格情報は構成済みの可能性があります。その場合、この手順は省略できます。

アカウントはデータベースまたは Web サービス内で構成されます。構成の詳細は、アプリケーションの権限によって異なります。

シングル サインオン サービスを有効にして構成する

SSO を使用するビジネス データ カタログの認証モードを選択した場合は、ファーム内のすべてのフロントエンド Web サーバーで Microsoft シングル サインオン サービス (SSOSrv) を有効にして構成する必要があります。ビジネス データ カタログの検索も使用する場合は、インデックス サーバーで SSOrv を有効にする必要があります。

サービスのログオン アカウントは、以下の条件を満たしている必要があります。

  • ドメイン ユーザー アカウントであること。グループ アカウントは使用できません。

  • Office SharePoint Server ファームのアカウントであること。

  • 暗号化キー サーバーのローカル Administrators グループのメンバであること。暗号化キー サーバーは、SSOSrv を開始する最初のサーバーです。

  • Microsoft SQL Server を実行するコンピュータの Security Administrators ロールおよび db_creator ロールのメンバであること。

  • SSO 管理者アカウントと同じであるか、SSO 管理者アカウントであるグループ アカウントのメンバであること。

SSO サービスの構成後、サーバーの全体管理のページで追加の設定を構成します。SSO のサーバー設定には、個別の SSO 管理者アカウントのアカウント情報、SSO データベース サーバーおよびサーバー名、タイムアウトと監査ログの設定などが含まれます。

SSO 管理者アカウントとして指定するユーザーまたはグループは、以下の条件を満たしている必要があります。

  • Windows グローバル グループまたは個別のユーザー アカウントであること。ドメイン ローカル グループ アカウントまたは配布リストは使用できません。

  • シングル サインオン サービス アカウントと同じアカウントであること (ユーザーが指定されている場合)。グループが指定されている場合は、シングル サインオン サービス アカウントはそのグループのメンバでなければなりません。

  • SSO 用の構成アカウントと同じアカウントであること (ユーザーが指定されている場合)。グループが指定されている場合は、SSO 用の構成アカウントはそのグループのメンバでなければなりません。

  • SharePoint の Farm Administrators グループのメンバであること。

シングル サインオン サービスの有効化とアクティブ化の詳細については、「Configure and start the Microsoft Single Sign-On service」を参照してください。シングル サインオン サービスの構成の詳細については、「シングル サインオンを構成する (Office SharePoint Server)」を参照してください。

企業アプリケーション定義を作成して構成する

シングル サインオン サービスの構成後、基幹業務アプリケーションの企業アプリケーション定義を作成して構成する必要があります。基幹業務アプリケーション、データベース、および Web サービスで使用される、格納される資格情報ごとに 1 つの企業アプリケーション定義を作成します。通常はアプリケーションまたはサービスごとに 1 つの企業アプリケーション定義を作成しますが、同じ資格情報のセットを使用するアプリケーションが複数ある場合には、それらの資格情報を使用するすべてのアプリケーションへの接続に使用できる企業アプリケーション定義 を 1 つだけ作成してください。

注意

SSO の企業アプリケーション定義は、各アプリケーションまたはサービスのビジネス データ カタログにインポートされるアプリケーション定義 XML ファイルとは異なります。企業アプリケーション定義を作成し、アプリケーション定義 XML ファイルに含まれるその企業アプリケーション定義を別に参照する必要があります。

企業アプリケーション定義を作成した後で、企業アプリケーション定義のアカウント情報を構成する必要があります。この手順を完了するには、ローカル管理者としてサーバーにログオンしている必要があります。

企業アプリケーション定義の作成の詳細については、「ビジネス データ カタログの企業アプリケーション定義を作成する」を参照してください。企業アプリケーション定義の構成の詳細については、「ビジネス データ カタログの企業アプリケーション定義を構成する」を参照してください。

アプリケーション定義 XML ファイルを変更してインポートする

SSO を構成し、企業アプリケーション定義を作成および構成したら、アプリケーション定義を変更して、アプリケーションの認証モード、アプリケーションで使用される ISsoProvider インターフェイスの実装、アプリケーションの企業アプリケーション ID を追加する必要があります。これらのプロパティは、アプリケーション定義 XML ファイルの LOBSystemInstance オブジェクトで構成します。

アプリケーションのその他のプロパティも変更できます。データベースと Web サービスの両方の認証の構成に使用できるプロパティの詳細な一覧については、「LobSystemInstance」(https://go.microsoft.com/fwlink/?LinkId=124545&clcid=0x411) を参照してください。サンプルも用意されています。

ビジネス データ カタログに認証設定を使用するには、アプリケーション定義 XML ファイルをビジネス データ カタログにインポートする必要があります。

ビジネス データ カタログ用のアプリケーション定義の作成、変更、およびインポートの詳細については、「アプリケーション定義を管理する」を参照してください。

アプリケーション定義 XML ファイルの一般的な作成タスクは、次のサブセクションで説明します。

  • データベースの SSO 認証を構成する

  • Web サービスの SSO 認証を構成する

  • アプリケーションの SSP プロバイダを構成する

  • RevertToSelf 認証を構成する

  • PassThrough 認証を構成する

  • アプリケーションのアプリケーションレベルの認証を構成する

データベースの SSO 認証を構成する

データベース システムで SSO を使用するには、次のプロパティが必要です。

  • WindowsCredentials または RdbCredentials に設定されている LOBSystemInstance オブジェクトの AuthenticationMode

  • ISsoProvider インターフェイスの完全修飾名に設定されている SsoProviderImplementation

    注意

    Office SharePoint Server ISsoProvider インターフェイスの代わりにサードパーティの ISsoProvider インターフェイスが使用されている場合は、そのプロバイダの完全修飾名を含める必要があります。

  • SsoApplicationId は、アプリケーションの企業アプリケーション ID の値に設定されます。企業アプリケーション定義の名前は、作成時に指定済みです。

Web サービスの SSO 認証を構成する

Web サービス システムで SSO を使用するには、次のプロパティが必要です。

  • WindowsCredentials または Credentials に設定されている LOBSystemInstance オブジェクトの WebServiceAuthenticationMode

  • ISsoProvider インターフェイスの完全修飾名に設定されている SsoProviderImplementation

    注意

    Office SharePoint Server ISsoProvider インターフェイスの代わりにサードパーティの ISsoProvider インターフェイスが使用されている場合は、そのプロバイダの完全修飾名を含める必要があります。

  • WebServiceSsoApplicationId は、アプリケーションの企業アプリケーション ID の値に設定されます。

アプリケーションの SSP プロバイダを構成する

ユーザーの認証に SSO を使用する基幹業務アプリケーションでは、SsoProviderImplementation プロパティと ISsoProvider インターフェイスを設定して、サード パーティの任意の SSO プロバイダを使用できます。Office SharePoint Server SSO プロバイダ以外の SSO プロバイダを使用するには、そのプロバイダを構成し、このプロパティのアプリケーション定義にプロバイダの完全修飾名を含める必要があります。詳細については、「ISsoProvider メンバ」(https://go.microsoft.com/fwlink/?LinkId=124546&clcid=0x411) を参照してください。

アプリケーションの RevertToSelf 認証を構成する

SSO を使用する代わりに、RevertToSelf 認証モードを使用して、アプリケーションをアプリケーション プール アカウント ID で実行し、各ユーザーのアプリケーションに対する個別の権限を使用して認証を行うように構成できます。RevertToSelf 認証モードを使用するには、認証プロパティを次のように設定します。

  • データベースに対して認証するには、LOBSystemInstance オブジェクトの AuthenticationMode プロパティを RevertToSelf に設定します。

  • Web サービスに対して認証するには、LOBSystemInstance オブジェクトの WebServiceAuthenticationMode プロパティを RevertToSelf に設定します。

アプリケーションの PassThrough 認証を構成する

PassThrough 認証でも、アカウントの格納に SSO を使用しません。代わりにバックエンド アプリケーションの各アカウントの権限を直接使用して、各ユーザーを認証します。PassThrough 認証モードを使用するには、認証プロパティを次のように設定します。

  • データベースに対して認証するには、LOBSystemInstance オブジェクトの AuthenticationMode プロパティを PassThrough に設定します。

  • Web サービスに対して認証するには、LOBSystemInstance オブジェクトの WebServiceAuthenticationMode プロパティを PassThrough に設定します。

アプリケーションのアプリケーションレベルの認証を構成する

ビジネス データ カタログは、二次的なアプリケーションレベルの認証もサポートしています。この認証は、システムに対して構成されている一次的な認証と併せて使用されます。この認証は、バックエンド アプリケーションでユーザーを承認するためにセキュリティ資格情報をメソッド呼び出しで渡す必要がある場合などに特に役立ちます。アプリケーションレベルの認証を有効にするには、次の手順を実行します。

  • LobSystemInstance オブジェクトの SecondarySsoApplicationId プロパティで、資格情報を含む SSO アプリケーションを指定します。

  • UsernameCredentialFilter プロパティと PasswordCredentialFilter プロパティを定義し、それぞれを入力パラメータと関連付けます。

匿名アクセスを構成する

2007 Microsoft Office Servers Service Pack 1 には、ビジネス データ Web パーツ内のビジネス データへの匿名アクセスを有効にするアプリケーション定義用の新しい AllowAnonymousExecute プロパティが追加されています。このプロパティの値を true に設定すると、匿名アクセスが有効になります。このプロパティの XML は次のとおりです。

     <Properties>

          <Property Name="AllowAnonymousExecute" Type="System.Boolean">true</Property>

     </Properties>

ビジネス データ リスト Web パーツまたはビジネス データ アイテム Web パーツ内のデータへの匿名アクセスを有効にするには、Web パーツで使用されるメソッド インスタンスにこのプロパティを追加します。

たとえば、音楽アーティストの情報を表示するビジネス データ アイテム Web パーツ用の ArtistRead メソッド インスタンスを匿名ユーザーが実行できるようにするには、次のように指定します。

<MethodInstance Type="SpecificFinder" ReturnParameterName="ArtistRead" Name="ArtistRead">

     <Properties>

          <Property Name="AllowAnonymousExecute" Type="System.Boolean">true</Property>

     </Properties>

</MethodInstance>

タスク要件

このタスクの手順を実行するのに必要な権限を示します。

  • ビジネス データ カタログ内のバックエンド基幹業務アプリケーションのアカウントを構成するには、アカウント権限を構成するためのアプリケーション権限が必要です。

  • サーバーでシングル サインオン サービスを有効にするには、ローカル Administrators グループのメンバである必要があります。

  • サーバーの全体管理で SSO 管理者アカウントを構成するには、ファーム管理者であると同時に、ローカル Administrators グループのメンバである必要があります。

  • サーバーの全体管理で企業アプリケーション定義を作成および構成するには、ファーム管理者であると同時に、ローカル Administrators グループのメンバである必要があります。

  • アプリケーションの既存のアプリケーション定義 XML ファイルを変更またはインポートするには、ビジネス データ カタログ内のアプリケーションの編集権限が必要です。

ビジネス データ カタログの認証を管理するには、次の手順を記載の順序どおりに実行します。