inrule/authoring-backend repository overview

⁠irAuthor Web Backend

The Backend provides the APIs used by irAuthor Web, stores authoring data in SQL Server, and connects each tenant to irCatalog. A self-hosted installation runs the Backend alongside the irAuthor Web Client.

A tenant is a workspace backed by an irCatalog. Users sign in through their configured identity provider and open the tenant's URL; their catalog accounts and roles control access.

⁠Before you start

You need:

• Docker with Linux container support and a compatible Backend and Web Client image pair.
• An OpenID Connect identity provider, such as Auth0 or Microsoft Entra ID, with a public SPA registration and an API registration.
• A reachable irCatalog service with a catalog service account for each tenant.
• A separate, empty SQL Server database for authoring data. The Backend creates its tables at startup, so its database account needs permission to apply schema changes.
• HTTPS addresses on your network and trusted TLS certificates for the Backend and Web Client.

The examples use an HTTPS reverse proxy on the Docker host. Both containers serve HTTP behind that proxy. SQL Server, irCatalog, and the identity provider must be reachable from the Backend container; its localhost refers to the container, not the Docker host.

Use a browser with Web Locks and crypto.randomUUID support in a secure context, such as HTTPS.

Set up and license irCatalog and any optional Decision Service independently of irAuthor Web.

The Catalog Service image used in this example is:

docker pull inrule/catalog-service:v20260813.5

Use Catalog Manager⁠ to manage catalog accounts and roles. Follow the Catalog Service⁠, Catalog Manager, and optional Decision Services⁠ deployment guides to configure those containers before starting irAuthor Web.

⁠Example network

These examples use Docker host address 192.168.10.20 and a shared Docker network named irauthor. Replace the address with your host's LAN address.

Use certificates valid for the chosen IP address and trusted by client machines. If your certificates use DNS names, substitute those names consistently in the browser addresses and sign-in settings.

Create the network once and connect your existing SQL Server and Catalog Service containers. Replace the container-name placeholders:

docker network create irauthor
docker network connect --alias sqlserver irauthor "<sql-container-name>"
docker network connect --alias catalog-service irauthor "<catalog-container-name>"

Skip a command if the network or connection already exists with the required alias. Connect optional Decision Service and collector containers to the same network using aliases decision-service and otel-collector.

Set CatalogService__Hostname=catalog-service:8080 on the Catalog Service container. The example uses its default /Service.svc/core endpoint. Keep the dependency containers on the private network; their HTTP addresses are not browser-facing.

Connect Catalog Manager and any Decision Service to irauthor as well. Set InRule__Catalog__Uri on Catalog Manager and inrule__runtime__service__catalog__catalogserviceuri on Decision Services to http://catalog-service:8080/Service.svc/core. This uses the Catalog Service's container port even if its published host port is different.

⁠Configure sign-in

Configure your identity provider for the irAuthor Web Client. The Web Client handles sign-in, token renewal, and sign-out. Supply its OIDC settings on the Backend as shown below.

Use the same HTTPS issuer for Web Client sign-in and Backend authentication. Include email in both ID and API access tokens, matching the user's active irCatalog account.

The required configuration below uses Auth0. For Microsoft Entra ID, substitute these values:

Set the API registration's api.requestedAccessTokenVersion to 2. Expose the delegated API scope and grant the SPA permission and required consent. Populate the user's email attribute and add email to both token types. Register the Web Client origin as the sign-in, silent callback, and post-logout redirect URI. Omit Webclient__Oidc__AuthorizationParameters__audience for Entra. Configure Catalog trust as described below before verifying access.

⁠Auth0 example

1. Create an API with identifier master_service and signing algorithm RS256. Set Webclient__Oidc__AuthorizationParameters__audience to this identifier. Enable Allow Offline Access for token renewal.

2. Create a Single Page Application. Set its Allowed Callback URLs, Allowed Logout URLs, and Allowed Web Origins to the Web Client's browser address, for example https://192.168.10.20. Enable the Refresh Token grant for renewal. Keep its Client ID for the Backend configuration.

3. Add the user's email to API access tokens with this post-login Action, and add it to the Auth0 login flow:

   exports.onExecutePostLogin = async (event, api) => {
     api.accessToken.setCustomClaim("email", event.user.email);
   };
   

   Copy

⁠Required configuration

Create backend.env with the settings below. Replace the example address and every placeholder with your own values. Use the issuer URL supplied by your identity provider. Use SQL authentication unless the Linux container has Kerberos configuration and a service-account keytab for Integrated Security.

MCP and AI capabilities are not supported in self-hosted installations. Keep the Mcp__* settings below: Mcp__ResourceIdentifier is required for Backend startup, and Mcp__Exposure__AllowedOrigins__* also controls browser access to the authoring APIs. These settings are not instructions to configure MCP clients or register a separate MCP API with the identity provider.

ASPNETCORE_ENVIRONMENT=Production
ASPNETCORE_URLS=http://+:8080
ConnectionStrings__Storage=Server=sqlserver,1433;Initial Catalog=<authoring-database>;User ID=<sql-user>;Password=<sql-password>;Encrypt=True;TrustServerCertificate=False
TenantManagement__Mode=SelfHosted
TenantManagement__Tenants__0__Id=<tenant-guid>
TenantManagement__Tenants__0__Alias=acme
TenantManagement__Tenants__0__Name=Acme Corporation
TenantManagement__Tenants__0__Catalog__Uri=http://catalog-service:8080/Service.svc/core
TenantManagement__Tenants__0__Catalog__ServiceAccountUsername=<catalog-service-account>
TenantManagement__Tenants__0__Catalog__ServiceAccountPassword=<catalog-password>
Identity__Jwt__Authority=<issuer-url>
Identity__Jwt__Audience=master_service
Identity__ApiKey__Key=<system-api-key>
Webclient__Oidc__ClientId=<spa-client-id>
Webclient__Oidc__Scopes=openid profile email offline_access
Webclient__Oidc__AuthorizationParameters__audience=master_service
Mcp__ResourceIdentifier=https://192.168.10.20:8443/mcp
Mcp__Exposure__AllowedOrigins__0=https://192.168.10.20
OpenTelemetry__Enabled=false

Environment variable paths use two underscores between each part. For more tenants, repeat the TenantManagement__Tenants__0__* settings using __1__, __2__, and so on. Tenant IDs must also be unique. Add browser origins as Mcp__Exposure__AllowedOrigins__1, and so on.

Keep credentials out of source control and browser-visible Webclient__* settings. Restrict access to backend.env; use platform-managed secrets for production deployments.

The SQL Server certificate must be valid for sqlserver and trusted by the Backend. Keep Encrypt=True and TrustServerCertificate=False.

⁠Catalog authentication

Configure each Catalog service to trust the identity provider's issuer and API audience. The Backend forwards the signed-in user's API token for Catalog operations; forwarding does not establish that trust. Catalog revisions and checkout ownership identify that user. The service account remains required for membership and permission lookups.

The Catalog installation must support OIDC authentication and reach the provider's HTTPS discovery and signing-key endpoints. Follow the Catalog centralized authentication setup⁠ for your Catalog deployment. For Entra, use the directory-specific v2 issuer and API application client ID shown above.

Leave CatalogCredentialsOverrides:User:Password unset or blank in all effective configuration sources. A nonblank development override selects password authentication instead of the user's token.

⁠Optional configuration

⁠Provider sign-out

Sign-out clears the application session across tabs. Provider sign-out uses its advertised end_session_endpoint; without one, the provider SSO session remains active.

To override discovery, set Webclient__Oidc__EndSessionEndpoint to a standard OIDC logout URL. Auth0 uses https://<tenant>/oidc/logout, not /v2/logout. The URL must be absolute HTTPS without credentials, query, fragment, or whitespace. Omitted or empty values leave discovery unchanged.

⁠Decision Service

Authoring works without a Decision Service. For each tenant that uses one, supply:

Use the corresponding tenant array position for additional tenants.

⁠Telemetry

To export Backend telemetry, set OpenTelemetry__Enabled=true and OpenTelemetry__Otlp__Endpoint=http://otel-collector:4318 for a collector on the shared Docker network. Do not append /v1/.... Treat a collector URL containing a credential as a secret.

⁠Run the container

Run these commands in PowerShell beside backend.env, after preparing the shared Docker network. Enter the Backend image reference for your deployment, including its version tag or digest. Use a compatible Web Client version rather than updating either image independently through latest.

$BackendImage = Read-Host "Backend image reference, including version tag or digest"
docker run -d --name irauthor-backend --network irauthor --env-file .\backend.env -p 127.0.0.1:8080:8080 $BackendImage

Configure the host-local proxy to forward https://192.168.10.20:8443 to http://127.0.0.1:8080. Keep the container's HTTP port bound to loopback. A proxy on another host or in another container needs a separately restricted network path.

⁠Verify the installation

docker logs irauthor-backend
curl.exe --fail http://localhost:8080/health
curl.exe --fail --include https://192.168.10.20:8443/api/config/webclient

/health confirms that the Backend is responding. Complete the sign-in and catalog checks below to verify access.

The configuration request must return HTTP 200 with JSON and Cache-Control: no-store, without requiring sign-in. Confirm that Oidc contains your configured issuer, SPA client ID, scopes, and public provider parameters. Self-hosted output must omit the TMAPI URI, Sumo collector URL, and Pendo agent key.

Start the Web Client and open https://192.168.10.20/acme, replacing acme with your configured tenant alias. Sign in and confirm catalog access. Reaching the login page alone does not verify authenticated access.

If your Backend and Web Client versions provide a tenant picker, you can also select the tenant there.

Create and check in a test rule application. Confirm that Catalog revision history identifies the signed-in user's Catalog account, not the service account. Verify token renewal, logout, and account switching before rollout.

⁠Users and tenant access

Manage users in irCatalog. The email claim in each user's access token must match exactly one active account in that tenant's catalog; the catalog user name is not used for this match. Catalog roles control what the user can read and change. Duplicate active email addresses deny that user access until an administrator fixes the catalog accounts.

User changes do not require a Backend restart. On versions with a tenant picker, it can take up to 30 seconds to reflect a catalog user change with the default cache settings.

⁠Troubleshooting

⁠Configuration changes

When changing variables in backend.env, recreate the container with the updated file. docker restart does not reload an environment file. The same image can be reused; no rebuild is needed.

Back up the authoring database separately from the catalog database. Removing the Backend container does not remove either external database.

⁠Related documentation

See the Catalog Service⁠, Catalog Manager⁠, and Decision Services⁠ pages for those containers.

See InRule documentation⁠ or contact InRule Customer Support for product, licensing, and deployment questions.