Run the security filters on every dispatch type

[vharseko]

Two hardenings around RequestDispatcher forwards, following up on #1128 ("a RequestDispatcher … does not run the web.xml filters").

Security filters on every dispatch type

Per the Servlet spec a <filter-mapping> that names no <dispatcher> applies to REQUEST only: a RequestDispatcher forward or include, an AsyncContext.dispatch or an <error-page> dispatch reaches the servlet with the filter skipped, and naming any type replaces that default. The four narrowly mapped security filters now declare all five types: AuthNFilter and AuthZFilter on /ws/*, JAXRPCRequestFilter on /jaxrpc/*, NotificationsWebSocketFilter on /notifications. No forward or include in the tree targets these roots (the /ws matches are /wsfederation/jsp/*, outside /ws/*), so nothing legitimate changes.

SecurityFilterDispatchersTest (new, openam-server-only) parses the shipped web.xml and fails if any mapping of those filters loses a type — a security filter added with the default dispatch set will not pass silently.

JAXRPCRequestFilter binds the request in a ThreadLocal; mapped for FORWARD/INCLUDE it can re-enter on a nested dispatch, so it restores the previous binding on exit instead of remove() (nestedDispatchRestoresTheOuterRequestOnExit).

Left as they are: the /*-mapped filters (amSetupFilter, SecurityHeaders, AuditContextFilter, ResponseValidationFilter) and FQDNValidationFilter (/XUI/*, /oauth2/authorize). Running those on every internal forward changes behaviour product-wide (double auditing, FQDN redirects on internal dispatch) and is a separate change.

Container-mapped forward target (java/unvalidated-url-forward #196)

FSUtils.forwardRequest passed the raw request-derived path to getRequestDispatcher once ForwardPathValidator.isSafeForwardPath had accepted it. It now dispatches ForwardPathValidator.forwardTarget(path): the form the container maps — path parameters stripped, percent-escapes decoded once, + literal, the query string as given — or answers 400 when there is none. For every path the validator accepts this maps to the same resource (Tomcat strips, decodes and normalises the dispatcher path itself; the trailing slash is kept, // and /./ are left to the container). One addition beyond isSafeForwardPath: a WEB-INF segment anywhere in the decoded path is refused, not only at the root — no in-app path of the product carries one. .. is still judged per segment, so /a/b..c/d stays an ordinary name as #1128 pinned it.

The decoded form is built and re-checked in the shape CodeQL's UrlForward barriers recognise (URLDecoder until no % remains, a .. check preceded by a WEB-INF check on the same value, the query appended after a constant ?); the validator itself was opaque to the query, which is why #196 stayed open after #1128 while #197/#198 closed. Whether the scan closes it is for this PR's CodeQL run to show; the behaviour is pinned by ForwardPathValidatorTest (14 forwardTargets rows, every unsafeForwardPaths row → null, 4 WEB-INF-below-root rows) and FSUtilsForwardPathTest.dispatchesTheFormTheContainerMaps either way.

Verification

openam-core 2131 tests, openam-federation-library 249 tests, 0 failures (mvn -o test). SecurityFilterDispatchersTest 4/4, run standalone against the module's web.xml (the war module's surefire run needs the full reactor — CI). Every new test was watched failing first: the four web.xml rows with found [[]], the nested-dispatch test with expected [outer] but found [null], the forwardTarget rows on the missing method, the dispatch-form test on the raw path.