[Reporting] usage of non-unique username to control report security

[tsullivan]

Capturing this from a conversation with @azasypkin:

In a Kibana request, the username information is not unique across all users in the cluster. There may be completely different users with the same usernames coming from different authentication realms (e.g. native and LDAP).

Example: Let's say Kibana/Elasticsearch is configured to work with native (native Elasticsearch users) and SAML realms (e.g. Okta connected to Active Directory). User can log in to Kibana using either of these authentication mechanisms if they have proper credentials. Today Kibana and Elasticsearch would rightfully treat users authenticated via different realms as different users, even if they have the same usernames. That's why you'd need to use username:realm-name tuple to uniquely identify users today.

But Elasticsearch has recently introduced security domains (https://www.elastic.co/guide/en/elasticsearch/reference/master/security-domain.html). Security domains allow to group multiple realms under the same domain, and in the example above we might need to treat users from different realms as the same users if their usernames match. In this case username:realm-name tuple will no longer work as expected and consumers will need to switch to the opaque user ids (will be exposed by the security plugin).

To uniquely identify users we either wait for opaque user ids or you use username:realm-name tuple today and plan to migrate to an opaque user id once it's available.

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesUx)

[legrego]

To uniquely identify users we either wait for opaque user ids or you use username:realm-name tuple today and plan to migrate to an opaque user id once it's available.

One important note: Not all users will have an opaque user id in all setups. For example, administrators who use a reverse-proxy in front of Kibana for authentication will not be able to take advantage of opaque ids or user profiles.

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[tsullivan]

This seems like an issue with a few complications and perhaps not a straightforward or easily-discoverable solution.

Adding the Discussion label.

[tsullivan]

This doesn't seem directly related to the main issue of unique usernames, but it's work under the same topic of security:

When it comes to scheduled reports, we should send a report download link to a group and allow anyone in the group the privilege to view the report. This will likely prompt us to change/augment the way privileges work to grant access to downloading reports.

[tsullivan]

I've discussed this further with @azasypkin to make our requirements more clear.

1. Opaque user ids are available as user.profile_uid exposed from Kibana Core
2. For anonymous users, interactive users authenticated via proxies and API access via non-interactive users (aka HTTP clients), profile_id will not be available. In these cases it is a reasonable trade off to use the username:realm-name tuple as a fallback.
3. We should never treat users in different realms as the same user, regardless of whether they have the same username
4. It seems feasible to use the same field for different user identifiers at the same time, depending on which one was available when we populate created_by (the time that the report job was created).
   1. The "tuple" and "user profile ID" have quite recognizable and unique structure that would be highly unlikely to collide with the "username"
   2. We can add logic in listing the reports that the user owns with "created_by: username OR triple OR user profile ID".
   3. There will be an edge case of an old report created for a user with the same username but from a different realm, but we're already affected by this.

[azasypkin]

For anonymous users, interactive users authenticated via proxies and API access via non-interactive users (aka HTTP clients), profile_id will not be available. In these cases it is a reasonable trade off to use the username:realm-name tuple as a fallback.

It might be a bit safer to use username:realm-type:realm-name triple as realm name can change and be assigned to a different realm.

We should never treat users in different realms as the same user, regardless of whether they have the same username

Correct. There might be cases when different realms are configured within the same security domain (https://www.elastic.co/guide/en/elasticsearch/reference/current/security-domain.html#security-domain), and this rule won't hold though. However, it's safe to treat this as a very rare edge case at this point.

The "tuple" and "user profile ID" have quite recognizable and unique structure that would be highly unlikely to collide with the "username"

Right, just for the records:

• The "triple" format is username:realm-type:realm-name
• The user profile ID format is u_{username or username hash}_{domain suffix} (values in braces are configurable, e.g., u_hOnY7k2LzZa7899O3bRNqdPmM4pma_ArDdQ62g0wPOI_0 or u_123456_cloud for ESS)

It's highly unlikely that any of these identifiers will collide with actual usernames, internal or external.

[tsullivan]

Thanks @azasypkin. When you wrote triple I thought it was a typo and changed it to tuple, but it looks like you were right: it is triple not tuple.

[tsullivan]

I believe we have reached a conclusion in discussion on this, so I'm putting the issue back into triage.