Authentication failed not handling nested challenges about warrant HOT 9 OPEN

Looks like it assumes there will only be one response challenge.
We'll need to add the ability to complete the challenge with an additional input (the new password).

from warrant.

The current state:

• Warrant raises ForceChangePasswordException for users which are required to change their passwords after successful first login (NEW_PASSWORD_REQUIRED challenge).

• new_password_challenge method is not documented

• Warrant raises NotImplementedError when a challenge is not supported.

• Warrant doesn't support SMS_MFA, CUSTOM_CHALLENGE, DEVICE_SRP_AUTH DEVICE_PASSWORD_VERIFIER challenges.

The first post says about the problem with the NEW_PASSWORD_REQUIRED challenge only and this issue is fixed. The title has more broad meaning, it implies that warrant should support all challenges.

@bjinwright The decision of closing the issue depends on what to take into account: the title or the first post.

from warrant.

Yeah I also just realized my initial diagnosis in where I thought the problem was was wrong. And you've hit the nail on the head for the conclusion I just came to.

from warrant.

The handling in #15 isn't perfect for NEW_PASSWORD_REQUIRED I'd like there to be a module global which is a callable and returns back the password. Allows users to specify a system to get the password rather than using a TTY is present.

from warrant.

I like the way #25 handles the authentication, it raises by default and then lets the user come up with their own way of getting the password which keeps in line with a web usage model.

from warrant.

Based on your suggested workflow @bjinwright I'm working on this aspect. Not sure if any one else is.

However admin_get_user looks like it requires developer credentials, credentials which we won't have. How would we get the user status without being able to login. I'm assuming a web framework which and the user provides credentials which calls warrant which calls cognito. Those are the only credentials in the framework. Can you expound on how your proposed workflow executes that?

from warrant.

Thanks for the feedback that makes sense

from warrant.

So with that in mind we may need to implement the remaining work flows based on challenge types rather than user status. What do you think?

from warrant.

For historical purpose I'm still going to put my work for user statuses:

UNCONFIRMED - User has been created but not confirmed.
ConfirmSignUp

CONFIRMED - User has been confirmed.
Normal workflow

ARCHIVED - User is no longer active.
Not sure there is a workflow here.

COMPROMISED - User is disabled due to a potential security threat.
Not sure there is a workflow here.

UNKNOWN - User status is not known.
Not sure there is a workflow here.

RESET_REQUIRED - User has issued a reset password request but not reset it.
ConfirmForgotPassword, possibly RespondToAuthChallenge

FORCE_CHANGE_PASSWORD - User has not authenticated for the first time and must change password
RespondToAuthChallenge

from warrant.