Clarify user authentication doc on ECH

[kunisen]

Description

Make it clear that LDAP, Active Directory and PKI is not configurable for Elastic Cloud hosted environment.

Background:

• In an internal ticket (SDH - CP - 9505), we were guided by @beiske that ECH doesn't support LDAP, but the public doc is not evident enough for us to understand this fact
• We agreed that a doc PR to clarify this would be necessary

I also found Active Directory and PKI are the same that are not applicable on ECH.
So I made a quick doc PR to make these related user authentication docs clear.

After PR is merged

The orange sections will be added

Additional Notes

To doc team: Maybe we could also use note instead of warning. I don't have strong opinion here. Would leave this to your capable hands for decision 🙏

[florent-leborgne]

@kunisen First, let me say that I totally understand the concern here. One new principle coming with these new docs is that we're trying to convey the applicability through metadata whenever possible rather than with callouts. While we will usually prefer to list what something is applicable to rather than not applicable to, such cases should indeed leave no ambiguity to avoid any confusion for users.

To not deviate from this new principle and go along with the new standard (that hopefully users will get used to fairly rapidly), I would then propose to use tags rather than callouts. This would give something like this for the concerned pages:

Let me know what you think.
cc @shainaraskas for 2nd opinion and input

[kunisen]

Thank you @florent-leborgne so much for the detailed explanation!

Personally, I am ++ on this as I think we can try as you suggested and revisit this if we still keep getting the support cases about similar topic.
(also to follow our new principle)

I'd also let @maggieghamry share her opinion since she's also proactively helping support engineers and customers by making our docs more clear and succinct. 🙏

[shainaraskas]

I don't mind @florent-leborgne's suggested approach personally, but I think we're not ready to use inline applies tags like this .... these are brand new and were introduced as a bandaid, meant to indicate the availability of things like settings in reference documentation.

Following our current guidance, I think we'd need to do something like this instead:

ldap
Uses an external LDAP server to authenticate the users. This realm supports an authentication token in the form of username and password, and requires explicit configuration in order to be used. LDAP is not available on Elastic Cloud Hosted deployments.

For more information, refer to LDAP user authentication.

Regarding the page-level applies tags, we aren't using unavailable tags consistently so I'd slightly prefer to not do this until we have that guidance locked down a bit better, but I'm ok with them going in.

There's also a concern about these missing serverless context if we call out non-availability explicitly, for all of these realms.

[florent-leborgne]

@kunisen I had a quick chat with @shainaraskas and we agreed on the following in order to stick as much as possible to our current docs guidelines:

• We'll dismiss my proposal for now as the docs team needs to discuss more on what we want to establish as a standard for the future of those "inline" applicability tags and "unavailable" tags. We may revisit this as well as all similar docs once we've discussed it.
• We'll keep the callouts you suggested except for the one under "Available external realms"
• For that one under "Available external realms", we would instead simply add text to each of these items to state that "LDAP/AD/PKI is not available on Elastic Cloud Hosted deployments."

Let me know if that would work for you and I'll be happy to implement the changes.

[kunisen]

Thank you again @florent-leborgne for the detailed explanation and proactive help as always!
They look all great to me and very clear. 🙏

[florent-leborgne]

👍 LGTM after the changes that we discussed. I'll just also quickly replace some names with their corresponding variable and I'll merge it.