When running Kibana with UIAM, an error for Streams is showing up in the logs.
Source: #239713 (review)
Testing locally, authentication errors consistently log from the Streams feature. After a bit of digging, I believe it's related to their use of a fake request. Without context, this pattern looks suspicious at best. We need to understand their use case to see if their implementation is valid, or if changes need to be made to accommodate UIAM. Plugins should not be trying to access the authorization header directly:
https://github.com/kc13greiner/kibana/blob/d8fd317c4166c99b3da0e679ca2cc360ec60ea97/x-pack/platform/plugins/shared/streams/server/lib/streams/helpers/fake_request_factory.ts#L11-L22
[2025-10-21T09:43:48.607-04:00][DEBUG][plugins.security.authentication] Re-authenticating request due to error: {"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [<unauthenticated-cloud-access-token>] for REST request [/_security/user/_has_privileges]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\", charset=\"UTF-8\""]}}],"type":"security_exception","reason":"unable to authenticate user [<unauthenticated-cloud-access-token>] for REST request [/_security/user/_has_privileges]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\", charset=\"UTF-8\""]}},"status":401}
[2025-10-21T09:43:48.609-04:00][ERROR][plugins.streams] Error: Failed to create AlertingAuthorization class: ResponseError: security_exception
Root causes:
security_exception: unable to authenticate user [<unauthenticated-cloud-access-token>] for REST request [/_security/user/_has_privileges]
at Function.create (alerting_authorization.ts:155:13)
at processTicksAndRejections (node:internal/process/task_queues:105:5)
at RulesClientFactory.create (rules_client_factory.ts:127:27)
at QueryService.getClientWithRequest (query_service.ts:36:25)
at async Promise.all (index 0)
at getScopedClients (plugin.ts:186:51)
at handler (route.ts:97:31)
at wrappedHandler (register_routes.ts:75:37)
at handle (route.ts:161:26)
at handler (route.ts:78:14)
at Router.handle (router.ts:218:30)
at router.ts:199:23
at exports.Manager.execute (/Users/larry/repos/kibana/node_modules/@hapi/hapi/lib/toolkit.js:60:28)
at Object.internals.handler (/Users/larry/repos/kibana/node_modules/@hapi/hapi/lib/handler.js:46:20)
at exports.execute (/Users/larry/repos/kibana/node_modules/@hapi/hapi/lib/handler.js:31:20)
at Request._lifecycle (/Users/larry/repos/kibana/node_modules/@hapi/hapi/lib/request.js:370:32)
at Request._execute (/Users/larry/repos/kibana/node_modules/@hapi/hapi/lib/request.js:280:9)
We should follow up with the Streams team as part of UIAM next steps.
When running Kibana with UIAM, an error for Streams is showing up in the logs.
Source: #239713 (review)
Testing locally, authentication errors consistently log from the Streams feature. After a bit of digging, I believe it's related to their use of a fake request. Without context, this pattern looks suspicious at best. We need to understand their use case to see if their implementation is valid, or if changes need to be made to accommodate UIAM. Plugins should not be trying to access the authorization header directly:
https://github.com/kc13greiner/kibana/blob/d8fd317c4166c99b3da0e679ca2cc360ec60ea97/x-pack/platform/plugins/shared/streams/server/lib/streams/helpers/fake_request_factory.ts#L11-L22
We should follow up with the Streams team as part of UIAM next steps.