Open legrego opened 4 years ago
Pinging @elastic/kibana-security (Team:Security)
Given our current priorities, it's unlikely that we will get to this before https://github.com/elastic/kibana/issues/59377 is resolved. It is probably worthwhile to wait for #59377 at this point so that the mechanism for navigating to the space selector is identical to the way we navigate to any other application within Kibana w/r/t dynamic capabilities.
Note from today's meeting: this is not well-defined, and some of the issue description is out of date from our old circular dependency. This issue needs some research and design work before implementation.
Currently, logging into Kibana is a multi-step process with Spaces enabled: 1) Full page load: login screen 1a) Authenticate (assuming basic/token providers here) 2) Full page load: space selector 3) Full page load: Kibana @ the selected space.
Ultimately, we should eliminate as many of these full page loads as possible. Until https://github.com/elastic/kibana/issues/59377 is resolved, we can't eliminate step
3
, as we require an updated set of UI Capabilities.This issue is focused on eliminating the full page load at step
2
, which we should be able to accomplish without https://github.com/elastic/kibana/issues/59377.We should render the space selector UI via client-side routing after authenticating, if (and only if) the user is authorized to access more than one space, and their
next
query parameter indicates that they would otherwise be navigating to the Kibana root.Doing this without a page reload means that the login page (and security in general) needs to be more aware of spaces. Spaces currently has its optional dependency on security declared, so we can't have security declare a dependency on spaces at this point.
I see a couple of paths forward, none of which are great. I'm open to all other ideas: 1) Allow security to have a dependency on spaces, by eliminating space's dependency on security. This likely involves splitting out the shared authorization code into its own plugin that both security and spaces can depend on, or reimagining how we authorize access to spaces themselves. 2) Have security make its own calls to the spaces APIs (extending them as necessary), without declaring a dependency 3) Expose an internal security api which uses the spaces service we already depend on to figure out if the login page should route to the space selector or not.
/internal/security/_get_next_location?next=...