LG-13937 Validate secret token for socure DocV webhook

[theabrad]

🎫 Ticket

LG-13937

🛠 Summary of changes

Socure has the ability to send a secret token with the webhook. We want to validate that secret whenever the webhook is used.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• Add a secret to the webhook on the Socure dashboard
• Add the secret token to IdentityConfig
• Point the webhook to the URL of the review app or dev once merged.
• Verify that it returns a 200

[mitchellhenke]

Suggested change

	authorization_header == IdentityConfig.store.socure_webhook_secret_key
	ActiveSupport::SecurityUtils.secure_compare(
	authorization_header,
	IdentityConfig.store.socure_webhook_secret_key,
	)

[zachmargolis]

Should we make the config an array so we can smoothly support a transition between an old & new key?

[amirbey]

i think @zachmargolis makes a great point here ☝🏿

[aduth]

Will we be doing more validation in the future? Should we start doing form validation pattern?

Suggested change

	if token_valid?
	render json: { message: 'Secret token is valid.' }
	else
	render status: :unauthorized, json: { message: 'Invalid secret token.' }
	end
	form = SocureWebhookValidationForm.new
	result = form.submit(headers: request.headers)
	if result.success?
	render json: { message: 'Secret token is valid.' }
	else
	render status: :unauthorized, json: { message: result.first_error_message }
	end

[jmax-gsa]

I don't think we will be; my understanding is that we'll use the webhook just for status updates on submitted requests, and the secret token is just an anti-ddos measure.

Certainly, if we do end up using information from the webhook, then we should follow the form validation pattern we already have.

[solipet]

Agreed, the actual PII data from Socure will be acquired through a separate API call to them.

[jmax-gsa]

LGTM

[solipet]

Tested against the review app, and in the solipet env.

[solipet]

Agreed, the actual PII data from Socure will be acquired through a separate API call to them.