Issue Summary

When someone visits a Private page with SSO configured, they are redirected to the identity provider to login. If the identity provider determines that this user should not have access to Statuspage, it is possible that the identity provider will send a "deny claim" (or "no permit claim") and send a SAML response with a StatusCode of "RequestDenied" and Statuspage should display an appropriate error.

We have only seen a customer using ADFS report this behavior so far, and have not been able to reproduce with something like Okta. It seems that most identity providers would block the access request inside the provider itself and put up a message there saying they do not have access. But ADFS may be sending back an empty request, with a RequestDenied, and we are sending that request back to ADFS in an endless loop.

Steps to Reproduce

(Support does not have an ADFS server to test against, so this may be incomplete)

1. Configure a Private Statuspage connected to ADFS for authentication
2. Create a user in ADFS, but make sure that user does not have access to the private Statuspage
3. In an incognito window, visit your private page URL
4. Observe that you are redirected to ADFS for authentication
5. Login with the user that does not have Statuspage access

Expected Results

Customer states that ADFS will send a "status:RequestDenied" response, which Statuspage should interpret as a denial and put up our own error message saying the user does not have access.
(Parker Editorial Note: My expectation would be that this responsibility lies in the ADFS side - detect this user does not have access to the requested application, and put up the error in ADFS denying access, which is what Okta does. It seems odd to even bother sending back a SAML response telling us to deny the user, but it is a valid status in the DNS spec (page 41, line 1672: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf )

Actual Results

A SAML response is sent from ADFS to our consume endpoint, which is empty aside from the RequestDenied status. We then route the request back to ADFS because it is missing an assertion with a NameID or email. ADFS then sends the same response back to us since that user is already authenticated to ADFS, and it gets caught in an endless loop.

The request is that we gracefully handle the "RequestDenied" status and put up an error message for the visitor, instead of routing back to the identity provider.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available