I'm pretty sure we don't want this in the headers, but that was the easiest place to add it in the draft.

My concern here (and we've run into this every time we've wanted to put user information into useful places) is that "username" isn't as meaningful or as simple as people expect.

Some challenges:

• API Keys have a username, but it's the username of the person that created the API key. That's accurate, but rarely sufficient.
• Usernames are not globally unique. The same username may exist in multiple realms and reflect different identities
• When run-as is in use, there are 2 username (the authenticating user and the effective user)
• Not everything that authenticates has a username that is meaningful.

As you can see in how we do this for the slowlog, representing that information well requires more than a single field.

• elasticsearch/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/Security.java

  Lines 2290 to 2319 in 04d4590

  	public Map<String, String> getAuthContextForSlowLog() {
  	if (this.securityContext.get() != null && this.securityContext.get().getAuthentication() != null) {
  	Authentication authentication = this.securityContext.get().getAuthentication();
  	Subject authenticatingSubject = authentication.getAuthenticatingSubject();
  	Subject effetctiveSubject = authentication.getEffectiveSubject();
  	Map<String, String> authContext = new HashMap<>();
  	if (authenticatingSubject.getUser() != null) {
  	authContext.put("user.name", authenticatingSubject.getUser().principal());
  	authContext.put("user.realm", authenticatingSubject.getRealm().getName());
  	if (authenticatingSubject.getUser().fullName() != null) {
  	authContext.put("user.full_name", authenticatingSubject.getUser().fullName());
  	}
  	}
  	// Only include effective user if different from authenticating user (run-as)
  	if (effetctiveSubject.getUser() != null && effetctiveSubject.equals(authenticatingSubject) == false) {
  	authContext.put("user.effective.name", effetctiveSubject.getUser().principal());
  	authContext.put("user.effective.realm", effetctiveSubject.getRealm().getName());
  	if (effetctiveSubject.getUser().fullName() != null) {
  	authContext.put("user.effective.full_name", effetctiveSubject.getUser().fullName());
  	}
  	}
  	authContext.put("auth.type", authentication.getAuthenticationType().name());
  	if (authentication.isApiKey()) {
  	authContext.put("apikey.id", authenticatingSubject.getMetadata().get(AuthenticationField.API_KEY_ID_KEY).toString());
  	authContext.put("apikey.name", authenticatingSubject.getMetadata().get(AuthenticationField.API_KEY_NAME_KEY).toString());
  	}
  	return authContext;
  	}
  	return Map.of();
  	}

It questionable as to whether we need all of that information for the tasks API, but I think it we add a username we'll immediately get asked to do it "right" and provide the user's name and/or the API key id (and name) as well. And probably realm.
Each of those really is useful and necessary for some real world use cases, and admins do ask us to make it all available.

A few years (!?!) ago we experimented with putting a user concept into core elasticsearch and even tried to plumb it into Task (as a real concept, so it touched a lot of files)

• [Draft] [Spacetime] Add "ActionUser"  #91985

One of the big problems was deciding how complicated to make it.
We ended up with something simple and opaque, but it required a few debates, and I don't think anyone was perfectly sure we landed in the right spot.

• ActionUser.java

Oh fun! I think it's pretty important that we start getting this stuff in - for, well, some definition of this stuff. I'm not surprised that user is a complex concept. It really would be nice if I, personally, didn't have to understand it and could just "add the user stuff".