Reject OpenID Connect authentication attempt initiated by a Third Party if configured and used realms don't match

[azasypkin]

Currently to handle an OpenID Connect authentication attempt initiated by a Third Party, Kibana passes only iss and login_hint parameters to the Elasticsearch. Elasticsearch explicitly forbids passing both iss and realm in the same request. That means that technically user can be authenticated by any suitable Elasticsearch OpenID Connect realm even if it doesn't match the realm configured in Kibana.

This may lead to a weird state when users are authenticated by one Elasticsearch OpenID Conect realm during a Third Party initiated login and by a different one when they initiate login from Kibana (we pass realm to Elasticsearch in this case). This issue is exacerbated in case we have multiple OpenID Connect authentication providers with potentially different settings (session timeouts, access agreement etc.).

Previously we didn't have an easy way to figure out which realm was actually used for a Third Party initiated authentication, but now Elasticsearch response includes both realm and authentication object. Using this information we can easily detect a realm mismatch and reject authentication attempt (and invalidate "mistakenly" created tokens) that will either give a chance to the next OpenID Connect provider to perform authentication or forbid login completely.

[elasticmachine]

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