For delegated authorization realms, preserve user metadata from the authenticating realm when constructing the User object

[justincr-elastic]

Compare what happens when delegated authorization (authz) is enabled or disabled in an authenticating realm.

Important code:

- DelegatedAuthorizationSupport.resolve(String username, ActionListener<AuthenticationResult<User>> resultListener)
- UserData(principal, dn, groups, metadata, realm)
- User(principal, roles, fullName, email, metadata, enabled)

Examples:

1. OpenIdConnectRealm.buildUserFromClaims(): If delegated authz is off, User objects are constructed using JWT claims like principal, fullName, email, and metadata. If delegated authz is on, only principal (ex: parsed "sub" claim) is passed to authz realms, so User objects cannot populate JWT claims into the fullName, email, and metadata fields.
2. LdapRealm.buildUser(): If delegated authz is off, User objects are constructed using principal and metadata. If delegated authz is on, only principal (ex: parsed CN value) is passed to authz realms, so User objects will lack metadata from the authc realm (i.e. "ldap_dn" and "ldap_groups").

Generalization:

If delegated authz is off, the authc realm does:

• role mapping using principal, dn, groups, and metadata.
• User construction using principal, fullName, email, and metadata.

If delegated authz is on, the authz realm does:

• role mapping using principal only; ignored values are dn, groups, and metadata.
• User construction using principal only; ignored values are fullName, email, and metadata.

Delegating role mapping by principal only is probably OK. However, only passing the principal for delegated User object construction is an issue. The two use cases of delegated authz on or off are inconsistent for how non-role fields get populated in the User object. Also, those non-role Use fields could be useful for other use cases like Elasticsearch audit logging, Kibana user display, etc.

Potential options:

1. Status quo. Let authz realms resolve both role mapping and User construction. Only pass the principal.
2. Let authz realm resolve both role mapping and User construction. Role mapping remains principal only, but pass the missing authc details through to use during User object construction.
3. Let authz realm resolve role mapping only. Return the resolved roles to the authc realm, and let the authc realm choose the non-role User fields for object construction.

To be determined:

1. Are non-realms affected (i.e. ServiceTokenAuthenticator, OAuth2Authenticator, ApiKeyAuthenticator)?

Context:

This issue was discovered while thinking through how a JWT realm can construct the User object. Looking at potential reuse of OIDC code, it seemed odd that enabling delegated authz meant metadata from JWT claims do not get populated in the User object.

[elasticmachine]

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