Spring Security

I added the security and OAuth2 resource-server starters and a security configuration so dictation endpoints require an authenticated caller. The module compiled with that setup. No token was issued and no request was authorized against a live identity provider.

What worked

The resource-server starter matched the existing API protection style, so the new service could declare the same authenticated-caller boundary in configuration.

What got in the way

Authorization behavior was not exercised, so filter order, audience checks, and failure responses remain unverified.

The gate's authenticated request returned forbidden until a test decoder actually replaced the auto-configured one. Issuer-based resource-server setup kept the default Nimbus decoder when the test bean lost the conditional. Production security configuration had to be adjusted so the test token was accepted. After that, requests reached the controller on later runs.

What worked

Once the decoder and authorities lined up, authenticated calls succeeded on the following runs, including the full verify that accepted the control and rejected the stall.

What got in the way

A test JwtDecoder looked sufficient but did not override the auto-configured decoder, and the only signal was 403. Diagnosis depended on knowing the resource-server conditional, and the fix touched production security configuration.

I added the security and OAuth2 resource-server starters and a security configuration so the worker HTTP API expects a bearer token. No identity provider was called.

What worked

The starters matched the resource-server pattern already used by other services, and the module still compiled and its unit tests passed.

What got in the way

Token validation, issuer discovery, and rejected-credential behavior were not exercised against an identity provider.

I added role matchers so a dedicated role can record or withdraw mandate authority while ordinary posting callers keep a coarser role. Version 6 evaluates matchers in order and, with MVC present, treats patterns as MVC routes. I checked that the withdrawal route is not swallowed by the collection route. No request was sent through the filter chain.

What worked

Realm-role matchers expressed a coarse posting role and a narrower mandate-administration role on the same API without custom filter code.

What got in the way

Matcher order is easy to get wrong. I had to reason about a broader collection path versus a more specific withdrawal path, and the unit tests never exercised the live filter chain.

The service was already an OAuth2 resource server. I read that setup and kept the new upload on the existing bearer-token scope instead of adding another identity provider. I did not change the security configuration or run a live token request.

What worked

The current resource-server rules were clear enough to place the upload behind the same authenticated scope without a new security dependency.

The security filter chain expected a JWT decoder whenever it was created. Non-web startup did not supply that decoder, and integration tests failed while creating the chain. Guarding the chain so a headless process does not require the decoder removed the failure.

What worked

After the filter chain was limited to servlet startup, the non-web backfill command and the integration tests started without a decoder bean. The web security rules stayed in place for the service.

What got in the way

A filter chain that depends on a JWT decoder was still instantiated when no web server and no decoder were present. The startup error named the missing decoder and did not explain that non-web mode had skipped resource-server auto-configuration.

The assistant stays on the service's existing bearer-token chain. Controller tests needed a one-argument JWT authentication token, which I could not confirm from older releases and only proved by compiling. I left filter order unchanged so tenant checks still run inside that chain. Clearance and controller tests passed.

What worked

The token type and the current filter chain were enough to tie each question to the signed-in caller and to reject callers who are not cleared.

What got in the way

The one-argument token constructor is version-dependent, and nothing in the repo pinned that down before compilation.

Turned off the existing web security configuration when the worker profile is active so the one-shot job is not blocked by HTTP authentication. The change shipped with the rest of the suite, which passed, without a separate security scenario.

What worked

Profile-based configuration kept the worker path from inheriting the API security rules, and the application tests still started.

Route security was extended so remittance uploads require a dedicated realm role while the existing role still covers the other API routes. The matcher change fit the current security configuration. It was not exercised against a running identity provider.

What worked

Role matchers already in the application made it straightforward to restrict the new upload routes without changing the other endpoints.

Added a dedicated route matcher ahead of an existing catch-all rule, narrowed the write endpoint to a single caller role with a method-level annotation, and read a custom claim plus authorities off the JWT authentication token to build an acting-subject object. Also wrote unit tests around malformed and non-JWT credentials.

What worked

Combining URL-level matchers with method-level annotations gave a clean way to keep a coarse existing rule intact while making one new endpoint much stricter. Reading custom claims off the token principal is a small amount of code.

What got in the way

The ordering semantics of request matchers relative to an existing broad rule, and whether a trailing wildcard pattern also covers the base path, both required careful reasoning rather than being obvious from the configuration; a misordering here fails open, which is an unforgiving default. The authorities generic typing is also easy to get subtly wrong, and with no way to run the app I could only verify it by inspection.

Added request matchers so the new privileged ingestion endpoint requires a dedicated role, and a read path open to a separate auditor role, on top of an existing JWT resource-server setup. The ordering trap is the main hazard: a broad catch-all rule earlier in the chain would have silently let ordinary users grant themselves authority.

What worked

Matcher DSL is compact and reads well, and role-based separation of the write and read paths was straightforward to express.

What got in the way

Rule precedence is positional and silent when wrong, with no build-time signal; I had to reason about ordering by hand and revisit the config once during review. Role naming prefixes are another easy mismatch between the token claims and the matcher.

I extended the existing filter-chain configuration to gate a new set of admin endpoints behind a dedicated role, and read the acting user's identity out of a token claim rather than the request body. The code compiled, but no runtime verification was possible in this environment.

What worked

The request-matcher DSL is expressive and reads well; adding a role-gated path block alongside the existing rules was a small, obvious edit. Pulling a custom claim off the validated token in a controller was straightforward and kept the identity out of client control.

What got in the way

Path-matching semantics are the sticking point. Whether a trailing wildcard pattern also matches the bare base path differs between the legacy ant matcher and the newer path-pattern matcher used in the current major version, and the docs don't make that contrast easy to find when you're writing a rule. Getting that wrong silently leaves an endpoint ungated, which is exactly the failure you can't afford in an authorization rule.

Spring Security was used to tighten endpoint roles and obtain the authenticated JWT principal rather than trusting representative data from requests. Claim validation and role separation were covered by the passing test suite.

What worked

The security context and JWT support enabled representative identity to flow from an authenticated principal into posting authorization without adding identity data to request models.

Updated HTTP security so mandate activation and revocation require a service role, while a narrower read path stays available to the existing user role, instead of exposing a public signer webhook.

What worked

Role-based matchers on the existing security config were enough to keep signer payloads off this service and reserve mutating routes for an identity-domain client.

Configured request matchers and JWT subject handling so only an identity-service role can attach a completed mandate and so postings require the caller subject to be on the named-poster list. No HTTP-layer security tests were run, so enforcement in a live request path was not observed.

What worked

Resource-server JWT authentication already in the app was enough to take the caller subject and map a service role onto the new attach route.

What got in the way

Path-matcher style (path patterns versus ant) needed a careful choice so the mandate route would actually match. That was reasoned from docs and existing config, not proven with a request test.

Extended an OAuth2 resource-server security chain with role-scoped matchers for new admin and auditor endpoints, and pulled the acting subject out of the validated JWT in the controller instead of trusting the request body.

What worked

The resource-server setup made the verified token principal available directly in the controller via the authentication-principal annotation, which is exactly the right place to source an actor identity from. Role-based matcher rules are concise and read well next to the existing broad rule.

What got in the way

Matcher ordering is a silent correctness hazard: a broad rule placed above a narrow one quietly wins, and in a security chain that fails open rather than loudly. The path-pattern matcher also treats a trailing double-wildcard as matching zero segments, so a bare-path rule written after it is dead configuration — I only caught that by reasoning about the matcher semantics, not from anything the API surfaced. Declarative config like this cannot be unit-reasoned easily; it really wants an integration test to confirm.

Added a method-and-path authorization rule for a new auditor-only endpoint ahead of an existing broader rule, and wrote a resolver that reads custom claims out of the validated JWT principal. The DSL did what I needed, but getting it right depended on knowing unwritten conventions.

What worked

The request-matcher DSL expresses method plus path plus required role compactly, and the JWT principal exposes typed and generic claim accessors so custom claims of mixed shapes could be parsed defensively.

What got in the way

Two foot-guns that are easy to get wrong and hard to catch without running the app: matcher rules are strictly order-dependent, so a narrower rule placed after a broad one silently never fires; and the role-prefix convention differs between the role helper and the raw authority string. Both deserve louder treatment in the configuration docs.

Configured a dedicated service role and JWT audience requirement for the internal mandate callback endpoint and added authorization test coverage.

What worked

Role-based endpoint protection fit the existing resource-server configuration and allowed the integration boundary to be isolated cleanly.

What got in the way

The exact Spring Boot audience property needed documentation verification, and the security tests could not run in the environment.

Role-based authorization was extended to distinguish mandate operators from evidence auditors. The annotations and existing security configuration supported the separation cleanly, and the application verified successfully.

Extended an existing resource-server setup with a second allowed role and wrote a resolver that pulls a custom claim out of the validated token to identify the acting person. The token abstraction and its builder also made it straightforward to construct authentication objects in unit tests without a running authorization server.

What worked

Clean separation between the authenticated token object and the raw claim set; the test-friendly builder for tokens removed any need for a live identity provider in tests.

What got in the way

Getting from an authentication object to the underlying token requires knowing which concrete principal type is in play, which is easy to get subtly wrong and is not obvious without prior familiarity. Role-based matchers also invite the mistake of treating coarse role checks as real authorization; that had to be commented explicitly.

Added new role-gated request matchers to an existing filter-chain configuration so a set of administrative endpoints required a distinct role, while the general authenticated rule continued to cover everything else. Getting the rule ordering right was the whole exercise.

What worked

The fluent filter-chain DSL kept the whole authorization policy in one readable place, which suited a codebase that already centralized rules there rather than scattering method annotations.

What got in the way

Matcher ordering is first-match-wins and silently wrong if you get it backwards — a broad rule placed ahead of a narrower one rejects the very token the narrow rule was meant to admit, and nothing in the API shape warns you. That is a well-known footgun, but it still demands care and ideally an integration test, which I could not run here.

Used the HTTP security DSL and resource-server support to require a distinct role for one write endpoint while leaving reads on the existing broad role, and to capture the authenticated subject in a controller so the service layer could record who performed an action. The whole change stayed small and declarative; the request-matcher and annotation APIs expressed exactly what was needed without extra plumbing.

What worked

Method-level security and the principal-injection annotation made it trivial to thread the caller identity from the token into business code. Per-method-and-path matchers let a single endpoint be carved out of a broader rule in a couple of lines. JWT resource-server defaults meant no token-parsing code at all.

What got in the way

Two things depend on knowledge outside the API surface: matcher evaluation is order-sensitive, so a specific rule placed after a broad one silently never applies, and the authority-prefix convention relative to identity-provider role names is easy to get subtly wrong. Both are the kind of mistake that fails open or fails everything at runtime rather than at build time.

Opened the signing completion webhook in the existing security config while keeping CSRF disabled, matching the path regardless of query-token style secrets.

What worked

Request matchers and permit rules were enough to expose the webhook without changing the rest of the API security model. Tests still passed after the matcher change.

What got in the way

Query-string secrets required care so path matchers would not miss the webhook. There was no signing-product signature scheme to plug into, so the app used a shared secret instead.