Loading

Browser authentication in Scout

Use the browserAuth fixture to authenticate UI tests. Scout uses SAML, so the same approach works across deployment types.

Available methods:

Method Description
loginAsViewer() Read-only flows using the built-in viewer role
loginAsPrivilegedUser() Resolves to editor, or developer for Elasticsearch serverless projects
loginAsAdmin() Admin-only behavior (full access); avoid unless required
loginAs(role) Log in with a specific built-in role by name (must exist in the deployment)
loginWithCustomRole(roleDescriptor) Log in with a specific set of Kibana and Elasticsearch privileges 
test.beforeEach(async ({ browserAuth, pageObjects }) => {
  await browserAuth.loginAsViewer();
  await pageObjects.dashboard.goto();
});
Note

Local runs can create on-demand identities via a trusted mock IdP. Cloud runs authenticate using pre-provisioned users (internal provisioning details live in internal AppEx QA documentation).

Use loginWithCustomRole() to test permission boundaries with least privilege:

await browserAuth.loginWithCustomRole({
  kibana: [{ spaces: ['*'], base: [], feature: { discover: ['read'] } }],
  elasticsearch: {
    indices: [{ names: ['logstash-*'], privileges: ['read', 'view_index_metadata'] }],
  },
});

If the same login/role is needed across many tests, extend browserAuth in your solution/package/plugin fixtures instead of repeating role descriptors.

Examples in the repo:

  • Avoid admin unless you’re explicitly testing admin-only behavior.
  • Prefer loginAsPrivilegedUser() for suites that run across multiple environments.
  • Keep custom roles minimal and document why they exist.