Frontend Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, single container deploying all components
• npm run start
• Other (please specify below)

Backend (Jet Stream) Deployment type

• Cloud Foundry Application (cf push)
• Kubernetes, using a helm chart
• Docker, single container deploying all components
• Other (please specify below)

Expected behaviour

When using SSO_WHITELIST, an operator should be able to list approved scheme + host + port, and users will be transparently redirected to the appropriate host.

Actual behaviour

When using SSO_WHITELIST, every possible landing point or bookmark needs to included or the user ends up with,

{"error":"SSO Login: Disallowed redirect state"}

Steps to reproduce the behavior

Configure Stratos with SSO_WHITELIST set to https://hostname/. Try to then visit, say, https://hostname/applications or, https://hostname/cloud-foundry/2oBn9LBurIXUNpfmtZCQTCHnxUM/summary

Context

When using Stratos with an IdP it's vital that we not have an external redirect, so we want to redirect back only to the Stratos host itself (or one of its CNAMEs).

We have to have close this external redirect (it's a regression for us) and we can't use the current implementation as visiting any page as an unauthenticated user except, say, / or /home, will result in an error.

More details on why external redirects are bad is available from OWASP

Possible Implementation

The current implementation at https://github.com/cloudfoundry/stratos/blob/3.1.0/src/jetstream/authuaa.go#L543-L559 uses the compareURL at https://github.com/cloudfoundry/stratos/blob/3.1.0/src/jetstream/stringutils/utils.go#L44, but that does path comparison.

I think any reasonable operator will only care about scheme + hostname + port, and not the paths (as already documented at https://github.com/cloudfoundry/stratos/blob/master/docs/sso.md#adding-a-stratos-sso-state-whitelist)

So I think changing the implementation to stop caring about path would be fine, but if folks are using this in production already with SSO_WHITELIST, then perhaps allow the use of a wildcard in the specification. E.g.

SSO_WHITELIST=https://your.domain/*,https://your.other.domain/*

See also #3718