What we have

Reporting currently utilizes a "higher-order handler" function to determine if the user (who initiated the request) has access to reporting. This is both a check on their licensing level, security setup, and if a configured (or not) reporting_user role is in their roles definition. This system works for what we have today but is lacking in a few areas:

• We're not able to take advantage of API keys internally.
• Having a hard-coded, or pre-configured, role makes troubleshooting issues tougher.
• Reporting jobs are async, and since we can't utilize API keys, authorization for reports are short lived -- effectively a blocker for scheduled reports.
• Users, overall, will benefit from having a consolidated place to manage their teams permission models -- easing the cognitive burden on administrators.

Why do this?

For reporting to function as it is today, we don't actually need to do this. Scheduled reports, however, does require longer lived credentials which our current model doesn't support. In reporting today, we memorize certain headers from the initial job-creation request, and when our headless browser starts we "inject" these same headers on all network requests in order to mimic being the actual user. This is a doable workflow for ad-hoc reports since the user's authorization tokens last long enough to ensure the reports work. However, since scheduled reports will likely outlive authorization tokens, reporting will need a more flexible permissions model in order to run reports on a users behalf. This new permissions model should get us this "for free" as far as my understanding goes.

High-level work needing to be done

• Remove the conditional configuration check on the authorized_user_pre_routing module.
• Introduce an (optional?) dependency on the roles/perms plugin if needed. Need to verify what we need to do exactly in our consumption of the security plugin.
• Pass the request over to this plugin to validate if the user has permission to do what they need to.
• Update all relevant tests, integration tests, our documentation on this change.
• Update our documentation to use this new workflow over the existing configuration based approach.

Potential Downsides and caveats

Given the larger change our users will face with this, there might arise some issues we should be aware of.

• Confusion on why something isn't working when it did in a prior version.
• Slightly more complex setup, as we won't have a one-size permission model.
• Perhaps more context needed in SDH and other issues to determine why something isn't working.
• Complexity in our plugin to determine if a request can run (do they have the right licensing? Do they have security turned on and is the user logged in? Does the logged-in user have the right permissions to do what they want to do?). This also makes testing a bit more complicated to setup as well.
• Possibly requires a larger body of documentation to setup properly.

Open Questions

• This is a medium sized body of work that requires some care in implementation. Given the current model is to use a configured reporting_user role, do we want to try and use both systems to mitigate a breaking change?
• If we are to do both, then we'll need to decide "which one wins" in cases where both are defined. My assumption is to use the security plugin if available, over the configuration-based approach. Care must be used on this to determine if a user has actually setup reporting, or if the supplied roles are simply defaults.
• We also need to determine the intersection of pages to reports as well, so we can illustrate to our users how to setup reporting permissions for success. For example, if a user doesn't have access to Dashboards, they won't be able to generate a PDF of them regardless of what their permission level is.
• We'll also need to know, prior to development, how we want to setup these permissions. Are they a sub-feature of the pages users can access? Or do we declare these permissions as standalone features and rely on our users to know how to set them up properly for success?
• In early designs of scheduled reports, there's a workflow where users can start/generate reports from within the reporting page itself. When work begins on that, we'll need to be sure that we make use of the appropriate APIs to filter out portions of Kibana that the user doesn't have access to.
• What are the "default" states when no permissions are set? Allowed?

Original Issue:

Similar to the dashboard only mode configuration via the advanced settings view, users would like to configure roles that have access to reporting through the UI.