RscCentral.Catalog.Lib 0.2.0

Resource Central catalog library

A set of functions that help integrate a catalog app into Resource Central.

Published to NuGet as RscCentral.Catalog.Lib.

Releasing

Releases are cut by pushing a tag of the form catalog-lib-vX.Y.Z to the rsc-central repository. The .github/workflows/publish-catalog-lib.yml workflow then builds catalog-lib/catalog-lib.csproj, packs it with the version derived from the tag (the catalog-lib-v prefix is stripped), and pushes the resulting .nupkg to nuget.org using the NUGET_API_KEY secret.

Example:

git tag catalog-lib-v0.1.0
git push origin catalog-lib-v0.1.0

The tag prefix is required so this workflow doesn't fire on tags used by other publishing workflows in this repo.

Bundled dependencies

The published package is self-contained: the sibling rsc-central libraries it depends on (lib, auth-lib, auth-api-lib, openapi-lib) are embedded as assemblies inside the .nupkg rather than declared as NuGet package dependencies. Consumers therefore get the public types from those libraries (e.g. RscCentral.Auth.Api.Lib.CustomClaimsPrincipal, RscCentral.Lib.OpenApi) without needing to install anything else.

This is implemented in catalog-lib.csproj via PrivateAssets="all" on the ProjectReference entries plus the CopyProjectReferencesToPackage target. If any of those sibling libraries are later published to NuGet in their own right, this bundling should be removed to avoid duplicate-assembly conflicts in downstream consumers.

Accepting delegated credentials

Data Central can be switched, per catalog version, from forwarding the caller's own credential to minting a short-lived token targeting this catalog. A catalog has to opt in on its side first, by naming its own audience:

builder.Services
    .AddCatalogAuthService(builder.Configuration)
    .AddOpenApiCatalogServices(builder.Configuration)
    .AddCatalogAuthentication(builder.Configuration, builder.Environment.IsDevelopment());

AddCatalogAuthentication replaces a direct call to AddResourceCentralAuthentication. It reads Catalog:Tag from configuration, derives the audience catalog/<tag>, and turns on audience validation -- so a token minted for a different catalog is refused here even though the same auth-server signed it. It throws at startup if Catalog:Tag is missing, rather than quietly accepting any audience.

Nothing else changes. The token still carries the caller as its sub, so log lines and authorization decisions are unaffected, and ICatalogAuthService needs no changes -- the capabilities arrive narrowed to this catalog's own subtree, which is the only part of them this catalog ever asks about.

Two things to know before switching a catalog over in the admin UI:

• This version is not a prerequisite for switching, only for the audience check. A catalog running an older catalog-lib does not validate the audience, so it accepts a delegated token as readily as a forwarded one -- meaning the caller's API key stops reaching it either way. What this version adds is the refusal: without it, a token minted for one catalog would also be accepted by another.
• A caller holding an ancestor capability sees it narrowed, whatever version is deployed. catalog:read arrives as catalog/<tag>:read, because minting narrows capabilities to this catalog's own subtree. ICatalogAuthService handles that; a catalog that checks for the literal ancestor string itself will stop matching, so check catalog/<tag>/... paths instead. This is the one thing worth verifying in a catalog's own code before switching it.

Contents

• RscCentral.Catalog.Lib — CatalogOptions, CatalogUtils, ServiceExtensions.AddCatalogAuthService, ServiceExtensions.AddCatalogAuthentication
• RscCentral.Catalog.Lib.Services — ICatalogAuthService / CatalogAuthService
• RscCentral.Catalog.Lib.Validation — CatalogTagAttribute, CatalogVersionAttribute
• RscCentral.Catalog.Lib.OpenApi — AddOpenApiCatalogServices, AddCatalogOpenApi, MapCatalogRoot