Automatically probe LDAP server to help user understand if LDAPIdentityProvider settings are working as expected

[cfryanr]

Is your feature request related to a problem? Please describe.

As a user creating an LDAPIdentityProvider, due to the nature of LDAP having a very flexible schema, I need to provide several configuration options to describe how to search my LDAP database for users (given a username typed by the end user during a login attempt) and how to search for group membership (given a user DN found in the username search). Because many users are not familiar with the old/arcane details of how LDAP queries work, these queries can be a little confusing to write and it is not clear if they are working as expected after the LDAPIdentityProvider is created.

Also, the admin user who is creating the LDAPIdentityProvider resource is not necessarily the same user who should be allowed to log in to the cluster. In order to test the login today, they need to know a valid username and password which can be found according to the LDAP search criteria specified in the LDAPIdentityProvider.

Today, the LDAPIdentityProvider helps the user understand if the host, tls, and bind settings are correct by attempting to open a connection to the LDAP server and perform the bind as the service account. If the connection, the TLS negotiation, or the bind fails, then our controller attaches a message to the LDAPIdentityProvider's status field to describe the nature of the failure. However, it does not help determine if the userSearch and groupSearch settings are correct, and these are the settings which are more difficult to get right.

Describe the solution you'd like

Since the controller has already connected to the LDAP server and bound as the service account, it could perform a user and group search. Given the name of any actual LDAP user who should be found in the database according the userSearch settings, it could find that user and then find that user's group memberships, and somehow report the results.

In the case of an error, it could report the error.

In the case of successfully finding a user, it could report the downstream username, which can already be configured as a mapping to come from any field in the LDAP record. It could also perform the group search and could report how many groups the user belongs to, along with the mapped group name (which can also come from any field in the group record) for the first few groups (as there may be hundreds).

Describe alternatives you've considered

It seems like the natural place to put this probe would be in the controller which is already watching LDAPIdentityProviders and performing other test probes. The natural place to put the error or success result would be in the status of the LDAPIdentityProvider, as a non-blocking warning status (still allow use of the LDAPIdentityProvider even when this probe fails). An input username must be provided, so this could be added to the LDAPIdentityProvider's spec.

However, it could alternatively be provided as a separate API: given the name of an LDAPIdentityProvider and given a username to probe, return the results.

Are you considering submitting a PR for this feature?

Sure, once a design has been agreed upon.

• How will this project improvement be tested?

Unit and integration tests.

• How does this change the current architecture?

Not at all.

• How will this change be backwards compatible?

It could be added as a new field or API (additive change).

• How will this feature be documented?

In the API docs.

[anjaltelang]

Reviewed on 12-7-21. On the backlog.

[joshuatcasey]

I wonder if the outcome of this issue is resolved by #1594?

[cfryanr]

#1594 is close enough for now. Closing.