doc updates to include new fields for SAML sig validation #29195
+16
−1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
hashicorp-contributed-pr
|
CI Results: |
…t-SAML-signature-validation
fairclothjm
reviewed
Dec 16, 2024
fairclothjm
previously approved these changes
Dec 16, 2024
yhyakuna
reviewed
Dec 17, 2024
| @@ -51,6 +51,15 @@ Configures the auth method with a SAML identity provider. | |||
| according to the current logging level. When `verbose_logging` is `true`, | |||
| debug-level logs provide user attributes and trace-level logs provide the full | |||
| SAML response. | |||
| - `validate_response_and_assertion_signatures` `(bool, false)` - Enables validation | |||
| of signatures for both response and assertion in the SAML response. If IDP allows | |||
| signing both response and assertion then **recommendation** is to opt for this option. | |||
There was a problem hiding this comment.
Is the recommendation is to opt in?
Suggested change
| signing both response and assertion then **recommendation** is to opt for this option. | |
| signing both response and assertion, then **recommendation** is to opt in for this option. |
There was a problem hiding this comment.
removed the validate_response_and_assertion_signatures option
yhyakuna
reviewed
Dec 17, 2024
| signing both response and assertion then **recommendation** is to opt for this option. | ||
| - `validate_response_signature` `(bool, false)` - Enables validation of signature | ||
| for at least response in the SAML response. If IDP allows signing both response | ||
| and assertion then recommendation is to opt for validating signatures of both. |
There was a problem hiding this comment.
Same question. Should this be opt in?
Suggested change
| and assertion then recommendation is to opt for validating signatures of both. | |
| and assertion, then recommendation is to opt in for validating signatures of both. |
yhyakuna
reviewed
Dec 17, 2024
| and assertion then recommendation is to opt for validating signatures of both. | ||
| - `validate_assertion_signature` `(bool, false)` - Enables validation of signature | ||
| for at least assertion in the SAML response. If IDP allows signing both response | ||
| and assertion then recommendation is to opt for validating signatures of both. |
There was a problem hiding this comment.
Same question. Should this be opt in?
Suggested change
| and assertion then recommendation is to opt for validating signatures of both. | |
| and assertion, then recommendation is to opt in for validating signatures of both. |
…t-SAML-signature-validation
|
Build Results: |
fairclothjm
approved these changes
Jan 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Updating docs for incoming SAML changes in PR for new options for strict SAML validation.
TODO only if you're a HashiCorp employee
backport/label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x, but older release branches will bebackport/ent/x.x.x+ent.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.