SSPR appears to hang after changes are made to https header

  • 7018830
  • 25-Apr-2017
  • 25-Apr-2017

Environment

Self Service Password Reset
SSPR 4.1 
Security > Web Security > Required HTTP Headers

Situation

SSPR seems to hang after a change is made to required HTTPS headers. 
Browser will not connect to SSPR after setting required HTTPS header. 
After changing and saving Required HTTP Headers, scroll bar goes back and forth with message: "save complete, restarting application"
Changes to required header are saved but browser will not reconnect to SSPR. 
"Access security violation" received after restarting browser.

Resolution

This is working as expected.  SSPR is not hung, the browser just can't reattach to the SSPR server after the restart.   The browser won't reconnect because it is not using the newly-set required HTTPS headers.

Set matching security headers on the upstream upstream gateway, proxy or web server and make sure the browser uses that upstream gateway, proxy or web-server.   Alternatively, manually remove the new required HTTPS header settings from SSPRconfiguration.xml or, if the SSPR server is on a virtual device, revert to a known working snapshot.

Cause

Browser is not using newly required settings.

Additional Information

The purpose for the "Required HTTP Headers" setting is to specify what SSPR can receive, not what SSPR can send. If the environment includes a NAM server or other upstream gateway/proxy server, and you want to force users to use only that gateway to access SSPR, you can set a required header in the SSPR config. After that, only requests that go through that upstream service will work with SSPR. Of course, the same header on the upstream gateway/proxy would also need to be set.  

The setting ' Security > Web Security > Required HTTP Headers' specifies HTTP headers that are required for incoming connections.  An upstream gateway/proxy/web server would have to include these headers in order to get SSPR to respond.  This prevents browsers from bypassing that upstream gateway.  SSPR will not would append these headers to its own responses.

SSPR is hard coded to set common headers. "Content Security Policy," "X-Content-Type," and "Xss-Protection" headers and a few others are already set by SSPR without anything being added in "Required HTTP Headers." 

SSPR will not set the "Strict Transport Security" header. This should be set by an upstream webserver or proxy.

SSPR has a setting for the "Content Security Policy" header in
Settings ⇨ Security ⇨ Web Security.  We strongly recommend that this setting not be modifyied from the default.  In SSPR 4.0 the default was blank, but in SSPR 4.1 this setting contains a rather complex value with which SSPR is tested.