Closed sokomishalov closed 2 years ago
@mp911de thanks! I've reworked it according to your review.
Given that the Login API for both authentication mechanisms looks pretty much the same, I tend to remove the LDAP variant and suggest using UsernamePasswordAuthentication
for userpass
and ldap
. Furthermore, Okta and RADIUS follow the same login scheme. Okta supports additionally one-time tokens (totp
). Introducing totp
to UsernamePasswordAuthenticationOptions
is likely less invasive than having options for each individual authentication mechanism.
I'm going to adopt the PR into that direction.
Thank you for your contribution. That's merged and polished now.
@mp911de I do agree with your concerns here about human-machine and machine-machine authentication. But despite that, the truth is some enterprise companies rely too much on LDAP authentication, unfortunately. That forces users to build their own workarounds over that restrictions to achieve some goal. For example, teamcity plugin for hashicorp vault which cannot provide
ldap
/userpass
auth because of absence of implementation in spring-vault which is used by that plugin. This is the case of human-machine-machine authentication so I suppose it's ok to deal with human credentials. I propose to merge these changes which implementuserpass
andldap
auth backends but mark it somehow as unrecommended for usage (just like@OptIn
from kotlin).