...

• $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:

$user = authenticate_user_login($username, $key);
if($user) {
	complete_user_login($user);
	// update user profile picture
	custom_code_update_profle_picture($user, $a);

// update auth_plugin records
custom_code_update_other_records($user, $b);	
	redirect("https://totara/custom_url.php");
}

class custom_code_callback {
	public static function complete_login($a, $b) {
		global $USER;
		
		// Logged-in user
		$user = $USER;

	// update user profile picture
	custom_code_update_profle_picture($user, $a);

// update auth_plugin records
custom_code_update_other_records($user, $b);	
	redirect("https://totara/custom_url.php");
	}
}

$user = authenticate_user_login($username, $key);
if($user) {
	$callback = \core\login\complete_login_callback::create(
	[custom_code_callback::class, 'complete_login'],
	[$a, $b]
);

	complete_user_login($user,$callback);
}

...

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.

public static function supports_mfa(): bool {
        return false;
}

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:

# Calling the script with a prompt

php server/admin/cli/revoke_admin_mfa.php

# Passing the username as a parameter

php server/admin/cli/revoke_admin_mfa.php --username=admin

Note that Site Administrators can also revoke MFA via the Manage user login page.