Closed aogail closed 7 months ago
Can I get some more people who are using Duo in their Okta environments to test this? The code all looks good, but I don't have access to Duo in any of my test environments, so I can't verify the functionality.
@epierce thanks for reviewing this. Is verification by other Duo users a blocker for merging? I'd love to get this integrated and released soon so our users can update ahead of Duo's traditional prompt shut down in a couple months.
@epierce @aogail tested it today and works like expected.
❯ gimme-aws-creds --profile <redacted>
Using inherited config: DEFAULT
*** No device token found in configuration file, it will be created.
*** You may be prompted for MFA more than once for this run.
Using password from keyring for <redacted>
Device token saved!
Multi-factor Authentication required.
push: Duo selected
Duo required; check your phone...
status: Pushed a login request to your device...
status: Success. Logging you in...
Saving arn:aws:iam::<redacted>
Written profile <redacted> to <redacted>
cheers 🍻
@epierce @aogail tested it today and works like expected with AWS.
Merging - Thanks to @dsaathere for testing and letting me know it's working for you as well.
Description
Add Duo Universal Prompt + Okta Classic support, including Duo Push, Phone Call, and Passcode methods of approving.
Related Issue
431
Motivation and Context
Duo is sunsetting their Traditional prompt in March 2024, so we need to migrate completely to Universal Prompt by then. Many of our people utilize gimme-aws-creds in their daily workflows, so I'm interested in contributing support for it.
Duo Universal Prompt integration with Okta is through a custom IDP. Okta presents this factor as a
claims_provider
type, which I've added to the relevant factor logic. I've made Duo Push the default Duo method and added a configuration setting for specifying whether to use Duo Push, Phone Call, or Passcode methods of approving.Besides the new Duo interactions, the new factor type also behaves differently when it comes to yielding an active Okta session. The Universal Prompt redirects to an Okta URL that accepts the result from Duo and, assuming success, immediately grants an active user session. So, I adjusted
OktaClassicClient#auth_session()
to handle that case, where it does not need to separately accesslogin/sessionCookieRedirect
to get the session cookie.How Has This Been Tested?
I contacted our Duo support to determine the best API to use for driving Universal Prompt without a browser, and their answer was that there is none. It looks like it's the same for the traditional Duo prompt implementation in gimme-aws-creds. So, the implementation is based on observing the HTTP requests made by a browser when authenticating to Okta with Duo Universal Prompt MFA. I've added unit tests that verify the interactions and data flow match what I reverse engineered from those observations.
Additionally, I've tested the updated gimme-aws-creds end-to-end locally against our Okta Classic tenant that is integrated with Duo Universal Prompt and the traditional Duo integration. My manual test regime includes executing approved and disapproved MFA for Duo Push, Phone Call, and Passcode.
I'm running gimme-aws-creds on a Mac with Ventura 13.6.
Screenshots (if appropriate):
Types of changes
Checklist: