feature:Allow configuration of a preferred_mfa_provider

[schlueter]

Description

Allows for configuration of a preferred mfa provider which is used to more precisely select an available preferred mfa factor by filtering the list of available factors by provider in addition to type. This allows, for instance, a user to have setup both Google totp and Okta push and to have a preferred default used by gimme-aws-creds; currently in this situation, the user must select their preferred mfa factor at runtime as gimme-aws-creds will see both available and default to prompting the user to select one.

Related Issue

#445

Motivation and Context

In order to give myself options, I have both Google Authenticator and Okta Verify setup. In the past, I have disabled Okta Verify so that gimme-aws-creds only has one totp mfa to find, but this seems like an unnecessary concession.

How Has This Been Tested?

While using an Okta account with both Google Authenticator and Okta Verify setup:

1. With preferred_mfa_type = token:software:totp and preferred_mfa_provider = GOOGLE in the global config, the user is prompted for an authentication token from Google.
2. With preferred_mfa_type = token:software:totp and preferred_mfa_provider = OKTA in the global config, the user is prompted for an authentication token from Okta.
3. With preferred_mfa_type = token:software:totp and preferred_mfa_provider = GOOGLE in an account configuration, the use is prompted for an authentication token from Google.
4. With preferred_mfa_type = token:software:totp and preferred_mfa_provider = OKTA in an account config, the user is prompted for an authentication token from Okta.
5. With neither preferred_mfa_type or preferred_mfa_provider configured, the user is prompted to select a factor as they were previously.
6. With preferred_mfa_type = token:software:totp and preferred_mfa_provider unset, the user is prompted to select a factor as they were previously when a preferred type is configured.

I do not use DUO, and I am unaware of which other combinations of factors might be affected by this. I specifically included logic to avoid filtering out all potential factors if none match the preferred provider to minimize potential confusion.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[schlueter]

I just realized that this appears like a different implementation of #354.