Fixed reading the force_classic parameter from the config file
Changed the default behavior for a missing value on force_classic
Disabled the DT cookie when in force_classic mode
Changed the source file filename to fix HomeBrew deployment
Description
The default behavior is to treat any missing or empty parameter in ~/.okta_aws_login_config as False. This causes an issue for orgs that are migrating from Okta to Classic to OIE because it forces all users to use the --force-classic parameter, modify their config file directly or run gimme-aws-creds --configure after migration to update the force_classic value.
We want to make migrations as seamless as possible for users, the default behavior from now on will be to treat a missing or empty value for force_classic as True. This will make gimme-aws-creds behave in the same way before and after the migration. You can then create a new OIDC app for the device authorization flow and have both flows available for a phased transition to the browser-based login.
When using a Global Session Policy that triggers MFA based on the DT cookie and an application policy that requires MFA, OIE uses the "step-up authentication" process, which is not supported by gimme-aws-creds "classic" mode. Disabling the use of the DT cookie avoids this situation and makes the classic mode useable in more auth policy configurations.
The move to building gimme-aws-creds using PIP instead of setup.py starting in 2.8.0 changes the filenames that were output, which broke the homebrew build (homebrew doesn't recognize that gimme-aws-creds has updated). The updated filename configuration should take care of this issue.
Related Issue
455
454
452
How Has This Been Tested?
Tested with migrating domain from Classic to OIE and updated unit tests
Screenshots (if appropriate):
Types of changes
[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
force_classicparameter from the config fileforce_classicDTcookie when inforce_classicmodeDescription
The default behavior is to treat any missing or empty parameter in
~/.okta_aws_login_configas False. This causes an issue for orgs that are migrating from Okta to Classic to OIE because it forces all users to use the --force-classic parameter, modify their config file directly or rungimme-aws-creds --configureafter migration to update the force_classic value.We want to make migrations as seamless as possible for users, the default behavior from now on will be to treat a missing or empty value for force_classic as True. This will make gimme-aws-creds behave in the same way before and after the migration. You can then create a new OIDC app for the device authorization flow and have both flows available for a phased transition to the browser-based login.
When using a Global Session Policy that triggers MFA based on the DT cookie and an application policy that requires MFA, OIE uses the "step-up authentication" process, which is not supported by gimme-aws-creds "classic" mode. Disabling the use of the DT cookie avoids this situation and makes the classic mode useable in more auth policy configurations.
The move to building gimme-aws-creds using PIP instead of setup.py starting in 2.8.0 changes the filenames that were output, which broke the homebrew build (homebrew doesn't recognize that gimme-aws-creds has updated). The updated filename configuration should take care of this issue.
Related Issue
455
454
452
How Has This Been Tested?
Tested with migrating domain from Classic to OIE and updated unit tests
Screenshots (if appropriate):
Types of changes
Checklist: