We would like to revisit the `Authentication` class to make it provide better and easier to use interface to the consumers. 

#79809 enables run-as for all authentication schemes in addition to `realm` which is already supported. This adds more complexity to an `Authentication` object and how it should be used. For an example, building the role associated to an user now has to consider whether the user is the authenticated user or run-as user and the authentication scheme of the authenticated user. The existing `Authentication` class can answer all these question today. But its interface and internals are not aligned for these questions and the usage is error prone. For example, the `Authentication` object itself does not know whether the user has run-as. This information is kept by the `User` object. If the `User` object has an `authenticatedUser`, it's the run-as user. Otherwise it is not. But the information about realms for each `User` is directly kept in `Authentication`. Therefore, for full picture, the caller must check both `User` and `Authentication` realms and understands the nuance of their differenent combinations. 

- [x] Refactor CompositeRolesStore to separate roleDescriptors resolving (#80926)
- [ ] Move effective role descriptor checking from Resolver to CompositeRolesStore
- [x] https://github.com/elastic/elasticsearch/issues/81192
- [ ] Replace Authentication with AuthenticationContext in places other than CompositeRolesStore
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/Subject.java
/*
 * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
 * or more contributor license agreements. Licensed under the Elastic License
 * 2.0; you may not use this file except in compliance with the Elastic License
 * 2.0.
 */
package org.elasticsearch.xpack.core.security.authc;
import org.elasticsearch.ElasticsearchSecurityException;
import org.elasticsearch.Version;
import org.elasticsearch.common.bytes.BytesArray;
import org.elasticsearch.common.bytes.BytesReference;
import org.elasticsearch.common.util.ArrayUtils;
import org.elasticsearch.core.Nullable;
import org.elasticsearch.xpack.core.security.authc.service.ServiceAccountSettings;
import org.elasticsearch.xpack.core.security.authz.store.RoleReference;
import org.elasticsearch.xpack.core.security.authz.store.RoleReferenceIntersection;
import org.elasticsearch.xpack.core.security.user.AnonymousUser;
import org.elasticsearch.xpack.core.security.user.User;
import java.util.Map;
import static org.elasticsearch.xpack.core.security.authc.Authentication.VERSION_API_KEY_ROLES_AS_BYTES;
import static org.elasticsearch.xpack.core.security.authc.AuthenticationField.API_KEY_LIMITED_ROLE_DESCRIPTORS_KEY;
import static org.elasticsearch.xpack.core.security.authc.AuthenticationField.API_KEY_ROLE_DESCRIPTORS_KEY;
import static org.elasticsearch.xpack.core.security.authc.Subject.Type.API_KEY;
/**
 * A subject is a more generic concept similar to user and associated to the current authentication.
 * It is more generic than user because it can also represent API keys and service accounts.
 * It also contains authentication level information, e.g. realm and metadata so that it can answer
 * queries in a better encapsulated way.
 */
public class Subject {