Creating a passwordless user

[NikSays]

Is your feature request related to a problem? Please describe.
RabbitMQ allows creating passwordless users. However when an User resource is added via this operator, the password is required. If the password is not provided, it is automatically generated.

Describe the solution you'd like
I see two possible solutions:

1. If the secret has no password key, generate the password; but if the secret has password: "", disable password auth. (Not backwards compatible)
2. Add a new noPassword: bool flag to UserSpec.

Describe alternatives you've considered
With the right configuration, password auth via AMQP can be disabled for all users, but not individually.

Additional context
Management API endpoint /api/users/*name* creates a paswordless user if password_hash: "".

I can implement the noPassword: bool solution and open a PR, just want to be sure that this isn't already possible, and that the maintainers are okay with this solution.

[Zerpet]

This idea sounds good to me. The best solution would be to support password hash in the User spec (see #866), or in the ImportCredentialsSecret secret, from a field inside the Secret. The password hash could have more priority over the "plain" password, because it's a more secure alternative.
It's important to note that we must have the ability to distinguish between "empty string" and "not set". This essentially means that, if we go down the new spec field solution, that field will have to be a pointer.

[NikSays]

The hashing_algorithm field in the UserSettings struct is currently hard-coded to rabbit_password_hashing_sha512. This is fine when the hash is generated by the controller, but the hash provided in the Secret might be either SHA512, SHA256, or MD5. The solutions I see are:

1. The Secret has a new hashingAlgorithm field;
2. The controller tries to detect the function used from the length of the hash;
3. Only one algorithm is supported in the spec.

[bou3108]

Hi,

It would be a high-value improvement for us. We use EXTERNAL authentication mechanism to authenticate external clients with mTLS only. They're supposed to be passwordless but they're currently created with a generated password.

We obviously don't share the generated passwords, but still, we're not happy with it.

Thanks @NikSays for the issue and the PR, we hope it could be merged soon !