-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Duo Universal Prompt support to Okta Classic #437
Conversation
Duo's Universal Prompt Okta integration involves a new type of MFA factor, claims_provider. This change treats claims_provider as Duo Universal Prompt and implements the interactions required to trigger a push to the user's preferred device, then complete the transaction and obtain a valid Okta session. Supported authentication includes Duo Push, Phone Call, and Passcode.
7aff5ef
to
9f61e8f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code all looks good to me and the tests pass.
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.
cheers 🍻 |
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: