Tags: cloudfoundry/uaa
Tags
build(deps): bump com.google.guava:guava from 33.7.0-jre to 33.7.1-jr… …e in the guava group (#4046) * build(deps): bump com.google.guava:guava in the guava group Bumps the guava group with 1 update: [com.google.guava:guava](https://github.com/google/guava). Updates `com.google.guava:guava` from 33.7.0-jre to 33.7.1-jre - [Release notes](https://github.com/google/guava/releases) - [Commits](https://github.com/google/guava/commits) --- updated-dependencies: - dependency-name: com.google.guava:guava dependency-version: 33.7.1-jre dependency-type: direct:production update-type: version-update:semver-patch dependency-group: guava ... Signed-off-by: dependabot[bot] <support@github.com> * Update libs.versions.toml --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Markus Strehle <11627201+strehle@users.noreply.github.com>
Fix remote address extraction in audit event origin string (#3992) * Fix remote address extraction in audit event origin string The audit event origin builder cast Authentication.getDetails() to String unconditionally to parse a remoteAddress out of a JSON blob. When details was not a String — a common case for UaaAuthenticationDetails and OAuth2AuthenticationDetails, which expose the remote address directly — the cast raised ClassCastException, which the broad catch swallowed by appending the raw Object.toString() to the audit log. This leaked internal state (map contents, request parameters, token fragments, session markers) into the log line and made the origin's shape depend on which details type happened to be attached to the Authentication. For example, an OAuth2AuthenticationDetails instance would have its full toString appended, producing a log line like: Audit: GroupModifiedEvent ('{"role_collection":"evenRC1771046947","op":"add_saml_attribute","saml_entity":"iot-idp-1771046947","attribute":"Groups","value":"even"}'): principal=evenRC1771046947, origin=[client=admin, details=(remoteAddress=172.18.0.1, sessionId=<SESSION>, tokenType=Bearer, tokenValue=<TOKEN>, sub=admin, iss=http://localhost:8080/uaa/oauth/token)], identityZoneId=[uaa] where the remoteAddress/sessionId/tokenType/tokenValue fragment came from the details object's toString, then sub/iss were appended by the token inspector — a shape that mixed two unrelated sources into one line. Replace the cast-and-catch with a pattern-matching switch that reads the remote address from each known details type: UaaAuthenticationDetails, OAuth2AuthenticationDetails, a Map (used by ResourceOwnerPasswordTokenGranter — currently has no remoteAddress key, but supported for forward compatibility), or a String parsed as JSON. Non-JSON strings, maps without a remoteAddress key, and null-valued fields fall through safely. Details types without a known accessor produce no remoteAddress line rather than dumping their contents. Add unit tests in AbstractUaaEventTest for each supported details type, for the non-JSON String and null-remoteAddress regression cases, for the Map paths (with and without a remoteAddress key), and for the client+user origin shape. Update AuditCheckMockMvcTests to reflect that audit origins no longer carry the sessionId=<SESSION> marker: the marker was only ever emitted via the buggy toString-leak path, carried no information (its value was a hardcoded literal), and disappears now that the leak is fixed. Drop the sessionId=<SESSION> assertions and collapse the assertLogMessageWithSession / assertLogMessageWithoutSession helpers, which are now equivalent, into a single assertLogMessage helper. * simplify * handle WebAuthenticationDetails * Restore sessionId absence assertion in audit log helpers * Stop including session identifier in audit log origin for authentication events Replace details.toString() in AbstractUaaAuthenticationEvent.getOrigin() with an explicit implementation that emits only remoteAddress and clientId, so the session identifier is no longer included even in masked form. * Filter blank remoteAddress values in extractRemoteAddress
Fix for Issue #3650 (#3894) * Fix for Issue #3650 Problem: When a SAML IDP's metadata endpoint is unreachable, the ConfiguratorRelyingPartyRegistrationRepository catches the exception, returns null, and the DelegatingRelyingPartyRegistrationRepository falls through to the DefaultRelyingPartyRegistrationRepository which returns a stub registration pointing to https://www.cloudfoundry.org. The user gets redirected there with all SAML request parameters — confusing UX and a data leak. * review
PreviousNext
