Reporting Services での認証
認証とは、ユーザーの本人性を立証するプロセスです。 ユーザー認証にはさまざまな方法がありますが、 最も一般的なのはユーザー パスワードを使用する方法です。 たとえば、フォーム認証を実装する場合は、ユーザーに資格情報のクエリを実行し (通常、サインイン名とパスワードを要求する一部のインターフェイスで)、データベース テーブルや構成ファイルなどのデータ ストアに対してユーザーを検証する実装が必要です。 資格情報を検証できない場合、認証プロセスは失敗し、ユーザーは匿名 ID を想定します。
Reporting Services でのカスタム認証
Reporting Services では、統合セキュリティを使用するか、またはユーザーの資格情報を明示的に受信して検証することによって、Windows オペレーティング システムがユーザー認証を実施します。 Reporting Services では、より多くの認証スキームをサポートするためにカスタム認証を開発できます。 このサポートは、セキュリティ拡張機能インターフェイスを介して可能になります IAuthenticationExtension2。 レポート サーバーであらゆる拡張機能を配置および使用できるように、すべての拡張機能が IExtension ベース インターフェイスから継承されます。 IExtension、および IAuthenticationExtension2、 は名前空間の Microsoft.ReportingServices.Interfaces メンバーです。
Reporting Services では、レポート サーバーに対して認証を行うための主要な手段として、LogonUser メソッドがあります。 Reporting Services Web サービスのこのメンバーを使用して、検証するユーザーの資格情報をレポート サーバーに渡すことができます。 基になるセキュリティ拡張機能は、カスタム認証コードを含む IAuthenticationExtension2.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 サービスには、Web ポータルとレポート サーバーによるフォーム認証を可能にするカスタム認証拡張機能が用意されています。
Reporting Services Web サービスの LogonUser メソッドを使用して、認証する資格情報をレポート サーバーに送信します。 Web サービスは HTTP ヘッダーを使用して、検証済みのサインイン要求のためにサーバーからクライアントに認証チケット ("Cookie" と呼ばれます) を渡します。
次の図は、レポート サーバーがカスタム認証拡張機能を使用するように構成されたアプリケーション配置における、Web サービスのユーザーを認証するメソッドを示しています。
図 2 が示すように、認証プロセスは次のようになります。
クライアント アプリケーションは、ユーザーを認証するために Web サービス メソッド LogonUser を呼び出します。
Web サービスは、セキュリティ拡張機能の LogonUser メソッド、つまり IAuthenticationExtension2 を実装するクラスを呼び出します。
LogonUser の実装によって、ユーザー ストアまたはセキュリティ機関のユーザー名とパスワードが検証されます。
認証の完了後に、Web サービスがクッキーを作成し、セッション用にそれを管理します。
Web サービスは、HTTP ヘッダーの呼び出し元アプリケーションに認証チケットを返します。
Web サービスがセキュリティ拡張機能によってユーザーの認証を正常に完了すると、以降の要求に使用されるクッキーが生成されます。 レポート サーバーがセキュリティ機関を所有していないため、Cookie がカスタム セキュリティ機関内に保持されない可能性があります。 クッキーは LogonUser Web サービス メソッドから返され、以降の Web サービス メソッド呼び出しおよび URL アクセスに使用されます。
Note
転送時にクッキーが損傷しないよう、LogonUser から返される認証クッキーの転送をトランスポート層セキュリティ (TLS) (旧称 Secure Sockets Layer (SSL)) 暗号化を使用して保護する必要があります。
カスタム セキュリティ拡張機能をインストールした場合に URL アクセスによってレポート サーバーにアクセスすると、インターネット インフォメーション サービス (IIS) および ASP.NET が認証チケットの転送を自動的に管理します。 SOAP API を使用してレポート サーバーにアクセスする場合は、プロキシ クラスの実装に、認証チケットを管理するための追加のサポートが含まれている必要があります。 SOAP API の使用および認証チケットの管理の詳細については、「カスタム セキュリティでの Web サービスの使用」を参照してください。
フォーム認証
フォーム認証は ASP.NET 認証の種類の 1 つであり、未認証ユーザーは HTML フォームにリダイレクトされます。 ユーザーが資格情報を入力すると、認証チケットを含むクッキーが発行されます。 後の要求では、システムは最初に Cookie をチェックして、レポート サーバーがユーザーを認証したかどうかを確認します。
Reporting Services API から利用できるセキュリティ拡張機能インターフェイスを使用すると、フォーム認証をサポートするように Reporting Services を拡張できます。 フォーム認証を使用するように Reporting Services を拡張する場合は、レポート サーバーとのすべての通信にトランスポート層セキュリティ (TLS) (旧称 Secure Sockets Layer (SSL)) を使用して、悪意のあるユーザーが別のユーザーのクッキーにアクセスすることを防止します。 TLS を使用した場合、クライアントとレポート サーバーが相互に認証でき、2 台のコンピューター間の通信内容を他のコンピューターから読み取ることができなくなります。 TLS 接続を介してクライアントから送信されるすべてのデータは暗号化されるため、悪意のあるユーザーがレポート サーバーに送信されたパスワードやデータを傍受できなくなります。
フォーム認証は、Windows 以外のプラットフォームのアカウントと認証をサポートするために実装されています。 レポート サーバーへのアクセスを要求するユーザーにグラフィカル インターフェイスが表示され、入力した資格情報が認証のためにセキュリティ機関に送信されます。
フォーム認証では、ユーザーが資格情報を入力する必要があります。 Reporting Services Web サービスと直接通信する自動アプリケーションの場合は、フォーム認証とカスタム認証方法を併用する必要があります。
Reporting Services でフォーム認証が適しているのは、次のような場合です。
Microsoft Windows アカウントを持たないユーザーを保存して認証する必要があります。
Web サイト上の異なるページ間のサインイン ページとして、独自のユーザー インターフェイス フォームを指定する必要があります。
フォーム認証をサポートするカスタム セキュリティ拡張機能を記述する場合は、次の点を考慮してください。
フォーム認証を使用する場合は、インターネット インフォメーション サービス (IIS) のレポート サーバー仮想ディレクトリで匿名アクセスを有効にする必要があります。
ASP.NET 認証を Forms に設定する必要があります。 レポート サーバーの Web.config ファイルで ASP.NET 認証を構成してください。
Reporting Services では、Windows 認証またはカスタム認証を使用してユーザーを認証および承認できますが、両方を使用することはできません。 Reporting Services では、複数のセキュリティ拡張機能の同時使用はサポートされていません。
関連するコンテンツ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示