Seal Report の入门：認証プロバイダー

レポート作成とデータソースへの連携はもう一つの機能であり、別の関心点はレポートに対する承認制御の適用です。デフォルトでは、Seal Report リポジトリのフォルダ内に Security サブフォルダが存在し、そこには認証プロバイダーと、各レポートサーバーインスタンスにおけるユーザー承認の処理方法を定義する Security.xml ファイルが含まれています。階層構造は以下の通りです。 Seal Report Repository |__ Security |__ Security.xml |__ Providers |__ Basic Authentication.cshtml |__ Basic Windows Authentication.cshtml |__ Claims Principal.cshtml |__ Database Authentication.cshtml |__ Integrated Windows Authentication.cshtml |__ JWT.cshtml |__ LDAP Authentication.cshtml |__ No Security.cshtml |__ OpenId.cshtml 本記事では、これらの認証プロバイダーのそれぞれをレビューし、レポート結果の取得に用いられるフローを考察します。 Security.xml ファイル Seal Report サーバーのリソースに対する許可されたアクセスを管理する責務を負うファイルです。ルート要素には 4 つの主要セクションが含まれています。カスタムセキュリティプロバイダーを使用している場合、そのセクションも表示されます。 ProviderName タグ内では、Providers サブフォルダにある利用可能な承認方法のいずれかを指定する必要があります（.cshtml ファイル拡張子なし）。例えば、OAuth true Parameters タグには要素の配列が含まれます。各セキュリティパラメータは鍵 - 値ペアを表します。例えば、check_auth_url http://localhost:3000/auth/check_token Groups タグには要素の配列が含まれます。各セキュリティグループには、一意の識別子、表示名、およびそのグループメンバーがアクセスを許可されているフォルダのセットが含まれます。さらに、セキュリティグループごとに権限を設定できます。これらの権限は、メンバーが以下の操作を許可されているかどうかを定義します。 - レポートを表示する - レポートをダウンロードする - レポートを編集する - 設定を変更する 例えば、fab75313-9be6-4d53-9545-781c2027f6f4 Administrator \PathToReportsFolder 1 true Download Logins タグには要素の配列が含まれます。各要素は、以下の情報を持つユーザーアカウントを定義します。 - 一意の識別子 - ユーザー ID - パスワードのハッシュ - 表示名 - 関連するセキュリティグループ ID 例えば、d8f5a54208af4d62a7c452e8d52ae659 username_here password_hash_here user_display_name_here user_email_here fab75313-9be6-4d53-9545-781c2027f6f4 Security.xml ファイルの構造と目的を理解することは、利用可能な承認プロバイダーの詳細を検討する前に不可欠です。 Basic Authentication プロバイダー Basic Authentication プロバイダーは、Seal Report ログイン画面に入力されたクレデンシャルに基づいてユーザーを検証し、Security.xml ファイルのセクションに定義されたエントリーと一致させます。その実装は以下のスクリプトにあります。 Security/Providers/Basic Authentication.cshtml 認証の間に、プロバイダーは Seal Report サーバーインターフェースを通じてユーザーが入力した値を使用します：WebUserName WebPassword これらの値は LoginAuthentication() メソッドに渡されます。 if (!user.LoginAuthentication(user.WebUserName, user.WebPassword)) { throw new Exception("Invalid user name or password"); } このメソッドは、Security.xml ファイルに宣言されたユーザーに対してクレデンシャルを検証します。認証に失敗すれば、レポートサーバーへのアクセスは拒否されます。認証に成功すれば、認証されたユーザーは対応するエントリーに関連付けられたセキュリティグループを継承します。これらのグループは、レポートフォルダへのアクセス権限と、レポートの表示、ダウンロード、または編集などの利用可能な操作を決定します。さらに、プロバイダーは認証されたユーザー名を現在のセッションに割り当てます： user.Name = user.WebUserName; この値は、後に Seal Report サーバーインターフェースがアクティブなユーザーに関する情報を表示する際に使用されます。 Basic Authentication プロバイダーは、認証が Security.xml に保存されたリポジトリ構成を介して直接管理される場合、Seal Report サーバーリソースへのアクセスを最もしっくりと守る方法です。 Basic Windows Authentication プロバイダー Basic Windows Authentication プロバイダーは、Windows クレデンシャルを基にユーザーを検証します。

One thing is to create report definitions and link them to data sources; another is to apply authorization to those reports. By default, the Seal Report Repository folder contains a Security subfolder. This folder includes authentication providers and a Security.xml file that defines how user authorization is handled for each instance of the report server. The hierarchy looks like this: . Seal Report Repository |__ Security |__ Security.xml |__ Providers |__ Basic Authentication.cshtml |__ Basic Windows Authentication.cshtml |__ Claims Principal.cshtml |__ Database Authentication.cshtml |__ Integrated Windows Authentication.cshtml |__ JWT.cshtml |__ LDAP Authentication.cshtml |__ No Security.cshtml |__ OpenId.cshtml In this post, we will review each of these authentication providers and examine the flow used to retrieve report results. Security.xml File The file responsible for managing authorized access to Seal Report Server resources has the root element. There are four main sections within this root element: If you are using a custom security provider, the section will also appear. Inside the ProviderName tag, one of the authorization methods available in the Providers subfolder must be specified (without the .cshtml file extension). For example, OAuth true The Parameters tag contains an array of elements. Each security parameter represents a key–value pair. For example, check_auth_url http://localhost:3000/auth/check_token The Groups tag contains an array of elements. Each security group has: a unique identifier a display name a set of folders that group members are allowed to access. Additionally, permissions can be configured per security group. These permissions define whether members are allowed to: view reports download reports edit reports modify configuration settings For example, fab75313-9be6-4d53-9545-781c2027f6f4 Administrator \PathToReportsFolder 1 true Download The Logins tag contains an array of elements. Each element defines a user account with: a unique identifier user ID password hash display name email address associated security group IDs For example, d8f5a54208af4d62a7c452e8d52ae659 username_here password_hash_here user_display_name_here user_email_here fab75313-9be6-4d53-9545-781c2027f6f4 Understanding the structure and purpose of the Security.xml file is essential before exploring the available authorization providers in detail. The Basic Authentication provider validates users based on credentials entered in the Seal Report login screen and matches them against entries defined in the section of the Security.xml file. Its implementation is located in the following script: Security/Providers/Basic Authentication.cshtml During authentication, the provider uses the values entered by the user through the Seal Report Server interface: WebUserName WebPassword These values are passed to the LoginAuthentication() method: if (!user.LoginAuthentication(user.WebUserName, user.WebPassword)) { throw new Exception("Invalid user name or password"); } The method validates the credentials against the users declared in the Security.xml file. If authentication fails, access to the report server is denied. If authentication succeeds, the authenticated user inherits the security groups associated with the corresponding entry. These groups determine access permissions to report folders and available operations such as viewing, downloading, or editing reports. Additionally, the provider assigns the authenticated username to the current session: user.Name = user.WebUserName; This value is later used by the Seal Report Server interface when displaying information about the active user. The Basic Authentication provider represents the most straightforward way to secure access to Seal Report Server resources when authentication is managed directly through the repository configuration stored in Security.xml. The Basic Windows Authentication provider validates users using Windows credentials entered in the Seal Report login screen. The authentication process relies on Windows identity verification and optionally maps Windows groups to Seal Report security groups. Its implementation is located in the following script: Security/Providers/Basic Windows Authentication.cshtml During authentication, the provider reads the credentials entered in the login interface through the WebUserName and WebPassword properties. These values are passed to the Windows authentication mechanism using the Impersonator.CheckWindowsLogin() method: user.Identity = Impersonator.CheckWindowsLogin( user.WebUserName, user.Security.GetValue("default_domain_name"), user.WebPassword ); If the authentication succeeds, a Windows identity is assigned to the current session and the username is stored in the active Seal Report user context: user.Name = user.WebUserName; After successful authentication, security groups are assigned either by matching Windows groups with Seal Report security groups or by assigning the default security group defined in the configuration. This behavior depends on the value of the add_windows_groups parameter declared in the provider settings. If Windows group matching is enabled, the provider retrieves the user’s Windows groups and attempts to associate them with existing Seal Report security groups. Otherwise, the default security group is applied automatically. If authentication succeeds but no matching security groups are assigned, the provider logs the detected Windows groups for diagnostic purposes and prevents access to report resources until group membership is resolved. If Windows authentication fails, access to the Seal Report Server is denied. The Basic Windows Authentication provider is typically used when Seal Report Server must authenticate users directly against Windows accounts entered through the login interface without relying on integrated domain authentication mechanisms. The Claims Principal provider authenticates users based on the ClaimsPrincipal object available in the HTTP request context. This provider is typically used when authentication is already performed by an external identity platform such as Azure App Service or another middleware component that injects claims into the request pipeline. Its implementation is located in the following script: Security/Providers/Claims Principal.cshtml During authentication, the provider retrieves the ClaimsPrincipal instance from the incoming HTTP request and extracts user identity information from its claims collection. The username is obtained from the claim of type name and assigned to both the WebUserName and Name properties of the active user session. After the identity is resolved, the provider iterates through the security groups defined in Security.xml and assigns matching groups when the authenticated principal belongs to roles with corresponding names. If no matching groups are found, access to report resources is denied and a warning is written to the server log. The Claims Principal provider is typically used when Seal Report Server operates behind an authentication-enabled hosting environment where user identity and role membership are already resolved before the request reaches the reporting layer. The Database Authentication provider validates users by attempting a connection to a database using the credentials entered in the Seal Report login screen. Authentication succeeds if the database connection is successfully established. Its implementation is located in the following script: Security/Providers/Database Authentication.cshtml During authentication, the provider uses the values entered through WebUserName and WebPassword to open a database connection based on the configured oledb_connection_string parameter. If the connection succeeds, the username is assigned to the active session and the default security group defined in the configuration is applied automatically. The provider also allows security groups to be resolved dynamically from database queries if additional logic is implemented inside the authentication script. The Database Authentication provider is typically used when user credentials are stored and validated directly within a relational database system accessible through an OLE DB connection. The Integrated Windows Authentication provider authenticates users based on the Windows identity already associated with the current HTTP request. This provider relies on IIS Windows Authentication and does not require credentials to be entered manually through the Seal Report login interface. Its implementation is located in the following script: Security/Providers/Integrated Windows Authentication.cshtml During authentication, the provider retrieves the Windows identity from the WebPrincipal object available in the request context. If the identity is authenticated, the username is assigned to the active session and security groups are applied either by matching Windows groups with Seal Report security groups or by assigning the default security group depending on provider configuration parameters. If the request does not contain an authenticated Windows identity, access to the Seal Report Server is denied and an error message indicates that Windows Authentication must be enabled in IIS. The Integrated Windows Authentication provider is typically used when Seal Report Server is deployed inside a Windows domain environment where authentication is managed transparently by IIS. The JWT provider authenticates users based on a JSON Web Token received either through the SWILogin parameter or through the HTTP Authorization header using the Bearer scheme. Its implementation is located in the following script: Security/Providers/JWT.cshtml During authentication, the provider retrieves the token from the request and validates it using the configured token_key parameter. After decoding the token payload, the expiration timestamp is verified against the current system time to ensure the token is still valid. If the token is valid, the username and associated security group are extracted from the token payload and applied to the active user session. If the token is missing or invalid, an alternate credential-based authentication flow may be executed depending on the provider configuration. The JWT provider is typically used when Seal Report Server is integrated with external authentication services that issue signed tokens representing authenticated user sessions. The LDAP Authentication provider validates users against an LDAP directory service using credentials entered in the Seal Report login interface. Its implementation is located in the following script: Security/Providers/LDAP Authentication.cshtml During authentication, the provider creates an LDAP connection using the configured server name, port number, authentication type, and SSL settings. The credentials entered through WebUserName and WebPassword are used to bind to the LDAP server. If the bind operation succeeds, the username is assigned to the active session and the default security group is applied automatically. Additional logic may be implemented to retrieve group membership information directly from the LDAP directory. The LDAP Authentication provider is typically used when user credentials are managed centrally within directory services such as Active Directory or other LDAP-compatible identity providers. The No Security provider allows unrestricted access to the Seal Report Server by automatically assigning the default security group without performing any authentication checks. Its implementation is located in the following script: Security/Providers/No Security.cshtml During authentication, the provider assigns the default security group defined in the configuration and initializes the session without validating user credentials. No username is required for access to report resources. The No Security provider is typically used in development environments or scenarios where access to the report server is already controlled externally. The OpenId provider authenticates users based on an OpenID token received through the request context and extracts identity information from the token payload. Its implementation is located in the following script: Security/Providers/OpenId.cshtml During authentication, the provider reads the token payload and verifies the expiration timestamp before allowing access to report resources. If the token is valid, a security group is assigned to the active session based on information contained in the token claims. If no token is present, an alternate credential-based authentication flow may be used depending on provider configuration. The OpenId provider is typically used when Seal Report Server is integrated with external identity providers supporting OpenID-based authentication workflows. The following table summarizes the main characteristics of the available authentication providers and helps identify which one best fits a particular deployment scenario. Provider Credentials Source Infrastructure Requirement Security Groups Resolution Typical Usage Scenario Basic Authentication Security.xml () None From Security.xml Local users stored inside Seal repository Basic Windows Authentication Windows account (manual login) Windows domain or local machine accounts Default group or mapped Windows groups Windows credentials entered through login screen Integrated Windows Authentication IIS Windows identity IIS Windows Authentication enabled Default group or mapped Windows groups Transparent domain authentication inside intranet Claims Principal HTTP request claims External identity platform (e.g., Azure App Service) Role-to-group matching Reverse proxy / platform-managed authentication Database Authentication Database connection validation Accessible relational database (OLE DB) Default group or database-driven logic Credentials stored in application database LDAP Authentication LDAP bind operation LDAP / Active Directory server Default group or LDAP-driven logic Centralized directory authentication JWT Token payload External token issuer Group from token claim API gateway / SSO / token-based authentication OpenId ID token payload OpenID-compatible identity provider Group from token claim Cloud identity providers (OIDC workflows) No Security None None Default group only Development or externally protected environments The choice of authentication provider depends primarily on where user identities are managed and whether authentication should be handled directly by Seal Report Server or delegated to external infrastructure components such as IIS, directory services, databases, or token-based identity providers. To integrate Seal Report Server as an embedded component within a web application, the first request must call the {SealReportURI}/SWILogin endpoint with the expected payload and/or headers, depending on the authentication provider configured in the Seal Report Server. If authentication succeeds, the server returns information about the current user session in JSON format. For example: { "name": "username_here, "group": "user_group_here", "culture": null, "language": "en", "folder": "\\relative_path_to_the_folder_on_the_server", "showfolders": true, "editconfiguration": false, "editprofile": true, "downloadupload": 0, "changepassword": false, "showresetpassword": false, "usertag": null, "onstartup": 0, "startupreport": null, "startupreportname": null, "report": "", "reportname": "", "executionmode": 0, "groupexecutionmode": 1, "sources": [ // data sources // and connections here ], "sessionId": "an_UUID_here" } The returned sessionId value must be included in all subsequent requests to the Seal Report Server. After authentication is completed, reports can be executed by calling the {SealReportURI}/SWExecuteReport endpoint. This endpoint returns the generated HTML page containing all required JavaScript and CSS resources necessary for rendering the report. The request to the SWExecuteReport endpoint uses the application/x-www-form-urlencoded content type and typically includes the following parameters: sessionId path (for example: /RelativePathToReports/ReportName.srex) When embedding Seal Report Server into a custom web application, it is often necessary to introduce a client-side interceptor or script-loading mechanism to ensure that dynamically returned JavaScript resources are executed correctly and that additional business-driven UI customizations can be applied. Seal Report Server supports multiple authentication providers that can be selected depending on where user identities are managed: locally in Security.xml, within Windows infrastructure, directory services such as LDAP, databases, or external identity platforms using claims or tokens. The authentication process starts with the {SealReportURI}/SWILogin endpoint and produces a session identifier required for all subsequent report execution requests. Because authentication providers are script-based, they can be extended or adapted to match project-specific integration requirements without modifying the Seal Report Server core.