Path based vs sub domain based routing

[vedantthapa]

In order to expose a deployment in an ephemeral environment, we can use istio virtual service with either path based routing i.e, /prod endpoint pointing to prod instance and /ephemeral/pr-123 pointing to an ephemeral instance that is created off of a PR OR sub-domain based routing i.e, prod.hopic-sdpac.phac-aspc.alpha.canada.ca pointing to prod instance and *.dev.hopic-sdpac.phac-aspc.alpha.canada.ca pointing to ephemeral instances where * can be a PR id.

Path based routing has it's benefits in terms of SSO because the redirect URIs only need to be configured once, however, it might require some changes to the application code. Sub-domain based routing, on the other hand, does not require app updates, but also does work with SSO unless we can get a wildcard redirect URI.

Relates to #138

[vedantthapa]

Path based routing doesn't deal with redirects well. It would require the application to expose a route prefix env variable which can then be configured with istio virtual serivce's HTTPRoute.

A long term solution would be have SSO as an infrastructure component with either Google IAP / OAuth2 proxy.

re: Disabling SSO for ephemeral environments

Disabling SSO opens a hole in the app's security boundary, since they rely on SSO as an alternative to being PHAC VPN locked. Definitely a no-go if/when the devs want to use copies of prod data in the ephemeral environment (maintaining realistic fake data for testing is a burden we can't enforce)

[vedantthapa]

After merging #185 i.e, exposing a route prefix env variable SCRIPT_NAME, stuff works as expected. It's important to note that the SCRIPT_NAME env variable in the deployment must have a leading / (example: /pr1, /pr2, etc.) otherwise it'll mess up redirections after the initial login.

Nevertheless, since the url route includes the {SCRIPT_NAME` prefix, which is not a component of the registered redirect uri, this still raises SSO issues. Thus, we effectively encounter the same issue as routing based on subdomains.

In conclusion, both subdomains per ephemeral build or path-differentiated ephemeral builds require some form of wildcard allow listing. The security folks would probably be much more receptive to the path-based option though since (sub)domain wildcards are much broader and more dangerous.

[Stephen-ONeil]

While waiting for a response from the M365 team, I figured I may as well do some googling my self. Seems, presumably, that path based routing won't actually be an option (for SSO), frustratingly, as the only wildcards Azure supports are at the lowest level of the subdomain, which I already wanted to avoid for security issues.

Can wait for a response from the M365 team, but I think we will likely end up having to return to creating subdomains per-ephemeral build.

Side note, but not an immediate solution, this recommended approach on using OAuth2 state parameters looks to be the solution we would use when implementing SSO proxies, should we want them to be decoupled from the target app/shareable between deployments. It would be an ugly and non ideal app-level solution for the ephemeral builds though.