認証方法を計画する (Windows SharePoint Services)

  • [アーティクル]

この記事の内容 :

  • 認証について

  • サポートされている認証方法

  • 認証を構成する

  • コンテンツのクロールの認証を計画する

  • 認証設計の領域を計画する

  • 環境で許可する認証方法を選択する

  • ワークシート

この記事では、Windows SharePoint Services 3.0 でサポートされている認証方法について説明します。この記事を読むことで、以下のことをできるようになります。

  • Windows SharePoint Services 3.0 で認証がどのように実装されるかを理解する。

  • 環境に適した認証方法を特定する。

認証について

認証とは、ユーザーの ID を検証するプロセスのことです。ユーザーの ID が検証されると、ユーザーがアクセスできるサイト、コンテンツ、およびその他の機能について、承認プロセスが判断します。

Windows SharePoint Services 3.0 では、認証プロセスはインターネット インフォメーション サービス (IIS) によって管理されます。IIS によるユーザーの認証が実行された後に、Windows SharePoint Services 3.0 のセキュリティ機能によって承認プロセスが実行されます。

Windows SharePoint Services 3.0 における承認の実装の詳細については、「サイトおよびコンテンツのセキュリティを計画する (Windows SharePoint Services)」を参照してください。

認証の計画は、ユーザーの ID を検証してソリューションを保護するためだけでなく、ネットワークを介したユーザーの資格情報のセキュリティを確保するためにも重要です。

サポートされている認証方法

Windows SharePoint Services 3.0 では、柔軟で拡張性のある認証システムを提供しています。このシステムでは、Microsoft Windows オペレーティング システムに基づく ID 管理システムに加え、Windows に基づかない ID 管理システムの認証をサポートしています。ASP .NET のプラグ可能な認証との統合によって、Windows SharePoint Services 3.0 はフォームベースのさまざまな認証スキームをサポートします。Windows SharePoint Services 3.0 での認証サポートにより、次のようなさまざまな認証シナリオが可能になります。

  • 標準の Windows 認証方法を使用する。

  • ユーザー名とパスワードによる簡単なデータベースを使用する。

  • 組織の ID 管理システムに直接接続する。

  • パートナーのアプリケーションにアクセスするために複数の認証方法を使用する (たとえば、パートナー企業の ID 管理システムに接続してパートナー企業の従業員を認証する一方で、Windows の認証方法を使用して自社内の従業員を認証します)。

  • フェデレーション ID 管理システムに参加する。

次の表は、サポートされている認証方法を示しています。

認証方法 説明 例

Windows

IIS による標準の Windows 認証方法がサポートされています。

  • 匿名

  • 基本

  • ダイジェスト

  • 証明書

  • Kerberos (統合 Windows)

  • NTLM (統合 Windows)

ASP.NET フォーム

Windows SharePoint Services 3.0 では、ASP.NET フォーム認証システムと統合することにより、Windows に基づかない ID 管理システムもサポートしています。ASP.NET 認証は、MembershipProvider インターフェイスを実装する ID 管理システムと Windows SharePoint Services 3.0 の相互運用を可能にします。セキュリティ管理ページを書き直したり、Active Directory ディレクトリ サービスのシャドウ アカウントを管理したりする必要はありません。

  • LDAP (ライトウェイト ディレクトリ アクセス プロトコ)

  • SQL データベースまたはその他のデータベース

  • その他の ASP.NET ベースのフォーム認証ソリューション

Web シングル サインオン (SSO)

Windows SharePoint Services 3.0 は、Web SSO ベンダによるフェデレーション認証をサポートします。Web SSO を利用することによって、多様なプラットフォーム上で実行されているサービスが存在する環境での SSO が可能になります。Active Directory アカウントを個別に管理する必要はありません。

  • Active Directory フェデレーション サービス (AD FS)

  • その他の ID 管理システム

システム アカウントの認証

ASP.NET フォーム認証と Web SSO は、ユーザー アカウントの認証にのみ使用できます。Microsoft SQL Server データベース ソフトウェアに接続するため、および Web ファームを実行するために使用するプロセス アカウントは、Windows アカウントである必要があります。これは、ユーザー認証に代替の方法を使用している場合でも同様です。

Windows SharePoint Services 3.0 では、SQL Server 認証、および Active Directory を実行していないファームのローカル コンピュータ プロセス アカウントをサポートしています。たとえば、ファーム内のすべてのサーバーで同じユーザー名とパスワードを使用することによって、ローカル アカウントを実装することができます。

認証を構成する

Windows 認証の構成は簡単なプロセスですが、ASP.NET フォームまたは Web SSO を使用して認証を構成するには、より綿密な計画が必要です。ここでは、Windows SharePoint Services 3.0 で認証を構成する方法について、その概要を説明します。ここでの情報は、ソリューションの認証戦略を立てる方法を理解し、組織内で認証の計画に参加する必要のある担当者を決定するために役立ちます。

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

Windows SharePoint Services 3.0 の認証は、SharePoint Web アプリケーションのレベルで構成されます。次の図は、複数の企業のサイトをホストするように構成された Windows SharePoint Services サーバー ファームを表しています。認証は、企業ごとに個別に構成されています。

2 つの異なる企業のためのホスティング認証

Web アプリケーションの初期作成時または拡張時には、使用できる認証の選択肢は限られています (Kerberos、NTLM、および匿名)。これらの中のいずれかの方法を使用する場合、Web アプリケーションの作成時または拡張時に認証を構成することができます。

次の図は、Web アプリケーションの初期作成時または拡張時に利用できる限られた認証の選択肢を示しています。

既定の認証設定

その他の認証設定を使用する場合は、既定の認証オプションを選択し、Web アプリケーションを作成または拡張した後に認証を構成します (そのためには、サーバーの全体管理の [アプリケーション構成の管理] ページの [アプリケーション セキュリティ] セクションで [認証プロバイダ] を選択し、領域をクリックして [認証の編集] ページを開きます)。このページで構成する設定は、選択する認証の種類 (Windows、フォーム、または Web SSO) によって異なります。

次の図は、[認証の編集] ページを示しています。

[認証の編集] ページ

サーバーの全体管理で選択した認証によっては、追加の構成が必要になる場合があります。以下の表は、認証方法と、それに基づく構成手順について示しています。また、この表では、SharePoint 管理者の他に特別な役割が必要かどうかも示しています。

認証方法 追加構成 特別な役割

匿名

なし

なし

基本

なし

なし

ダイジェスト

直接 IIS でダイジェスト認証を構成します。

なし

証明書

  1. サーバーの全体管理で Windows 認証を選択します。

  2. IIS で証明書認証を構成します。

  3. SSL (Secure Sockets Layer) を有効にします。

  4. 証明機関 (CA) から証明書を取得して構成します。

Windows Server 2003 の管理者 (証明書を取得して構成するため)

NTLM (統合 Windows)

なし

なし

Kerberos (統合 Windows)

  1. Kerberos 認証を使用するように Web アプリケーションを構成します。

  2. アプリケーション プールの ID に使用されるドメイン ユーザー アカウント (アプリケーション プール プロセス アカウント) のサービス プリンシパル名 (SPN) を構成します。

  3. このドメイン ユーザー アカウントの SPN を Active Directory に登録します。

IIS 管理者

フォーム

  1. メンバシップ プロバイダを SharePoint Web アプリケーションの Web.config ファイルに登録します。

  2. ロール マネージャを SharePoint Web アプリケーションの Web.config ファイルに登録します (オプション)。

  3. メンバシップ プロバイダをサーバーの全体管理サイトの Web.config ファイルに登録します。

  • ASP.NET 開発者

  • 接続先の ID 管理システムの管理者

Web SSO

ASP.NET フォーム認証に必要な構成手順に加えて、Web SSO プロバイダの HTTP モジュールを登録します。

  • ASP.NET 開発者

  • 接続先の ID 管理システムの管理者

外部の ID 管理システムまたは Windows に基づかない ID 管理システムに接続する

ASP.NET フォームまたは Web SSO を使用して、Windows に基づかない ID 管理システムまたは外部の ID 管理システムに対してユーザーを認証するには、メンバシップ プロバイダを Web.config ファイルに登録する必要があります。メンバシップ プロバイダに加えて、ロール マネージャも登録できます。Windows SharePoint Services 3.0 は、標準の ASP.NET ロール マネージャ インターフェイスを使用して現在のユーザーに関するグループ情報を収集します。ASP.NET の各ロールは、Windows SharePoint Services 3.0 の承認プロセスによって、ドメイン グループと同様に処理されます。認証のメンバシップ プロバイダを登録するのと同じ方法でロール マネージャを Web.config ファイルに登録します。

サーバーの全体管理サイトからメンバシップ ユーザーまたはロールを管理する場合、オプションとして、サーバーの全体管理サイトの Web.config ファイルに、メンバシップ プロバイダとロール マネージャを登録することができます (これは、コンテンツをホストする Web アプリケーションの Web.config ファイルに登録することに加えて実行します)。

Web.config ファイルに登録したメンバシップ プロバイダ名とロール マネージャ名が、サーバーの全体管理の Authentication.aspx ページに入力した名前と同じであることを確認します。Web.config ファイルにロール マネージャを入力しない場合、machine.config ファイルに指定されている既定のプロバイダを代わりに使用することもできます。

たとえば、Web.config ファイル内の次の文字列によって、SQL メンバシップ プロバイダが指定されます。

<membership defaultProvider="AspNetSqlMembershipProvider">

ASP.NET フォーム認証を使用して SQL Server の認証プロバイダに接続する方法の詳細については、「認証サンプル (Windows SharePoint Services)」を参照してください。

最後に、Web SSO を使用して外部の ID 管理システムに接続する場合、Web SSO の HTTP モジュールも登録する必要があります。HTTP モジュールは、アプリケーションに対して要求が行われるたびに呼び出されるアセンブリです。HTTP モジュールは、ASP.NET 要求パイプラインの一部として呼び出されます。詳細については、「Introduction to HTTP Modules (英語)」(https://go.microsoft.com/fwlink/?LinkId=77954&clcid=0x411) を参照してください。

ASP.NET フォーム認証と統合するには、認証プロバイダに追加の要件が発生します。Web.config ファイルにさまざまな要素を登録するのに加え、次の表に示すように、メンバシップ プロバイダ、ロール マネージャ、および HTTP モジュールを Windows SharePoint Services 3.0 および ASP.NET メソッドとやり取りするようにプログラムする必要があります。

カテゴリ 説明

メンバシップ プロバイダ

Windows SharePoint Services 3.0 とやり取りするには、メンバシップ プロバイダに次のメソッドを実装する必要があります。

  • GetUser (文字列)   Windows SharePoint Services 3.0 は、招待時にユーザー名を解決するときやユーザーの表示名を取得するときに、このメソッドを呼び出します。

  • GetUserNameByEmail   Windows SharePoint Services 3.0 は、このメソッドを呼び出して招待するユーザー名を解決します。

  • FindUsersByName、FindUsersByEmail   Windows SharePoint Services 3.0 は、これらのメソッドを呼び出して、[ユーザーの追加] ページのユーザー選択コントロールにデータを設定します。メンバシップ プロバイダがユーザーを返さない場合、選択機能が動作しないので、管理者は [ユーザーの追加] ボックスに、ユーザー名または電子メール アドレスを入力する必要があります。

ロール マネージャ

ロール マネージャでは、次のメソッドを実装する必要があります。

  • RoleExists   Windows SharePoint Services 3.0 は、このメソッドを呼び出して、招待時にロール名が存在するかどうかを確認します。

  • GetRolesForUser   Windows SharePoint Services 3.0 は、アクセス チェック時にこのメソッドを呼び出して、現在のユーザーのロールを収集します。

  • GetAllRoles   Windows SharePoint Services 3.0 は、このメソッドを呼び出して、グループ選択およびロール選択のコントロールにデータを設定します。ロール プロバイダがグループまたはロールを返さない場合、Windows SharePoint Services 3.0 の選択機能が動作しないので、管理者は [ユーザーの追加] ボックスにロール名を入力する必要があります。

HTTP モジュール

HTTP モジュールでは、次のイベントを処理する必要があります。

  • AuthenticateRequest   このイベントは、ASP.NET がユーザーを認証する準備ができたときに呼び出されます。Web SSO モジュールは、ユーザーの認証 Cookie を開いて、HttpContext.User オブジェクトに現在のユーザーの ID を設定します。

  • EndRequest   これは、ASP.NET パイプラインの最終イベントです。このイベントは、コードをクライアントに返す直前に呼び出されます。Web SSO モジュールは、Windows SharePoint Services 3.0 からの 401 応答を取得し、Web SSO ログオン サーバーの認証ため、適切な 302 リダイレクトに変更する必要があります。

匿名アクセスを有効にする

より安全な認証方法の構成に加えて、Web アプリケーションの匿名アクセスを有効にすることができます。この構成を使用して、Web アプリケーション内にあるサイトの管理者は匿名アクセスを許可することができます。匿名ユーザーがセキュリティ保護されたリソースや機能へのアクセスを要求する場合、ログオン ボタンをクリックして資格情報を送信することができます。

異なる認証方法を使用してサイトにアクセスする

Windows SharePoint Services 3.0 の Web アプリケーションを構成する場合、最大 5 種類の異なる認証方法または ID 管理システムを使用してアクセス可能にすることができます。次の図は、2 つの異なる ID 管理システムのユーザーがアクセスできるように構成されたパートナー アプリケーションを表しています。社内の従業員は、標準の Windows 認証方法のいずれかを使用して認証されます。パートナー企業の従業員は、各社独自の ID 管理システムで認証されます。

認証オプションの管理の図

2 つ以上の異なる認証システムによってアクセスできるように Web アプリケーションを構成するには、Web アプリケーションに追加の領域を構成する必要があります。領域は、同一の物理アプリケーションへのアクセスを取得するための異なる論理パスを表します。典型的なパートナー アプリケーションでは、パートナー企業の従業員はインターネットを介してアプリケーションにアクセスしますが、内部の従業員はイントラネットを介して直接アプリケーションにアクセスします。

新規の領域を作成するには、Web アプリケーションを拡張します。[別の IIS Web サイトへの Web アプリケーションの拡張] ページの [負荷分散される URL] セクションで、URL および領域の種類を指定します。領域の種類は、その領域に適用される単なるカテゴリ名です。領域の構成には影響しません。

Web アプリケーションを拡張すると、新規領域の認証方法を個別に構成できるようになります。次の図は、2 つの異なる領域を使用して構成された Web アプリケーションの [認証プロバイダ] ページを表しています。既定の領域は、内部の従業員が使用する領域です。インターネット領域はパートナーのアクセス用に構成され、パートナー ID 管理システムに対してパートナー従業員を認証するために ASP.NET フォームが使用されます。

2 つのゾーンを使用して構成された Web アプリケーション

コンテンツのクロールの認証を計画する

Web アプリケーションのコンテンツのクロールを正常に実行するには、検索サーバーのインデックス コンポーネント ("クローラ" とも呼ばれます) の認証要件を理解する必要があります。ここでは、Web アプリケーションのコンテンツを正常にクロールできるように Web アプリケーションの認証を構成する方法について説明します。

ファーム管理者がすべての既定の設定を使用して Web アプリケーションを作成すると、その Web アプリケーションの既定の領域は NTLM を使用するように構成されます。ファーム管理者は既定の領域の認証方法を、Windows SharePoint Services 3.0 でサポートされている任意の認証方法に変更することができます。

ファーム管理者は、Web アプリケーションを何度か拡張して、追加の領域を有効にすることもできます。特定の Web アプリケーションには、最大 5 つの領域を割り当てることができます。各領域を構成して、Windows SharePoint Services 3.0 でサポートされている任意の認証方法を使用することができます。

クローラが領域にアクセスする順序

Web アプリケーションの領域を計画する場合は、認証を試みるときに、クローラが領域にアクセスする際のポーリング順序を考慮する必要があります。ポーリング順序は重要です。クローラが、基本認証、ダイジェスト認証、または Kerberos 認証を使用するように構成された領域に遭遇すると、認証は失敗し、クローラはポーリング順序の中の次の領域にアクセスしようとしないからです。この状態が発生すると、クローラはその Web アプリケーションのコンテンツをクロールしません。

ヒント

ポーリング順序の中では、NTLM が構成された領域を、基本認証、ダイジェスト認証、または Kerberos 認証が構成された領域よりも前に置いてください。

クローラは次の順序で領域をポーリングします。

  • 既定の領域

  • イントラネット領域

  • インターネット領域

  • カスタム領域

  • エクストラネット領域

次の図は、クローラが認証を試みるときに認証システムが行う判断を表しています。

クローラがゾーンをポーリングする順番を表示する

次の表は、図中の各番号の部分に関連する動作を説明しています。

番号 動作

1

クローラは既定の領域を使用して認証を試みます。

注意

クローラは、特定の Web アプリケーションの認証を試みるときに、常に既定の領域を最初に使用します。

2

領域に NTLM が構成されている場合、クローラは認証され、承認段階へ進みます。

3

領域に基本認証、ダイジェスト認証、または Kerberos 認証が構成されている場合、認証は失敗し、クローラは他の領域を使用して認証を試みることはありません。この場合、コンテンツはクロールされません。

4

ポーリング順序の中にもう領域がない場合、認証は失敗し、コンテンツはクロールされません。

5

クローラは、ポーリング順序の中の次の領域を使用して認証を試みます。

フォーム認証、Web SSO など、クローラがサポートしていない認証方法を使用するように既定の領域を構成する場合、少なくとも 1 つの領域を追加作成し、この領域が NTLM 認証を使用するように構成する必要があります。次のシナリオを考慮してください。

認証のシナリオ

ファーム管理者は、Web アプリケーションを作成し、フォーム認証を使用するように構成します。ファーム管理者は、この Web アプリケーションのコンテンツがクロールされインデックスが作成されるようにしたいと考えており、また、クローラが NTLM が構成された領域を要求することを理解しているので、この Web アプリケーションを拡張して、NTLM を使用するイントラネット領域を構成します。

クローラが既定の領域を使用して認証を試みる際に、認証システムは、クローラとこの領域が同じ認証方法を使用するように構成されていないと判断します。この領域には基本認証、ダイジェスト認証、または Kerberos 認証が構成されており、ポーリング順序の中には少なくとも 1 つの追加の領域があることから、クローラはイントラネット領域を使用して認証を試みます。イントラネット領域は NTLM を使用するように構成されており、クローラも NTLM を使用するので、認証は成功します。

認証方法を適切に構成するだけでなく、Web アプリケーション内のコンテンツをクロールする権限がクローラに与えられている必要があります。このためには、コンテンツ アクセス アカウントで使用される資格情報には、クロール対象の Web アプリケーションに対してすべて読み取りアクセス許可レベル、またはそれ以上のアクセス許可レベルが与えられている必要があります。ファーム管理者は、サーバーの全体管理の [Web アプリケーションのポリシー] ページを使用して、コンテンツ アクセス アカウントに、特定の Web アプリケーションに対するすべて読み取りアクセス許可レベルを与えるポリシーを作成することができます。

ホスト名付きサイト コレクションのクロール

上の図で示されているプロセスとルールは、ホスト名付きのサイト コレクションには適用されません。これは、ホスト名付きサイト コレクションを利用できるのは、既定の領域を使用する場合のみだからです。ホスト名付きサイト コレクションを展開するときに、NTLM を使用するように既定の領域を構成しない場合、インデックス コンポーネントがコンテンツにアクセスする代替方法を構成する必要があります。

NTLM 認証が構成されていないホスト名付きサイト コレクションのクロールの詳細については、次の記事を参照してください。

認証設計の領域を計画する

領域を使用して Web アプリケーションに複数の認証方法を実装する計画を立てる場合、次のガイドラインに従います。

  • 既定の領域には、最もセキュリティの高い認証設定を実装します。要求を特定の領域に関連付けられない場合、既定の領域の認証設定およびその他のセキュリティ ポリシーが適用されます。既定の領域は、Web アプリケーションの初期作成時に作成される領域です。通常、最もセキュリティの高い認証設定はエンド ユーザーのアクセス用に設計されます。その結果、多くの場合、既定の領域はエンド ユーザーがアクセスする領域になります。

  • 使用する領域の数は、アプリケーションで必要とされる最小限の数にします。各領域は、Web アプリケーションにアクセスするために、新規 IIS サイトおよびドメインに関連付けられます。新規アクセス ポイントは、それが必要な場合のみに追加します。

  • 検索結果に Web アプリケーション内のコンテンツを含めることを考慮している場合は、少なくとも 1 つの領域で NTLM 認証を使用するように構成します。インデックス コンポーネントがコンテンツをクロールするためには、NTLM 認証が必要になります。必要ない場合は、インデックス コンポーネントの専用領域を作成しないでください。

環境で許可する認証方法を選択する

認証の構成方法を理解するだけでなく、認証の計画では次のような点も踏まえる必要があります。

  • Windows SharePoint Services 3.0 の Web アプリケーションでのセキュリティ コンテキストや環境について考慮する。

  • それぞれの方法について、推奨理由とトレードオフを評価する。

  • Windows SharePoint Services 3.0 で、ユーザーの資格情報および関連する ID データがどのようにキャッシュされ、使用されるかについて理解する。

  • ユーザー アカウントがどのように管理されるかについて理解する。

  • 認証方法がユーザーの使用しているブラウザと互換性があるか確認する。

ワークシートでの作業

認証方法ワークシート (https://go.microsoft.com/fwlink/?linkid=77970&clcid=0x411) を使用して、どの認証方法を環境でサポートするかを決定し、各認証方法についての決定結果と推奨事項を記録します。このワークシートは、Windows SharePoint Services 3.0 の個々の Web アプリケーションの認証方法を計画する際に使用します。 .

特定のセキュリティ環境に関する推奨事項

認証方法を選択する場合、最も考慮する必要のある点となるのがアプリケーションのセキュリティ コンテキストです。次の表は、一般的なセキュリティ環境に基づく推奨事項を示しています。

環境 考慮事項

内部イントラネット

少なくとも、ユーザーの資格情報がそのまま表示されないように保護します。環境で実装されているユーザー管理システムと統合します。Active Directory が実装されている場合、IIS に組み込まれている Windows 認証方法を使用します。

外部のセキュリティ保護されたグループ作業

サイトに接続する各パートナー企業に対して個別に領域を構成します。Web SSO を使用して、各パートナー独自の ID 管理システムに対して認証します。これにより、自社の ID 管理システムにアカウントを作成する必要がなくなり、パートナー企業の従業員の ID は、引き続きパートナー企業によって維持、検証されます。従業員がパートナー企業を退社した場合、この従業員はパートナー アプリケーションにアクセスできなくなります。

外部の匿名

匿名アクセス (認証なし) を有効にして、インターネットから接続するユーザーに読み取り専用アクセス許レベルを与えます。対象が設定されたコンテンツまたはロールベースのコンテンツを提供する場合、ASP.NET フォーム認証、およびユーザー名とロールによる簡単なデータベースを使用して、ユーザーを登録することができます。この登録プロセスを使用し、ロール (たとえば医師、患者、薬剤師など) によってユーザーを識別します。ユーザーがログオンするときに、そのユーザー ロールに固有のコンテンツをサイトに表示することができます。このシナリオでは、認証を資格情報の検証やコンテンツへのアクセス可能なユーザーの制限に使用するのではなく、認証プロセスは単にコンテンツの対象を設定する手段を提供するだけです。

認証方法の推奨理由とトレードオフ

各認証方法の利点、推奨事項、およびトレードオフを理解しておくと、環境で使用する認証方法を決めるのに役立ちます。次の表は、各認証方法の推奨事項とトレードオフを説明しています。IIS でサポートされている各 Windows 認証方法の詳細については、「IIS の認証」(https://go.microsoft.com/fwlink/?linkid=78066&clcid=0x411) を参照してください。

認証方法 利点および推奨理由 トレードオフ

Windows

  • 既存の Active Directory アカウントを使用して認証できます。

  • ユーザーの管理が簡素化されます。

  • Windows SharePoint Services 3.0 の承認を構成する際に、Active Directory グループが利用できます。

  • カスタム コードを記述しなくても済みます。

  • それぞれの方法には、固有の利点と欠点があります。

  • IIS 認証プロトコルの中には、特定の Web ブラウザでサポートされていないものがあります。

ASP.NET フォーム

  • Active Directory を使用しない環境に Windows SharePoint Services 3.0 をセットアップできます (Windows アカウントを必要としません)。

  • パートナー アプリケーションを作成する場合、複数の異なる ID 管理システムに対して認証できます。

  • 任意の基準を使用したカスタム認証スキームを実装できます。

  • インターネットからのユーザーを認証できます。

  • Web.config ファイルをカスタマイズする必要があります。

  • SSL や TLS (Transport Layer Security) を使用しないと、Cookie の有効期間中にリプレイ攻撃にさらされる可能性があります。

Web SSO

  • フェデレーション認証を使用する環境で Windows SharePoint Services 3.0 を実装し、組織およびセキュリティ環境全体でデジタル ID を保護します。

  • 多様なプラットフォームで実行されているサービスに対して SSO を提供する環境で Windows SharePoint Services 3.0 を実装できます。これには、Active Directory を使用しない環境も含まれます。

  • AD FS を利用することができます。

  • パートナー アプリケーションを作成する場合、複数の異なる ID 管理システムに対して認証できます。

  • 既存のフェデレーション認証システムが必要です。

  • Web.config ファイルをカスタマイズする必要があります。

  • AD FS には SSL が必要になります。その他の SSO システムにも、別の要件がある場合があります。

ユーザーの ID 情報の管理

Windows SharePoint Services 3.0 によってユーザーの資格情報やその他の ID 情報がどのように処理され、使用されるかは、意図した目的にどの認証オプションが最も合致するかを判断する際の材料となります。ここでは、ユーザーの ID 情報がどのように処理されるかついて、以下のカテゴリに沿って詳しく説明します。

  • バイナリ ID   Windows SharePoint Services 3.0 によって、ユーザーのバイナリ識別子 (ID) が作成され、使用される方法です。

  • キャッシュ   要求ごとに認証プロセスを繰り返さなくて済むように、一定期間ユーザーの ID を維持するプロセスです。

  • ロールとグループ メンバシップ   認証プロセスでは、ユーザーの確認に加えて、ユーザーがどのグループやロールに属しているかを判断します。この情報は、ユーザーが持つ権限によってどの処理が実行できるかを判断するために、承認プロセスで使用されます。Windows SharePoint Services 3.0 は、承認を行うために Active Directory のグループと ASP.NET のロールを同じ種類のエンティティとして扱います。

次の表は、Windows SharePoint Services 3.0 が、使用されている認証方法に基づいてユーザーのバイナリ ID、キャッシュされたユーザー データ、ロールとグループ メンバシップのデータをどのように管理するかについて詳しく説明しています。

項目 Windows 認証 ASP.NET フォームおよび Web SSO

バイナリ ID

Windows SharePoint Services 3.0 は、Windows セキュリティ識別子 (SID) を使用します。

Windows SharePoint Services 3.0 は、プロバイダ名とユーザー名を結合して一意のバイナリ ID を作成します。

キャッシュ

ユーザーの資格情報は、IIS、Internet Explorer、および Windows によってキャッシュされ、管理されます。

ASP.NET は、暗号化された Cookie を使用して、セッションの期間中ユーザーの資格情報を保持します。

ロールとグループ メンバシップ

Windows は、ユーザーが属する Active Directory ドメイン グループの一覧を、アクセス トークン内に保持します。Windows SharePoint Services 3.0 は、アクセス トークンに保存されている情報を使用します。

ロール マネージャが登録されると、Windows SharePoint Services は標準のロール マネージャ インターフェイスを使用して現在のユーザーに関するグループ情報を収集します。ASP.NET の各ロールは、承認プロセスによってドメイン グループと同様に扱われます。ASP.NET は、Web.config ファイルに構成されている設定に従って、ユーザーが属するロールを Cookie にキャッシュします。

ユーザー アカウントの管理

Windows SharePoint Services 3.0 が典型的なユーザー アカウントの管理タスクをどのように処理するのかを理解することは、認証方法の選択にも影響します。一般に、ある領域の認証プロバイダのメンバであるユーザーが権限を与えられている場合は、すべての領域でアカウントを管理することができます。次の一覧にある情報は、実装されている認証方法にかかわらず適用されます。

  • 新規ユーザーの追加と招待   メンバシップ プロバイダとロール マネージャが現在の Web.config ファイルに登録されている場合、任意の領域および構成されているすべての認証方法において、新規ユーザーを追加または招待することができます。新規ユーザーを追加するとき、Windows SharePoint Services 3.0 は以下のソースをこの順で使用して、ユーザー名を解決します。

    • Windows SharePoint Services 3.0 によって保存されている UserInfoList テーブル。ユーザーが既に他のサイトに追加されている場合、ユーザー情報はこの一覧の中に存在します。

    • 現在の領域に構成されている認証プロバイダ。たとえば、ユーザーが既定の領域に構成されている認証プロバイダのメンバである場合、Windows SharePoint Services 3.0 は初めに、この関連付けられているメンバシップ プロバイダを確認します。

    • 他のすべての認証プロバイダ。

  • ユーザーの削除   ユーザー アカウントは、Windows SharePoint Services 3.0 データベースで削除済みとマークされます。ただし、ユーザーのレコードは削除されません。

Windows SharePoint Services 3.0 内のユーザー アカウントの管理動作の中には、認証プロバイダによって異なるものがあります。次の表は、実装されている認証方法によって動作が異なる、いくつかの一般的なユーザー アカウント タスクに焦点を当てています。

タスク Windows 認証のアカウント ASP.NET フォーム認証のアカウントおよび Web SSO 認証のアカウント

新規ユーザーの追加と招待

Windows SharePoint Services 3.0 は、Active Directory を使用してユーザーの ID を検証します。

Windows SharePoint Services 3.0 は、メンバシップ プロバイダおよびロール マネージャを呼び出して、ユーザーとロールが存在するかどうかを確認します。

ログオン名の変更

更新されたユーザー名は、Windows SharePoint Services 3.0 によって自動的に認識されます。UserInfoList テーブルに新規エントリは追加されません。

古いアカウント名を削除して、新しいアカウント名を追加する必要があります。権限は移行できません。

ログオン

統合 Windows 認証 (Kerberos または NTLM) が使用され、自動的にログオンするようにブラウザが構成されている場合、ユーザーは手動で SharePoint サイトにログオンする必要はありません。既定では、Internet Explorer は自動的にイントラネット サイトにログオンするように構成されています。ログオンが必要な場合 (別の一連の資格情報を要求するサイトなど)、ユーザーはユーザー名とパスワードのみを要求されます。ただし、基本認証が使用される場合、または自動的にログオンする構成になっていないブラウザをユーザーが使用している場合、ユーザーは SharePoint サイトにアクセスするときにログオン資格情報を求められます。

Windows SharePoint Services 3.0 は、フォーム認証で使用するための標準のログオン ページを提供しています。このページには、ユーザー名、パスワード、自動サインイン (Cookie を保存) のフィールドが含まれます。独自のログオン ページを作成し、新規アカウントの作成、パスワードのリセットなど、ログオン用の他のコントロールを追加することができます。

ブラウザのサポート

サポートされているそれぞれの認証方法は、すべてのブラウザで動作するとは限りません。環境で使用可能にする認証方法を選択する前に、サポートする必要のあるブラウザを決定します。その後で、それらのブラウザでサポートされる認証方法を特定します。Internet Explorer は、サポートされているすべての認証方法で動作します。Windows SharePoint Services 3.0 でサポートされている他のブラウザには次のものがあります。

  • Netscape 8.0

  • Netscape 7.2

  • Mozilla 1.7.12

  • Firefox 1.5

  • Safari 2.02

ワークシート

次のワークシートを使用して、自分の環境に適しているのはどの認証方法であるかを記録します。

次の表は、記入済みのワークシートの例を示しています。

認証方法 許可する 許可しない メモおよび推奨事項

匿名

x

基本

x

ダイジェスト

x

証明書

x

NTLM (統合 Windows)

x

*"財務部門以外のすべての部門サイトに NTLM を使用する。"*

Kerberos (統合 Windows)

x

*"サービス レベル アグリーメントで高度なセキュリティが要求されるサイトには Kerberos 認証を使用する。"*

ASP.NET フォーム

x

*"パートナー企業がパートナーのエクストラネットでホストされているサイトにアクセスできるように、フォーム認証を使用する。現在、Active Directory および LDAP の ID 管理システムによる認証が許可されている。Sidney Higa と共同で、フォーム認証で使用する認証設定を開発する。"*

Web SSO

x

*"パートナー企業がフェデレーション ID 管理システムに参加している場合に限り、パートナー アプリケーションでこの方法を使用する。詳細については、David Jones と相談。"*

追加メモ : "Denise Smith と共同で、実装前に SharePoint Web アプリケーションのすべての認証設定のサインオフを行う。"

このドキュメントをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なドキュメントに収められています。

入手可能なドキュメントの詳細な一覧については、「Windows SharePoint Services 3.0 テクニカル ライブラリ」を参照してください。