Add in-response-to field to saml successful response#137599
Conversation
|
Pinging @elastic/es-security (Team:Security) |
|
Hi @piotrsulkowski-elastic, I've created a changelog YAML for you. |
|
Hi @piotrsulkowski-elastic, I've updated the changelog YAML for you. |
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for returning the in-response-to field in SAML successful authentication responses, making this information available to clients for correlation purposes.
Key changes:
- Added
inResponseTofield toSamlAttributesclass to capture and propagate the SAML response correlation ID - Updated token metadata creation to include the
in-response-tovalue when present - Enhanced test coverage to verify the new field is properly returned in authentication results
Reviewed Changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| SamlAttributes.java | Added inResponseTo field with getter method and updated constructor/toString |
| SamlAuthenticator.java | Modified to extract and pass inResponseTo from SAML response to SamlAttributes |
| SamlRealm.java | Added constant TOKEN_METADATA_IN_RESPONSE_TO and updated createTokenMetadata to include the field |
| TransportSamlInvalidateSessionAction.java | Updated createTokenMetadata call to pass null for inResponseTo |
| TransportSamlLogoutActionTests.java | Updated test to pass null for new inResponseTo parameter |
| TransportSamlInvalidateSessionActionTests.java | Updated test to pass null for new inResponseTo parameter |
| SamlRealmTests.java | Added test assertions to verify inResponseTo is returned in token metadata |
| SamlAttributesTests.java | Updated test to include inResponseTo in assertions |
| 137599.yaml | Added changelog entry for the enhancement |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
3fc5fb5 to
3a0316c
Compare
jfreden
left a comment
There was a problem hiding this comment.
Great job on this PR!
I think you're missing a changelog since this is an >enhancement, maybe the autogenerated one was overwritten during a force-push?
Optional: You might want to add a REST test that verifies that the metadata field indeed makes it all the way to the client. I haven't found a great place to add that but maybe by adding a test to SamlServiceProviderMetadataIT that test is more for testing unreliable metadata but it has all the components. WDYT?
7d96928 to
eb89101
Compare
|
Hi @piotrsulkowski-elastic, I've created a changelog YAML for you. |
f8ae8fe to
9e93cd8
Compare
b5c786a to
9c461f9
Compare
jfreden
left a comment
There was a problem hiding this comment.
Great job! I have a couple of minor comments.
|
|
||
| // Constructor used in Serverless | ||
| public SamlAuthenticateResponse(Authentication authentication, String tokenString, String refreshToken, TimeValue expiresIn) { | ||
| this(authentication, tokenString, refreshToken, expiresIn, /* inResponseTo= */ null); |
There was a problem hiding this comment.
nit: I don't think the /* inResponseTo= */ is needed here.
| String tokenString, | ||
| String refreshToken, | ||
| TimeValue expiresIn, | ||
| String inResponseTo |
| out.writeString(refreshToken); | ||
| out.writeTimeValue(expiresIn); | ||
| authentication.writeTo(out); | ||
| out.writeString(inResponseTo); |
There was a problem hiding this comment.
I was kind surprised by not finding a corresponding StreamInput constructor and found some information about it here: #107666 (comment)
This is dead code per my understanding, the only scenario is if we send this to an old node and don't expect a response:
That argument isn't totally watertight, there could be situations where we're required to send a particular kind of message (e.g. a response to an older remote node) but will never receive such a message (e.g. because we never make the corresponding request).
If that's the only potential use case (which we probably don't support for SamlAuthenticationResponse) we shouldn't add to it, since the remote node wouldn't know how to parse it.
There was a problem hiding this comment.
The reason we don't need transport serialization for SamlAuthenticationResponse is because we're using a NodeClient in RestSamlAuthenticateAction that will be executed on the local node (so not sent over the wire).
| } | ||
|
|
||
| public Map<String, Object> createTokenMetadata(SamlNameId nameId, String session) { | ||
| public Map<String, Object> createTokenMetadata(SamlNameId nameId, String session, String inResponseTo) { |
There was a problem hiding this comment.
nit: nameId and inResponseTo are @Nullable
| String requestId = generateRandomRequestId(); | ||
| var response = authUser(username, requestId, requestId); | ||
| assertThat(response, hasKey("access_token")); | ||
| assertThat(response, hasKey("in_response_to")); |
There was a problem hiding this comment.
Nice to be able to extend this! 👍
Return in-response-to field in all successful authentication attempts, as this information is useful to the client part of elastic#128179
9aa9604 to
6a1e254
Compare
Return in-response-to field in all successful authentication attempts, as this information is useful to the client
fixes #128179