[アーティクル]
04/01/2012

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 が示すように、認証プロセスは次のようになります。

クライアントアプリケーションは、ユーザーを認証するために Web サービスメソッド LogonUser を呼び出します。
Web サービスは、セキュリティ拡張機能の LogonUser メソッド、つまり IAuthenticationExtension を実装するクラスを呼び出します。
LogonUser の実装によって、ユーザーストアまたはセキュリティ機関のユーザー名とパスワードが検証されます。
認証の完了後に、Web サービスがクッキーを作成し、セッション用にそれを管理します。
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 では、複数のセキュリティ拡張機能を同時に使用できません。

次の方法で共有

Reporting Services での認証

Reporting Services でのカスタム認証

認証フロー

フォーム認証

関連項目

概念

その他のリソース