Reporting Services での認証

認証とは、ユーザーの本人性を立証するプロセスです。 ユーザー認証にはさまざまな方法がありますが、 最も一般的なのはユーザー パスワードを使用する方法です。 たとえば、フォーム認証を実装する場合は、ユーザーに対して資格情報の提示を要求し (通常は、ログイン名とパスワードを要求するインターフェイスを使用)、データベース テーブルや構成ファイルなどのデータ ストアと照合して、そのユーザーが本人かどうかを検証します。 資格情報の有効性を確認できない場合は、認証プロセスが失敗し、そのユーザーは匿名ユーザーであると見なされます。

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 ヘッダーを使用して、検証されたログオン要求の認証チケット (クッキー) をサーバーからクライアントに渡します。

次の図は、レポート サーバーがカスタム認証拡張機能を使用するように構成されたアプリケーション配置における、Web サービスのユーザーを認証するメソッドを示しています。

Reporting Services のセキュリティ認証フロー

図 2 が示すように、認証プロセスは次のようになります。

  1. クライアント アプリケーションは、ユーザーを認証するために Web サービス メソッド LogonUser を呼び出します。

  2. Web サービスは、セキュリティ拡張機能の LogonUser メソッド、つまり IAuthenticationExtension を実装するクラスを呼び出します。

  3. LogonUser の実装によって、ユーザー ストアまたはセキュリティ機関のユーザー名とパスワードが検証されます。

  4. 認証の完了後に、Web サービスがクッキーを作成し、セッション用にそれを管理します。

  5. Web サービスは、HTTP ヘッダーの呼び出し元アプリケーションに認証チケットを返します。

Web サービスがセキュリティ拡張機能によってユーザーの認証を正常に完了すると、以降の要求に使用されるクッキーが生成されます。 クッキーをカスタム セキュリティ機関に保持することはできません。レポート サーバーがセキュリティ機関を所有していないためです。 クッキーは LogonUser Web サービス メソッドから返され、以降の Web サービス メソッド呼び出しおよび URL アクセスに使用されます。

注意

転送時にクッキーが損傷しないよう、LogonUser から返される認証クッキーの転送を Secure Sockets Layer (SSL) 暗号化を使用して保護する必要があります。

カスタム セキュリティ拡張機能をインストールした場合に URL アクセスによってレポート サーバーにアクセスすると、インターネット インフォメーション サービス (IIS) および ASP.NET が認証チケットの転送を自動的に管理します。 OAP API によってレポート サーバーにアクセスする場合は、プロキシ クラスの実装に認証チケット管理用の追加サポートを含める必要があります。 SOAP API の使用および認証チケットの管理の詳細については、「カスタム セキュリティでの Web サービスの使用」を参照してください。

フォーム認証

フォーム認証は ASP.NET 認証の種類の 1 つであり、未認証ユーザーは HTML フォームにリダイレクトされます。 ユーザーが資格情報を入力すると、認証チケットを含むクッキーが発行されます。 以降の要求では、クッキーをチェックしてユーザーがレポート サーバーによって認証されているかどうかを確認します。

Reporting Services API から利用できるセキュリティ拡張機能インターフェイスを使用すると、フォーム認証をサポートするように Reporting Services を拡張できます。 フォーム認証を使用するように Reporting Services を拡張する場合は、レポート サーバーとのすべての通信に Secure Sockets Layer (SSL) を使用して、悪意のあるユーザーが別のユーザーのクッキーにアクセスすることを防止します。 SSL を使用した場合、クライアントとレポート サーバーが相互に認証でき、2 台のコンピューター間の通信内容を他のコンピューターから読み取ることができなくなります。 SSL 接続で送信されたすべてのデータが暗号化されるため、悪意のあるユーザーはレポート サーバーに送信されたパスワードやデータを傍受できません。

一般に、フォーム認証は、Windows 以外のプラットフォームでのアカウントおよび認証をサポートするために実装されます。 レポート サーバーへのアクセスを要求するユーザーにグラフィカル インターフェイスが表示され、入力した資格情報が認証のためにセキュリティ機関に送信されます。

フォーム認証では、ユーザーが資格情報を入力する必要があります。 Reporting Services Web サービスと直接通信する自動アプリケーションの場合は、フォーム認証とカスタム認証方法を併用する必要があります。

Reporting Services でフォーム認証が適しているのは、次のような場合です。

  • Microsoft Windows アカウントを持たないユーザーを格納および認証する必要がある場合。

  • Web サイトの異なるページ間で、ログオン ページとしてユーザー インターフェイス フォームを提供する必要がある場合。

フォーム認証をサポートするカスタム セキュリティ拡張機能を記述する場合は、次のことを考慮してください。

  • フォーム認証を使用する場合は、インターネット インフォメーション サービス (IIS) のレポート サーバー仮想ディレクトリで匿名アクセスを有効にする必要があります。

  • ASP.NET 認証を Forms に設定する必要があります。 レポート サーバーの Web.config ファイルで ASP.NET 認証を構成してください。

  • Reporting Services では、Windows 認証またはカスタム認証を使用してユーザーを認証および承認できますが、両方を使用することはできません。 Reporting Services では、複数のセキュリティ拡張機能を同時に使用できません。

関連項目

概念

セキュリティ拡張機能の実装