認証は、ID に対するユーザーの権利を確立するプロセスです。 ユーザーの認証に使用できる手法は多数あります。 最も一般的な方法は、パスワードを使用する方法です。 たとえば、フォーム認証を実装する場合は、ユーザーに資格情報のクエリを実行し (通常は、ログイン名とパスワードを要求する一部のインターフェイスで)、データベース テーブルや構成ファイルなどのデータ ストアに対してユーザーを検証する実装が必要です。 資格情報を検証できない場合、認証プロセスは失敗し、ユーザーは匿名 ID を想定します。
Reporting Services のカスタム認証
Reporting Services では、Windows オペレーティング システムは、統合セキュリティまたはユーザー資格情報の明示的な受信と検証を通じて、ユーザーの認証を処理します。 追加の認証スキームをサポートするために、Reporting Services でカスタム認証を開発できます。 これは、セキュリティ拡張機能インターフェイスの IAuthenticationExtensionを通じて可能になります。 すべての拡張機能は、レポート サーバーによって展開および使用されるすべての拡張機能の IExtension 基本インターフェイスから継承されます。 IExtensionは、 IAuthenticationExtensionと同様に、 Microsoft.ReportingServices.Interfaces 名前空間のメンバーです。
Reporting Services のレポート サーバーに対して認証を行う主な方法は、 LogonUser 方法です。 Reporting Services Web サービスのこのメンバーは、検証のためにユーザー資格情報をレポート サーバーに渡すために使用できます。 基になるセキュリティ拡張機能は、カスタム認証コードを含む IAuthenticationExtension.LogonUser を実装します。 フォーム認証のサンプル LogonUser では、指定された資格情報とデータベース内のカスタム ユーザー ストアに対して認証チェックを実行します。 LogonUser の実装の例を次に示します。
public bool LogonUser(string userName, string password, string authority)
{
return AuthenticationUtilities.VerifyPassword(userName, password);
}
次のサンプル関数を使用して、指定された資格情報を確認します。
internal static bool VerifyPassword(string suppliedUserName,
string suppliedPassword)
{
bool passwordMatch = false;
// Get the salt and pwd from the database based on the user name.
// See "How To: Use DPAPI (Machine Store) from ASP.NET," "How To:
// Use DPAPI (User Store) from Enterprise Services," and "How To:
// Create a DPAPI Library" for more information about how to use
// DPAPI to securely store connection strings.
SqlConnection conn = new SqlConnection(
"Server=localhost;" +
"Integrated Security=SSPI;" +
"database=UserAccounts");
SqlCommand cmd = new SqlCommand("LookupUser", conn);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter sqlParam = cmd.Parameters.Add("@userName",
SqlDbType.VarChar,
255);
sqlParam.Value = suppliedUserName;
try
{
conn.Open();
SqlDataReader reader = cmd.ExecuteReader();
reader.Read(); // Advance to the one and only row
// Return output parameters from returned data stream
string dbPasswordHash = reader.GetString(0);
string salt = reader.GetString(1);
reader.Close();
// Now take the salt and the password entered by the user
// and concatenate them together.
string passwordAndSalt = String.Concat(suppliedPassword, salt);
// Now hash them
string hashedPasswordAndSalt =
FormsAuthentication.HashPasswordForStoringInConfigFile(
passwordAndSalt,
"SHA1");
// Now verify them. Returns true if they are equal.
passwordMatch = hashedPasswordAndSalt.Equals(dbPasswordHash);
}
catch (Exception ex)
{
throw new Exception("Exception verifying password. " +
ex.Message);
}
finally
{
conn.Close();
}
return passwordMatch;
}
認証フロー
Reporting Services Web サービスには、レポート マネージャーとレポート サーバーによるフォーム認証を有効にするカスタム認証拡張機能が用意されています。
Reporting Services Web サービスの LogonUser 方法は、認証のためにレポート サーバーに資格情報を送信するために使用されます。 Web サービスは、HTTP ヘッダーを使用して、検証されたログオン要求の認証チケット ("Cookie" と呼ばれます) をサーバーからクライアントに渡します。
次の図は、カスタム認証拡張機能を使用するように構成されたレポート サーバーでアプリケーションを展開するときに、Web サービスに対してユーザーを認証する方法を示しています。
図 2 に示すように、認証プロセスは次のようになります。
クライアント アプリケーションは、Web サービス LogonUser メソッドを呼び出してユーザーを認証します。
Web サービスは、セキュリティ拡張機能の LogonUser メソッド (具体的には 、IAuthenticationExtension を実装するクラス) を呼び出します。
LogonUserの実装により、ユーザー ストアまたはセキュリティ機関のユーザー名とパスワードが検証されます。
認証が成功すると、Web サービスによって Cookie が作成され、セッションの Cookie が管理されます。
Web サービスは、HTTP ヘッダーの呼び出し元アプリケーションに認証チケットを返します。
Web サービスは、セキュリティ拡張機能を使用してユーザーを正常に認証すると、後続の要求に使用される Cookie を生成します。 レポート サーバーがセキュリティ機関を所有していないため、Cookie がカスタム セキュリティ機関内に保持されない場合があります。 Cookie は、 LogonUser Web サービス メソッドから返され、後続の Web サービス メソッド呼び出しおよび URL アクセスで使用されます。
注
送信中に Cookie が損なわれるのを防ぐために、 LogonUser から返される認証 Cookie は、Secure Sockets Layer (SSL) 暗号化を使用して安全に送信する必要があります。
カスタム セキュリティ拡張機能のインストール時に URL アクセスを使用してレポート サーバーにアクセスすると、インターネット インフォメーション サービス (IIS) と ASP.NET 認証チケットの送信が自動的に管理されます。 SOAP API を使用してレポート サーバーにアクセスする場合、プロキシ クラスの実装には、認証チケットを管理するための追加のサポートが含まれている必要があります。 SOAP API の使用と認証チケットの管理の詳細については、「カスタム セキュリティでの Web サービスの使用」を参照してください。
フォーム認証
フォーム認証は、認証されていないユーザーが HTML フォームに転送される ASP.NET 認証の一種です。 ユーザーが資格情報を入力すると、システムは認証チケットを含む Cookie を発行します。 後の要求で、システムは最初に Cookie をチェックして、ユーザーがレポート サーバーによって既に認証されているかどうかを確認します。
Reporting Services は、Reporting Services API で使用できるセキュリティ拡張インターフェイスを使用して、フォーム認証をサポートするように拡張できます。 フォーム認証を使用するように Reporting Services を拡張する場合は、レポート サーバーとのすべての通信に Secure Sockets Layer (SSL) を使用して、悪意のあるユーザーが別のユーザーの Cookie にアクセスできないようにします。 SSL を使用すると、クライアントとレポート サーバーが相互に認証を行い、他のコンピューターが 2 台のコンピューター間の通信の内容を読み取れないようにすることができます。 SSL 接続を介してクライアントから送信されるすべてのデータは暗号化されるため、悪意のあるユーザーはレポート サーバーに送信されたパスワードやデータを傍受できません。
フォーム認証は、通常、Windows 以外のプラットフォームのアカウントと認証をサポートするために実装されます。 レポート サーバーへのアクセスを要求するユーザーにグラフィカル インターフェイスが表示され、指定された資格情報が認証のためにセキュリティ機関に送信されます。
フォーム認証では、ユーザーが資格情報を入力する必要があります。 Reporting Services Web サービスと直接通信する無人アプリケーションの場合、フォーム認証をカスタム認証スキームと組み合わせる必要があります。
フォーム認証は、次の場合に Reporting Services に適しています。
Microsoft Windows アカウントを持たないユーザーを保存して認証する必要があります。
Web サイト上の異なるページ間のログオン ページとして、独自のユーザー インターフェイス フォームを指定する必要があります。
フォーム認証をサポートするカスタム セキュリティ拡張機能を記述するときは、次の点を考慮してください。
フォーム認証を使用する場合は、インターネット インフォメーション サービス (IIS) のレポート サーバー仮想ディレクトリで匿名アクセスを有効にする必要があります。
ASP.NET 認証はフォームに設定する必要があります。 ASP.NET 認証は、レポート サーバーの Web.config ファイルで構成します。
Reporting Services では、Windows 認証またはカスタム認証を使用してユーザーを認証および承認できますが、両方を認証することはできません。 Reporting Services では、複数のセキュリティ拡張機能の同時使用はサポートされていません。