RscCentral.Service.Lib 0.2.0

Resource Central service library

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

Published to NuGet as RscCentral.Service.Lib.

Releasing

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

Example:

git tag service-lib-v0.1.0
git push origin service-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 service-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

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

builder.Services
    .AddServiceAuthService(builder.Configuration)
    .AddOpenApiServiceServices(builder.Configuration)
    .AddServiceAuthentication(builder.Configuration, builder.Environment.IsDevelopment());

AddServiceAuthentication replaces a direct call to AddResourceCentralAuthentication. It reads Service:Tag from configuration, derives the audience service/<tag>, and turns on audience validation -- so a token minted for a different service is refused here even though the same auth-server signed it. It throws at startup if Service: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 IServiceAuthService needs no changes -- the capabilities arrive narrowed to this service's own subtree, which is the only part of them this service ever asks about.

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

• This version is not a prerequisite for switching, only for the audience check. A service running an older service-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 service would also be accepted by another.
• A caller holding an ancestor capability sees it narrowed, whatever version is deployed. service:read arrives as service/<tag>:read, because minting narrows capabilities to this service's own subtree. IServiceAuthService handles that; a service that checks for the literal ancestor string itself will stop matching, so check service/<tag>/... paths instead. This is the one thing worth verifying in a service's own code before switching it.

Contents

• RscCentral.Service.Lib — ServiceOptions, ServiceUtils, ServiceExtensions.AddServiceAuthService, ServiceExtensions.AddServiceAuthentication
• RscCentral.Service.Lib.Services — IServiceAuthService / ServiceAuthService
• RscCentral.Service.Lib.Validation — ServiceTagAttribute, ServiceVersionAttribute
• RscCentral.Service.Lib.OpenApi — AddOpenApiServiceServices, AddServiceOpenApi, MapServiceRoot