承認と認証

Windows SharePoint Services 3.0 では、Web サイト、リスト、リスト フォルダやライブラリ フォルダ、およびアイテムのレベルでユーザー アクセスのセキュリティがサポートされます。セキュリティ管理はすべてのレベルでロールに基づいており、Windows SharePoint Services プラットフォーム全体に対して一貫したセキュリティ管理を提供します。オブジェクトに対する権限の割り当てには、一貫性のあるロールベースのユーザー インターフェイスとオブジェクト モデルが使用されます。結果として、リストレベル、フォルダレベル、またはアイテムレベルのセキュリティに、Web サイトレベルのセキュリティと同じユーザー モデルが実装され、Web サイト全体でのユーザーとグループの権限管理が容易になります。また、Windows SharePoint Services では、リスト ライブラリとドキュメント ライブラリに含まれるフォルダとアイテムに対する一意な権限もサポートされます。

承認とは、あるオブジェクトに対してどのユーザーが特定のアクションを実行できるかを決定することによって Windows SharePoint Services が Web サイト、リスト、フォルダ、またはアイテムにセキュリティを提供するプロセスです。承認プロセスでは、ユーザーが認証済みであることを前提としています。認証とは、Windows SharePoint Services が現在のユーザーを識別するプロセスです。Windows SharePoint Services では、認証や ID 管理に独自のシステムを実装しておらず、代わりに外部システム (Microsoft Windows の認証または Windows 以外の認証) に依存しています。

Windows SharePoint Services では、以下の種類の認証をサポートしています。

• Windows : 基本、ダイジェスト、証明書、NTLM (Windows NT LAN Manager)、および Kerberos を含めたすべての Microsoft Internet Information Services (IIS) と Windows 認証の統合オプションです。Windows 認証では、IIS を使用して Windows SharePoint Services の認証を実行できます。

  重要

  「Windows SharePoint Services 3.0 インフラストラクチャ更新プログラム (KB951695)」をインストールする場合、偽装が一時中断されている間に SharePoint オブジェクト モデルを呼び出すと、カスタム ソリューションが失敗することがあります。Windows 認証を使用していて、コード内で IIS ワーカー プロセスから SharePoint オブジェクト モデルを呼び出す場合、その要求は呼び出し元ユーザーの ID を偽装する必要があります。Windows SharePoint Services は呼び出し元ユーザーを自動的に偽装するように ASP.NET を構成しますが、(たとえば、Windows API の RevertToSelf 関数を呼び出すか、またはユーザー トークン パラメータの値として IntPtr.Zero を指定して System.Security.Principal.WindowsIdentity.Impersonate メソッドを呼び出すことにより) 偽装を一時中断した場合は、予想外の動作が起こったり、コードが失敗したりする可能性があります。コード内で明示的に RevertToSelf 関数を呼び出さなくても、たとえば仮想パス プロバイダを実装している場合などには、偽装が解除された後で ASP.NET によって RevertToSelf 関数が呼び出されることがあります。このようなケースでは、コードで呼び出し元ユーザーを偽装していない場合、適切に動作しない可能性があります。

• ASP.NET フォーム : プラグ可能な Microsoft ASP.NET フォームベースの認証システムを使用する、Windows 以外の ID 管理システムです。このモードでは、Windows SharePoint Services は LDAP (Lightweight Directory Access Protocol)、ライトウェイト データベース ID 管理システムなど、外部に定義されたグループまたはロールを含めたさまざまな ID 管理システムを操作できます。フォーム認証では、ASP.NET を使用して Windows SharePoint Services の認証を実行できます。多くの場合、ログオン ページにリダイレクトすることになります。

• 委任 : 信頼されたシステムから Windows SharePoint Services にエンドユーザーの資格情報を委任するシステムです。これにより、信頼されたサービスは、ユーザー ID を Windows SharePoint Services に渡して承認を受けることができ、Windows SharePoint Services は現在のユーザーの資格情報を保有する必要がないまま、ユーザーがだれであるかが伝達されます。

フォームベースの認証

フォームベースの認証では、メンバシップ プロバイダとロール マネージャを実装することによって Windows SharePoint Services でのカスタム ID 管理を提供します。メンバシップ プロバイダは個別のユーザーを識別および認証するためのインターフェイスを定義し、ロール マネージャは個別のユーザーを論理グループまたはロールにグループ化するためのインターフェイスを定義します。ユーザー名が指定されると、ロール プロバイダ システムは、そのユーザーが属するロールのリストを返します。メンバシップ プロバイダはログオン名とパスワードからユーザー トークンを作成し、ロール マネージャは現在のユーザーのグループ メンバシップ トークン セットを作成します。

ロール マネージャは省略可能なので、カスタムの認証システムがグループ (Windows Live ID など) をサポートしない場合、ロール マネージャは不要です。Windows SharePoint Services では、URL ゾーン (SPUrlZone) ごとに 1 つずつのメンバシップ プロバイダとロール マネージャをサポートします。ASP.NET フォームのロールには、権限の継承は関連付けられていません。代わりに、Windows SharePoint Services のポリシーと承認を経由してフォームのロールに権限が割り当てられます。

ログオン フォーム (login.aspx) は Windows SharePoint Services によって提供され、_layouts 仮想ディレクトリ (ローカル ドライブ:\\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS) にあります。このファイルによって、ユーザーの資格情報の収集と資格情報の Cookie への格納に使用される ASP.NET フォーム コントロールが実装されます。

Web サイトのサーバー管理者は、実行時仮想サーバーの web.config ファイルを変更することによって、メンバシップ プロバイダとロール マネージャを登録する必要があります。プロバイダが登録されない場合、ASP.NET フォームベースの認証は機能しません。同様に、サーバーの管理者は sptimer.exe.config ファイルを更新する必要があります。

Windows SharePoint Services では標準の ASP.NET 2.0 ロール プロバイダ インターフェイスを使用して、現在のユーザーのグループ情報を収集します。認証目的としては、ロールとグループは同じものです。どちらも承認用の論理セットにユーザーをグループ化するための方法です。それぞれの ASP.NET ロールは、Windows SharePoint Services によってドメイン グループとして扱われます。

ASP.NET によって提供されるプラグ可能な認証フレームワークの詳細については、「New Security Features in ASP.NET 2.0」を参照してください。

認証の委任

Windows SharePoint Services では、エンドユーザーの資格情報を外部システムから SharePoint 展開に委任することをサポートしており、エンド ユーザーが直接 Windows SharePoint Services に接続するのではなく別のシステムを介して接続しているときに、信頼されたサービスはユーザー ID を渡して承認を受けることができます。このようにして、Windows SharePoint Services はユーザーの資格情報を保持することなく、信頼されたコードによるユーザーの識別情報を受け入れます。

認証の委任では、あるサーバーがエンドユーザーの認証を別のサーバーに委任します。クライアント コンピュータは最初のサーバーに対して要求を行い、次に 2 番目のサーバーに対して 1 つ以上の要求をエンド ユーザーとして行います。成功するには、最初のサーバーがエンドユーザー認証を 2 番目のサーバーに委任することが必要です。それには、以下の 2 つの信頼関係のどちらかが必要です。

• クライアントは最初のサーバーの、たとえば、パスワードを使用した基本認証、または Microsoft Office SharePoint Server 2007 のプラグ可能なサインオン機構や Active Directory フェデレーション サービス (ADFS) のようなサーバー側資格情報ストアを信頼します。

• 2 番目のサーバーは最初のサーバーを信頼して、たとえば、制限付きの Kerberos 委任信頼関係をサーバー間で確立するなど有効な目的のために、有効な資格情報を伝えます。