`/` should get you something other than 404

[plotnick]

Visiting the root path on a Nexus server should get you somewhere, though it's not obvious exactly where. This should be decided (this issue would be a reasonable place to have such discussion) and may depend on whether you are already logged in or not.

[plotnick]

See also

omicron/nexus/src/external_api/console_api.rs

Lines 386 to 394 in a0e5d59

	let next_url = if let Some(relay_state) = &relay_state {
	if let Some(referer) = &relay_state.referer {
	referer.clone()
	} else {
	"/".to_string()
	}
	} else {
	"/".to_string()
	};

[smklein]

For reference, this was discussed in the June 28th IAM sync. FYI @david-crespo , @davepacheco , @jmpesp

[davepacheco]

I think the immediate motivation here is that a successful SAML login today ends with the browser being redirected to "/", which is currently a blank 404 page because there's no Nexus route at "/". This is a special case of an authenticated user navigating to "/" (or typing it into their browser). I imagine this should redirect to some top-level console view. @david-crespo is there a URL we can redirect people to for this case?

There's the separate case of an unauthenticated user reaching this URL. This is harder because we don't know what Silo they're supposed to get logged into. One idea is to list the discoverable Silos and let them choose. This is fine, but doesn't help the use case of undiscoverable Silos. We've also discussed having different DNS names for the API and console for each Silo. In that case, we'd know what Silo's login page to redirect you to and this works regardless of whether the Silo is discoverable. This approach may well have other implications and we should put together an RFD on that. I think this use case is also less urgent.

[david-crespo]

Some things we can do in order of simplicity:

• SAML server sends user to /orgs
  • should just work as-is because Nexus will serve the console at that route
• SAML server sends user to /, and Nexus has an endpoint that returns a redirect to /orgs
  • a bit pointless, though it is weird that we don't have anything at /
• SAML server sends user to /, which has a Nexus endpoint that serves the console (extract the contents of the existing /orgs/* handler and call it in both endpoints) and then the console does whatever it does
  • Currently, at / the console does a client-side nav to /orgs because we don't have a root page, but we could easily serve the orgs list directly at / too. Doesn't matter that much and it's easy to change

The first one makes the most sense to me. I don't see too much point to the other two. However we really should do something at / in both Nexus and console. (Though you might never be able to get to / in console if Nexus doesn't serve the console at that path.)

[davepacheco]

That's a good summary. One advantage of the third option is avoiding coupling between Nexus and console code (by having Nexus know about a specific console route). We might also be able to avoid this with the first option if the console is responsible for specifying where to go after the redirect? i.e., if someone goes to '/login/pluto/saml', maybe the console tacks on ?redirect_on_success=/orgs (I just made that query param up) and then we have the SAML flow wind up at whatever that query param says?

[plotnick]

The state query parameter already allows exactly that. We do use it for some things, but maybe if it's missing the console could add a default.

[david-crespo]

We agreed on a demo run-through call that we'll start by serving the console assets from /, which delegates the question of what is actually shown at that route to the console.