Providing users with a second, "simple", set of credentials for low risk level operations

[Marc Marschner]

To provide our users on the work floor with a simpler method of authentication we want to introduce a PIN code credential next to the standard password credential. This authentication should be used for systems with low-level access (e.g. operations on the shop floor). In these scenarios, we are mostly interested in identifying the person executing commands and less in protecting access behind a high barrier of entry - a simple check for matching username and four digit PIN will suffice, especially as these operations are executed from a mobile device which lacks a suitable keyboard and allowing for simpler passwords would compromise our policy.To implement such a credential, we are following the Secret Question example described in the Keycloak Server Developer Guide (https://www.keycloak.org/docs/latest/server_development/) and available as example on the Keycloak Github Project. To fit our purpose, we need to modify the requirements on two points:

1. The PIN code of a user should be stored encrypted
   
2. We need to verify user and PIN code at the same time
   

Following the recommendation in the Server Developer Guide we therefore also looked at the PasswordCredentialModel and its use of the PasswordHashProvider. Ideally, we would like to rely on existing code as much as possible, such as that any updates and fixes automatically will also apply for us.
In this case, this would mean reusing the PasswordHashProvider to create an encoded secret, with the values for algorithm name, iterations and salt being provided alongside.
Unfortunately, this is not as straight forward as we had hoped, as the implementations of the PasswordHashProvider are geared towards directly providing a PasswordCredentialModel - the generic "encode" method omits at least the salt from the response and other methods operate on and/or return the PasswordCredentialModel class. We are therefore wondering if there are any near-future plans to make this component more generic and reusable and, if that is not the case, wonder which of the following two options you would recommend:

• Use the PasswordHashProvider and build our own model from the resulting PasswordCredentialModel by copying over the attributes and do the same translation for the verification of provided input.
  
• Create our own HashingProvider and load it as additional SPI. Ideally, we would avoid this approach, as it requires code duplication w.r.t. the existing code base and will require ongoing maintenance of this code.
  

To fulfil our second requirement, the verification of the user, we want to make use of the functionality already established in the AbstractUsernameFormAuthenticator. Would the recommended approach be to extend that abstract class and override the methods to our requirements, similar to the OTPFormAuthenticator, or is the user verification functionality available through other means?

On a more general level - is this the way we should move forward to include the requested functionality? Do you see other options that we should explore that provide us with the expected functionality (or a reasonable approximation of it)?