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.

• Refactor CompositeRolesStore to separate roleDescriptors resolving (Refactor CompositeRolesStore for separation of concerns #80926)
• Move effective role descriptor checking from Resolver to CompositeRolesStore
• Rework Role and LimitedRole to support more general limiting #81192
• Replace Authentication with AuthenticationContext in places other than CompositeRolesStore