...
$name – should be set to the plugin name, the part after mfa_
user_can_register() – return true if the user is able to register a new instance of this factor
gethas_register_componentui() – name of the Tui component to use for registrationdoes this factor have a registration UI?
get_register_data() – data to provide to the registration componentUI
gethas_verify_componentui() – name of the Tui component does this factor have UI to show on the login screen?
get_verify_data() – extra data to pass to the verify componentUI
verify() – called with data from the front end, when the verify component is submitted
...
On the front end, there are two components you’ll you'll want to implement. These should be located directly under components, so that the front-end code can find them.
The first one is the Register component. This takes a data prop, containing the result of get_register_data(). This should call a plugin-specific GraphQL mutation in order to create an instance of the factor (see TOTP’s create_instance mutation for an example). It should then emit a saved event with the ID of the new instance.
...
An example of what this change looks like is shown below:
|
|
Note |
---|
The function/method provided to the complete_user_login_callback MUST be discoverable by the class autoloader. |
...
After creating the complete_user_login callback and testing your auth plugin works as expected, override the supports_mfa method in the auth plugin class to return true. This will help identify that the auth plugin now supports MFA in the system.
|
Revoking registered user factor via CLI
By using the revoke_admi_mfa CLI script, an admin user’s registered MFA factors can be revoked. The script prompts for the admin user’s username to find the user to revoke registered factors. You can also pass the username as a parameter to the script as shown below:
|
Note that Site Administrators can also revoke MFA via the Manage user login page.